小熏的编程日记

越过长城，走向世界
Across the Great Wall we can reach every corner in the world.

7月21日，老爸陪余去爬八达岭。坐北京北到延庆的柴油动车组，二等座的票价14元，座位很舒适，空间很大

进入山区，火车一直在爬坡

路过居庸关

这样看去，也相当的崎岖

八达岭高速在堵车

出京方向，停靠的是青龙桥新站，返京时，停靠的是青龙桥老站。老站才是詹天佑的设计

查看大图

青龙桥新站。其实，余觉得在这里上班很不错，抬起头就是青色的山峰和灰色的长城。传说在青龙桥下车可以去爬残长城

终于来到长城的脚下。北坡方向

左边的山峰应该是附近的最高点

回望南坡。最低点是关城，南北两端从关城延伸

在此处断开。古代的工艺还是力有所不及

即将到达北坡最高点，看见了缆车

山峰非常陡峭，长城如果能修到那就牛叉了

最高点，北八楼不给上了。GPS测量的高度是872m

刻纪念牌的小商贩。好像是十块钱一个小的，二十块钱一个大的。最高点的生意明显比下面的好许多

爬完北坡，转回来再爬南坡。南坡的人很少，可能也跟时间有关。远处动车从青龙桥新站开出

回望北坡

砖上的刻字。最左上的那位功力深厚

人很少

真的非常少

少到可以拍到完全没有人的照片。这应该是南六楼

从终点俯瞰没修复的残长城

南坡终点。有刻石碑画的商贩，女老板英语能扯好一些，成功忽悠了一个老外买了块大的，100人民币+5张1欧元

八达岭处于飞机降落的航线上，飞机非常频繁

再回到关城，遥拍想摸个一筒，就摸个一筒。大概是奥运的公路自行车赛从此经过

回京。傍晚的八达岭车站。其实快的话，可以赶得上下午三点的火车回去

19日跟老爸去了天坛，下着小雨，非常凉爽的天气。20日毕业典礼天晴，之后直到28号离开北京，都非常炎热，后面几天很闷，也就传说中的桑拿天

雨中拍天坛的光影效果自然不及21日的八达岭长城，不过也别有一番韵味。总觉得那天的天气很像南方三四月时的阴雨连绵，雨细细的一直下个不停

坐地铁到天坛东门，从东门进去。在长廊看到很多老人家打牌，然后看到一个老爷子在跳舞，跳得非常好，一群人在围观

接着走就是祈年殿。天坛标志性三大建筑物之一

排水体系

祈年殿很难拍全，下了三级台阶从较远地方拍摄又会遮挡底部

虽然是下雨天，但游客还是蛮多的

回音壁和皇穹宇，回音壁已经围起来了，老爸当年来的时候还可以贴上耳朵去听

遇到一个同讲白话的伯伯，盛赞皇穹宇的建筑工艺

圜丘。圜丘和祈年殿台基的工法很像，把大殿拿掉，也是一圜丘。以前初中的语文课说皇帝站在圜丘中央说话，柱子反弹回音，会使得声音听起来比较大。可惜人很多，无法实验了

望灯

被袁世凯推倒的望灯

接着转向天坛的西面。新植的柏树

斋宫的桥

斋宫的护城河

斋宫

月季园。来张微距

再来一张微距

从西往东横穿，返回东门。遇到一只蜗牛

这条路上还画了一个羽毛球场

大概下午五点多坐地铁返回

在毕业典礼的前几天，学位服已经发了下来。老爸也正好抵达帝都，于是第二天在校园取景拍了一些照片。
自爆什么的是不会有的，同鞋的也不好发上来，于是贴一下景物的照片

学校的荷花7月就开始开放了，但还没到极盛

四倍光学变焦拉近拍，这小DC的极限了（啥时候余能有台单反啊

水草和倒影，倒影很清晰的

已经有一部分荷叶残掉了

不知道名字的奇特的树，花朵开在树尖

从树底下往上看基本看不到

航院有一架灰机，两个屁股，应该是歼八

看机头，应该是歼八早期型号

20号，毕业典礼，早上雨刚停。学校居然安排家长到6教看网络直播，真仆街，综体里空位一大堆。老爸说基本什么都看不到

到中午已经是晴空万里

典礼后继续拍。校园里人非常多，和同学将就在一些显著景点拍了下。
荷塘

于是就这样毕业了

7月12日～13日，老板请客去天津玩，其实12日是参加研讨会，13日算是福利，这就是毕业旅行了。先前承诺的去坝上吹了

也没坐上京津高铁，雇的是校巴，一路上在京津高速上飞驰，用G4的GPS测速，居然上到了100KM/h以上

天津港国际邮轮码头客运大厦是我们本次前往参观的目的地。码头坐落在渤海的填海造出的土地上，离海河入海口颇远
码头吃水10米深，围栏后面是登船桥，这种方式和航空的一样

客运大厦的光告就不多打了，流动的丝带是常用的字词。
其实施工质量并不是特别好，GRC板的缝隙很大，远看还好，近看有点脏，地面的大理石面砖也偶见被压坏，出入口围了半圈觉得很SB

传说造价100W的厕所，对面还有一个

镜头没完全打开，很奇妙的拍摄效果

晚上，吃海鲜，接着和同鞋一起逛了下周边。入住某酒店。
第二天。该酒店提供的早餐巨垃圾。一行人从中午起先后中招腹泻，还没吃午饭，已经战损3大主力，剩余的人午饭还吃得颇欢，结果下午就都不行了。估计是早餐的问题。

上午逛了下海河外滩公园，其实没觉得有啥看头

貌似喷水的装置

每人花了30块钱，上了一游艇。旁边的冲锋舟不断做着10元一次，安全刺激的光告，确实很刺激，不过也就转一圈，不到2分钟就结束
刚开始时余还以为30块钱能出到海河口，谁知竟是在河里往上游开个3、4公里就返回了

传说发哥拍的赌博片曾在此邮轮上取景

很有意思的大桥，中间的航道在桥梁升起后可以通行更大吨位的轮船

海河的水非常的脏，不逊于珠江

轮船启动时发出的黑烟还真大

中午去天津市区。在古文化街附近觅食，此时一个二个已经不行，暂时没事的去寻古玩（？），余已经被放倒就在玉皇阁歇息

大家购物完毕，匆匆返回帝都，结束糟糕的出游

关于页面里给的联系邮箱是

如果曾打开过mail.kuyur.info应该就会发现其实是疼迅提供的域名邮箱。今天决定将其转移到Gmail上。

使用Gmail做域名邮箱需要注册Google的企业应用套件，好在标准版是免费的，注册地址：http://www.google.com/apps/intl/zh-CN/group/index.html

注册流程挺简单的，验证域名后即可启用数种服务，包括Gmail、日历、sites、docs等，并且可以为单独的服务自定义自己域名的网址。Gmail的域名邮箱比国内IDC提供的企业邮箱好太多，IDC的垃圾企业邮箱去死！Gmail的服务质量也无疑比疼迅、网易等的域名邮箱要好。

标准版Google企业应用套件提供50个用户额度，因此熏子可以开一个小型电子邮局啦。如果你喜欢@kuyur.info的地址邮箱，可以发送邮件到上面的邮箱，注明用户名和密码，熏子为你手动添加帐号。邮箱空间即是Gmail的空间。

邮局：http://mail.kuyur.info
Google企业应用套件：https://www.google.com/a/kuyur.info/

实验室某后辈的玩具熊，身长50cm（好像不止50cm）。余也想要一个啊（咬手指）

情侣必须去死去死去死！

肖申克的救赎其实是一部伟大的同志电影，看，宣传海报已经指出了这点

整部影片讲述的是推与被推、从被推到逆推以及基友之间的基情故事。

影片没有女猪脚，甚至连女配脚都木有，在同志电影中这都是鲜见的，李安的断背山好歹基友们都有老婆而且还生活得很好，本影片可怜的男猪脚刚开始老婆就挂掉了。影片中女人出现的次数少得可怜，仅见的镜头就是超市里的大妈，男猪脚的老婆更是只有背影，并且是在激情的时候被做掉了。这反映出了导演对女人的蔑视、对出轨行为的憎恨以及被出轨行为深深伤害的扭曲心灵。到影片最后，男猪脚说他原谅了妻子，然而给余的观感是死了活该，只可惜男猪脚坐了20年冤牢，导演想通过男猪脚的话表达出宽恕，然而给观众的实际观感出卖了他。

男猪脚和一号男配角的基情故事是影片的主线，两人客服了种种艰难困苦，最后终于成功搞在一起。男猪脚一进监狱，一号男立刻看上了他，这叫什么？这叫一见钟情。两人在狱中擦着基情火花，互相视对方为心目中最重要的人，这叫情人眼里出西施。影片最后，墨西哥的海滩，明媚的阳光，蓝蓝的天空和海洋，雪白的沙滩，一艘小船，多么浪漫的场景，放到任何一部电影中肯定是爱的重逢，两位基友紧紧拥抱在一起，导演的意图已经公仔画出肠。不用说男猪脚肯定是攻方。

对于罪犯而言，典狱长和狱警都是攻。想上男猪脚的家伙喜欢爆人菊，结果被狱警用警棍爆了菊，可怜的家伙。当然，他应该成功推倒过男猪脚，但攻受转换就在瞬间。男猪脚被狱警看上了，接着被典狱长看上了，成为典狱长的御用后宫。二十年间，虽然有小摩擦，倒也显得恩爱，就算男猪脚惹怒了典狱长，典狱长也舍不得上SM。男猪脚后来也收了个后宫，典狱长非常愤怒男猪脚居然想背叛他，于是将他的小后宫给枪了，意图让男猪脚回心转意。然而男猪脚已经非常厌倦当受了，成功越狱并通过超长距离精神触手逆推典狱长。典狱长说他是总攻，结果导演笑了。典狱长致死都不明白他怎么会被逆推的，谁让男猪脚头顶猪脚光环啊～

以上纯属口胡，认真乃就输了

android也是Linux系统，解决乱码的原理是一样的。

音频文件可以使用的tag版本非常多，mp3大多使用这三个：ID3v1、ID3v2、APEv2，每个版本下又有多个小版本。Windows只能支持ID3v1，ID3v1其实是不支持多语言的，但因为Windows平台使用本地语言编码页去处理那些多字节字符串，简体系统中文字符能够显示出来，倘若来了个Shift-JIS的ID3v1，Windows就只能乱码了。这种情况和txt是一样的。如果将mp3的ID3v1抹掉，Windows自身的资源管理器和media player将不能识别mp3信息。ID3v2和APEv2都支持Unicode，这才是真正的多语言支持。让播放器去猜ID3v1的编码类型是最笨的方法。因此并不是说Windows的编码兼容性好，Linux就差，仅采用多字节编码去写ID3v1才是真正的罪魁祸首，杯具的是大多数mp3文件都是这样子，而Windows是其推手。

标签的使用优先度是播放器的事，支持是否也是播放器的事。一般而言，大多数播放器都支持ID3v2和ID3v1，ID3v1的优先度会设得比较低。Foobar2000支持APEv2、ID3v2、ID3v1，优先度应该是APEv2最高，ID3v1最低。在Foobar2000上转换出来的mp3的兼容性相当好，fb2k默认会写ID3v2（UTF-8）和ID3v1（本地编码），ID3v1实现了Windows平台（资源管理器和wmp）的兼容，ID3v2实现了多语言支持。Linux的播放器一般都支持ID3v2，而且优先度比ID3v1高，因此播放这些mp3不会乱码。

故一个较好的方案是：UTF-8的ID3v2+本地编码的ID3v1。这个工作fb2k 0.9版本以上可以完成（0.8.3不清楚）。

操作如下图所示，首先选中要转换的曲目，弹出右键菜单，tagging->MP3 Tag Types

勾选ID3v1和ID3v2，APEv2可选可不选，但Linux下很多播放器都不支持APEv2，所以建议不选。Updates files，完毕。

这可以为ID3v2缺失的mp3文件重建UTF-8的ID3v2。

倘若在ubuntu下仍然有乱码，不用怀疑，那是因为ID3v2不是UTF-8编码。ID3v2是可以存放本地多字节编码的，mp3若已经存在ID3v2，fb2k会跳过而不重新生成，导致ubuntu下仍然是乱码。这种情况我们可以借助APEv2做中介（APEv2只支持UTF-8，且字段比ID3v1丰富）。勾选APEv2，Update files（生成UTF-8的APEv2）–>去掉ID3v2的勾，Update files（擦掉非UTF-8的ID3v2）–>勾上ID3v2，Update files（重写UTF-8的ID3v2）。最后的APEv2保留是否随意。fb2k擦写ID3v2比较耗时，因为ID3v2位于头部，需要重构文件，处理几百M文件以上就会觉察到了。但毕竟非UTF-8的ID3v2文件是少数，ID3v2是不是本地编码在fb2k中也看不出来，这项修正工作可以到ubuntu下完成。rhythmbox（支持APEv2和ID3v2）、audacious和Amarok（仅支持ID3v2），这些播放器的播放列表如果还存在乱码曲目，用wine加载fb2k对乱码曲目执行上面步骤。

以上基本可以解决Android和ubuntu的乱码问题。再赞foobar2000，非常优秀的播放器，优秀是表现在能力上，不是在界面。倘若添加“仅为非UTF-8 ID3v2重构UTF-8 ID3v2”那就更完美了。

明天（确切说是今天了）毕业论文答辩，这几天过着昏天暗地的日子。余真是到了deadline才会动手的银，从初审回来有15天的时间，基本上就只在最近这三天忙活，这性格啥时候能改一下呢。

三年就这样匆匆过去，烟酒僧生涯也将要结束。从小学一直读到现在，从未间断。一回首，感觉时间从高中起至今天简直就是过眼云烟。下一个十年的感触又会什么样呢？

很快就要正式步入社会，开始第一份工作，进入人生新的阶段。但无论怎样，读书也好，工作也好，希望熏子都能够保持激情，就算再讨厌的事，再难捱的困难，都不阴暗，保持乐观的态度坚持下去。面朝大海，春暖花开。

字符串的编码检测需要使用自定义的映射表，使用系统自带的Codepage是不大可能有准确率的，系统Codepage会将它所有没定义的字符映射为空格。
GBK、Shift-JIS、BIG5的码表空间都是不连贯的，而它们的有效空间也不完全重合，这为检测编码类型提供了可能性。

检测算法：
1、建立字符映射表：将任一ANSI编码的所有字符做全映射，从0x00到0xFFFF都有Unicode字符对应，但需要注意的是没有定义的字符统统映射到Unicode的0xFFFD（共三个映射表，既可用于检测也可用于转换）。
2、预设字符串的编码是Shift-JIS。
3、使用Shift-JIS的映射表从字符串第一个字符开始检测直至最后一个字符。如果遇到有字符映射到0xFFFD，设置预设编码是GBK，立刻停止步骤3，跳至步骤4。
4、如果预设编码是GBK，使用GBK的映射表从字符串第一个字符开始检测直至最后一个字符。如果遇到有字符映射到0xFFFD，设置预设编码是BIG5，立刻停止步 骤4，跳至步骤5。
5、如果预设编码是BIG5，使用BIG5的映射表从字符串第一个字符开始检测直至最后一个字符。如果遇到有字符映射到0xFFFD，设置预设编码是未知编码，立刻停止步 骤5，跳至步骤6。
6、返回预设编码。

这个算法的编码检测优先度是Shift-JIS>GBK>BIG5，也即如果顺利通过当前检测，则跳过后面所有检测。事实上，有大量字符串是能通过所有检测的。例如只有一个字符的字符串，假设这个字符是0x8140，在三个编码当中，都不会映射到Unicode的0xFFFD，因此能通过所有检测。但这没意义了。设定了优先度后是为了告诉用户最可能的一种编码。

为什么设定Shift-JIS>GBK>BIG5？
Shift-JIS的码表空间是0x00-0x7F、0xA1-0xDF、0x8140-0xFC4B
GBK的码表空间是0x00-0x7F、0x8140-0xFEFE
BIG5的码表空间是0x00-0x7F、0x8140-0xFEFE
但双字节段（0x8140以上）都不是全部已定义，Shift-JIS在0x8140以上的有效字符数是7724，GBK是21885，BIG5是19782。
GBK的覆盖面最大，有效空间基本覆盖了Shift-JIS，因此一个字符串如果能通过Shift-JIS检测，也差不多能通过GBK检测。如果将GBK的优先度设得比Shift-JIS高，那么大量真正是Shift-JIS编码的字符串就压根没机会返回给用户了。从反方向看，GBK中存在数量庞大的字符Shift-JIS没定义，Shift-JIS是高度覆盖不住GBK的，一个GBK文本从概率上没那么容易检测成Shift-JIS。也即：如果一个文本的真正编码是Shift-JIS，那么优先使用Shift-JIS检测自然不会有问题；如果它是GBK，那么优先使用Shift-JIS检测也不大会返回Shift-JIS。因此Shift-JIS应当优先于GBK。
Shift-JIS和BIG5的关系的考虑也类似。

从转换日系音乐cue、日文小说的宅用途出发，也应当将Shift-JIS设置为最高。

下面三张图是是Shift-JIS编码的小说“文学少女”と死にたがりの道化的转换结果。左边是当作本地编码的处理结果，可以无视。右边才是转换结果。
（程序和文本下载：http://code.google.com/p/unicue/downloads/detail?name=Ansi2Unicode_1.01.zip）

使用Shift-JIS映射表转换，结果自然是正确的。

强行使用GBK映射表转换，没有出现标记0xFFFD（0xFFFD：�），也即能通过GBK检测

强行使用Big5转换，出现0xFFFD标记，也即通不过BIG5检测。BIG5跟Shift-JIS的有效空间重合度没那么高，区分相对容易一点

另外一个GBK文本强行使用Shift-JIS转换的结果。很容易就出现了0xFFFD标记

那么GBK和BIG5的优先度应该谁高呢？这里就见仁见智了。GBK的字符数比BIG5多，从概率上GBK相对容易覆盖住BIG5，BIG5相对不容易覆盖住GBK。倘若采用Shift-JIS和GBK之间的比较方法，应该是BIG5的优先度比GBK高。但从实际情况来看，真正BIG5编码的文本强行使用GBK映射表转换比较容易出现0xFFFD标记，真正GBK编码的文本强行使用BIG5映射表转换反而不容易出现0xFFFD标记。

GBK文本强行使用BIG5映射表转换的结果，不容易出现0xFFFD标记

BIG5文本使用BIG5映射表转换，正常的结果

BIG5文本强行使用GBK映射表转换，很容易出现0xFFFD标记

现实结果和表面现象完全相反。如果一个文本的真正编码是GBK，那么优先使用GBK检测自然不会有问题；如果它是BIG5，那么优先使用GBK检测也不大会返回GBK。因此余倾向于GBK的优先度高于BIG5。
阅读全文…