无意中在twitter上看到有人提到这个软件，开始还以为是个手机上统计流量的小玩艺来着，总共才100多k的样子，昨晚仔细看了一下官方的文档，原来这是一个用来加快网络速度的软件，数据传输会适当进行压缩，还有一个附带的功能就是翻墙，操作超级方便，速度也很快，是个绝佳软件。
官方网址: http://toonel.net
一直以来对大海都充满期待，所以就想借这次国庆的机会出去转转，与几个在附近工作的同学朋友们联系了一下，都欣然应允了我的请求。
第一站来到惠州，去了大亚湾的金海岸，算是第一次看到了大海，心中并没有太大的震憾和激动，人生可能就是这样，有些东西只要存在心里就好了。那里的海滩平坦开阔，海浪也很平缓，在那里提双鞋光个脚丫漫步，还是相当惬意的。在这里我们本来也想下水去玩的，但由于事先准备不充分，最终还是放弃了，我们爬到了海岸附近的一个石头岛上，尽情的体验了一把浩瀚的大海。
第二站去了深圳，其间有个好久都没联系过的同学，起初第一眼我还没注意到，走了一段才发现，颇有些意外，。在深圳我们去的是大梅沙公园，这里的海浪特别大，好多人拿个救身圈站的海边冲浪，后来我们也加入其中，海水很咸，但也很凉块，我小时候在家里就学会游泳了，所以在水里还算游刃有余，海水浮力比在淡水中要大得多，在水中人基本可以保持平衡漂浮在上面。面对海岸边上一波接一波的风浪，不下水去冲冲那真是可惜了，海浪一般都是从远处缓缓飘来，快到海岸就会迅速翻转而上，形成一个将近一米到两米的浪花然后急泻而下砸向岸边，这时站在浪花内侧的人被冲向岸边了，每来一波都会有许多人同时尖叫呐喊，场面十分火暴刺激(胆小的人不敢站在这里冲)，有些不会游泳的人，刚走出几步就被浪花打了回来，根本没法到海中间去，我们搞笑的Bing同学就是其中之一，抱着救身圈拼命的蹬脚，可总还是在原地打转转，真可惜了那强状的身体，那滑稽的样子，要笑死人。从大梅沙出来，几个人都筋疲力尽了，坐车的地方人山人海，而且一上车一般都是个把多钟头，真是够要命的了，深圳是很大，但很多地方都是山，第一感觉有点像个山城似的，当然深南大道是不错的，宽阔整洁气派，有现代大都市风范。
从大梅沙回来的当晚，才注意到皮肤出问题了，连续暴晒两三日，都被晒伤了，手臂，背部都有灼烧感，而且都变成红黑色，背部基本成黑皮了。
非常感谢两地同学们的慷慨接待，麻烦大家了，这些天过得很开心很充实。
惠州大亚湾
惠州大亚湾
Emacs22 的编码原理是让多个国家的编码系统共存。buffer里的每一个字符 都用 1－4 个字节表示，比如 gb2312 的汉字就是用3个字节表示，这三个 字节中的第一个字节叫 leading byte, 说明了这个字符所属的字符集，后 面两个字节是这个字符的gb2312编码。chinese-gb2312 的 leading byte 是 0×91, big5 因为比较大，所以分成了两个 charset: chinese-big5-1 和 chinese-big5-2, leading byte 分别是 0×98 和 0×99。
所以对于 Emacs22 来说，只要查看一个字符的 leading byte，就可以知道 它属于哪个字符集，一看是 0×91 就知道它是 gb2312 字符，一看是 0×98 就知道它是 big5 字符。所以一个汉字可能会有好几种内部编码，比如“好” 字，gb2312, big5, 朝鲜文, 日文中都有这个字，那么它就有四种内部编码。
当 Emacs22 打开一个文件的时候，就需要判断出这个文件的编码系统，然 后给文件中的每个字符加上 leading byte，放到内存中，Emacs22把这个过 程叫做 decode。当emacs22保存文件时就需要根据每个字符的 leading byte 把它转换成相应字符集的编码，再写到文件中，emacs22把这个过程叫 做 encode。
为了演示 Emacs decode/encode 的过程，我们可以做个小实验：
- 新建一个文件 ~/test.txt
- 输入“中文”两个字
- C-x <return> f gb2312
- C-x C-s 保存文件
- 在 *scrach* buffer 里输入
(insert-file-contents-literally “~/test.txt”)
C-j 一下可以看到 \326\320\316\304 ，这是八进制的“中文”两个字的编码。
- 现在打开 ~/test.txt，然后执行
M-x toggle-enable-multibyte-characters
我们可以看到 \221\326\320\221\316\304，Emacs在每个汉字的编码前都加 上了一个 \221，正是十六进制的 0×91——gb2312的 leading byte。
然而，leading byte 的数量是有限的，而世界上的字符集却越来越多，因 此当 gbk 和 gb18030 出现以后，就没有合适的 leading byte 分配给它们， 所以 Emacs22 不支持 gbk 和 gb18030。
苏勇和詹剑写的 mule-gbk，实际上是把全部的gbk字符分成了三部分，分别 占用了 chinese-cns-5, chinese-cns-6, chinese-cns-7 的 3 个 leading byte。mule-gbk 的主要代码就是把 gbk 中的字符加上这三个 leading byte 之一，放入内存，也就是 decode；或者反过来把内存中带有 这三个 leading byte 之一的字符转换成 gbk 编码，也就是 encode。 Emacs为了方便进行各种编码的转换，专门内嵌了一种称为 ccl 的语言，编 码转换部分的代码就是用 ccl 写成的。
Emacs23的编码原理是把所有的字符集都转换成 utf-8，内部字符都是 utf-8 编码。这样对于每个字符集都需要两张表，一个是 charset –> utf-8，另一个是 utf-8 –> charset。Emacs23源码的 etc/charsets/ 目录 下有很多 *.map 文件，就是这种转换表。
当Emacs23打开一个文件时，先判断文件的编码，然后加载相应的表格，再 按照表格把文件中的字符一个一个转换成 utf-8 放入内存；保存文件时， 也是按照表格把内部的 utf-8 编码转换成相应的字符集编码。
unicode 的全部编码可以分成很多 block，在 www.unicode.org 可以查到。 由于中国参与 unicode 的制定比较晚，因此造成了gb2312/gbk/gb18030中 的字符被分配到了很多不同的 block 中，汉字还相对比较连续，标点符号 就特别分散，这个block中有几个，那个block中有几个。
Emacs 23 在进行 fill 时不整齐的原因，主要是那些标点符号的宽度属性 设置错误，本来应该是2，却设成了1，因此 fill 时计算行宽不准确，标点 符号越多，误差越大。我的那个patch主要是更改了这些标点符号的宽度属 性。
由于长期以来，网站更新量少，一来由于时间精力有限，再者个人能力也有限，故想效仿大牛们的做法，把网站改成自己的个人博客，采用了主流的wordpress系统，做为一个信息分享的平台，与大家共同学习进步。