kindle与卫斯理   Kindel者，亚马逊出的电子书阅读器也；卫斯理者，中国写汉字最多的人也。   为啥这两者会有联系呢？   由于世界还没有大同，各国还在使用不同的文字。更有甚者，同一个国家，可能 还在使用不同的文字。   更更有甚者，在计算机世界里，更加混乱。   即使是相同的文字，也可能用不同的方法编码--就是以数字对文字进行编号。   对英文甚至数字都有不同的编码方案，比如著名的ASCII和BCD码、克雷码等，不 一而足。   更不用说汉字了，计有GBK，GB2312，GB18060，UTF-8等诸多编码方案。   给你串数字497825832403，在不同的编码方案下，对应着不同的文字。如果不告 诉你用的是什么编码，打死你也猜不出来。或者你就挨个方案猜，结合上下文， 看哪个方案猜出来的像是人话。   计算机程序如果事先不知道编码是什么，也就只能瞎猜（比以上更有些依据，有 限）。   Kindle也需要程序解码，因此也有类似的问题。   我在把卫斯理全集整到kindle的过程中，花了40多个小时，悟出了点道理。   以下。   1. 文件名， 文件内容 都是有编码的. 在Windows下尚好，只有GB系列的编码，它还是少年，不会犯青年的错误. 而Linux对中文以各种方式支持，这就要求使用者选对. 我发现如果发到kindle的邮箱的话，编码相同为宜. 以UTF-8编码为宜. 但是，这不是最好的方法.   2. 如果在windows下，能以word发送，相当之好. 这时候排版较好. 最好别整成PDF再发.无论是全图扫描的，很多图片的，编码不是非常简单的，处 理的都不太好看.   3. 有个软件，Calibre，是专门用来转换电子书格式的，很不错. 有windows, osx, linux版本. 最大的好处是，传到kindle以前，可以先预览一下效果. 但是，当它处理大文件，即很多文字的时候，速度极其慢. 比如卫斯理全集，在我的实验中，每次都耗费几个小时之多. 然后一看，可能仍不符合要求.打击人.   4. 最后我终于发现最佳处理流程. 如下.   步骤1. 先把不管什么格式，手动整成HTML；这能节省calibre，就是上面说的那 个电子书格式转换软件，很长时间.   不知道该软件啥算法，把PDF或者大的TXT（比如能写如卫斯理这么多文字者）转 成HTML就要费掉几个小时.   手动整成HTML的意思，比如把TXT文件改名为HTML后缀.   步骤2. 手动修改HTML   如果是TXT改名成HTML， 加   啥啥啥   head里那段是关键.   步骤3. 用UTF-8编码保存. 如果是记事本打开，可以另存为UTF-8格式. 如果是用emacs打开，C-x RET f C-x s，编码选UTF-8   如果整不出来utf-8，那么，HTML的编码 和 内容的编码 都用gb2312吧.   步骤4. 段落   把所有的^J或^M改成

.   段落前的空两格，与后面要用的转换工具有关.free.kindle.com的信箱和 calibre对

处理不完全一样.   calibre转换html到mobi时，

的每个段落前不会自动加空格（所以需要手动每 个段落前全角空格，批量替换.我用的方法.）；free.kindle.com的信箱转换html到 azw时，

的每个段落前会自动加2个全角空格那个大的空白；   步骤5. 转换   用calibre转html为mobi格式.   步骤6. 发送   发送mobi格式的文件到free.kindle.com上的你的信箱. 你的信箱的意思是，在kindle上能查到的，你的 用来转换个人文档的 信箱， 不是 yourname@free.kindle.com. 学计算机的谨记，自然语言是模糊的多义的.不咋地的.   以上.   这个故事告诉我们：无论多长的内容，采用了正确的方法，就总能成功解析；无 论多长的路，踏着正确的方向，就总能走到终点.   ”正确的”关键是，始终如一，处处一致. 用GBK，那就是GBK，用UTF-8，那就是UTF-8.   只要有一处矛盾，那么就全盘皆错.这也是逻辑残忍的一面，”它会因为对所有人都 相同的态度而伤害某些人的宗教感情.”   这个故事花费了我40个小时以上的时间.其实尽早地换个数据来源，可能会更容易. 40小时的时间这个故事告诉我们：如果走了很久的夜路仍然没有尽头，那么应该 换条路，或者   醒过来.