Liu Zhongshu

现今的压缩格式种类繁多，常见的有zip,rar, 不常见的7z，imp，ace，bz2等，多的让人数不过来，今天有兴致研究了一把这些格式的压缩算法。
压缩算法包括有损，无损两种，一般的有损压缩是在执行特定的有损变换后再执行无损压缩，所以这里我们只讨论无损压缩算法。按照一些教材的分类(这些教材可 能偏老，现代的压缩算法不知还能否这样分)，无损压缩一般可分为基于统计模型和基于字典模型的两大类，最早的应用于数据压缩领域的算法应该是基于统计模型 的Huffman算法(1952)，在Unix和Dos的早期版本中都可以找到基于Huffman算法的软件，不过现在已经极少用了。
1977/1978，两个聪明的以色列人提出基于字典模型的算法LZ77，LZ78，这两个经典文献提出的算法成为了当代几乎所有流行压缩软件的算法核 心。1982年, LZSS算法作为LZ77的改良被提出，大量的压缩软件使用了这个算法，如zip,arj,lharc等，1985年，LZ78的改良LZW提出，LZW 也得到广泛的应用，如GIF图像中的压缩算法，Unix下的compress程序。但由于LZW存在专利问题，此后的应用并没有LZSS广泛。
如今大量的新的压缩格式出现，如bzip2，imp，他们都能够提供比前辈们更高的压缩率，这些压缩软件的核心算法则比较新，如PPM，BWT等，也难以查到相关资料。不过有很多网站定期做最新压缩算法的评测，可以做参考http://compression.graphicon.ru/ybs或者http://www.maximumcompression.com/, 看看最新的评测结果，排名靠前的压缩软件有Slim 20，Durilca 0.3，Epm 9，7Zip 3.11，Paq6等, 只有7zip我用过，其它连听都没有听说过！它们大多能提供比WinRar3.3还要小10～20%的压缩结果，只是速度一般比较慢，耗用内存比较多，再 加上用户界面的简陋(大多是命令行界面),所以没有流行起来，其中有些软件还是OpenSource的, 如PAQ, 7zip，厉害。

对于访问计数来说，1000实在是个很小的数字，不过对于我的网站来说，还是挺有纪念意义的，今天是2003/12/29，能够在2004年到来之前达到1000，我还是很高兴(超出我的预期 :)) 下一个数字是10000，目标就暂定在2005年吧。
Weblog在国内现在已经有很多人用了，光是在www.blogcn.com这个网站上，注册的Weblog用户已经超过10万，当然还不包括我这样的散户，以后准备找一些感兴趣的Weblog加入到我的链接里去。

随着内容越来越多，再象原来那样一个页面列出所有帖子已经不太合适了，特别是CG类中有很多图像，一起列出会很耗时间，增加一个分页的功能，每页只显示部分帖子，然后可以一页一页前后翻，就像很多论坛里的帖子一样，这样可能比较好，b2的功能还是很强大的，并且扩充性很好，增加分页功能并没有费多大事情。
前两天还想起要增加skin，就是将这个页面的外观改变一下，这样我看久了也不会烦了，今天有空就做了一个，这个改动也不大(因为CSS我没有改)，原来的那个被放到index1.php了，所有的图象都是在Photoshop中做的，然后在Dreamweaver中组合成HTML，最后用文本编辑器手动修改一下，再加入php代码就可以了。整个过程并不复杂，原来准备将CSS也一并改掉的，这样看起来才会和以前的有很大不同，但CSS试了多次，效果都没有原来的好，就没有改了。
做下来感觉蛮有趣的，以后可以多做一些，反正可以从index1.php,index2.php一个一个排下去，呵呵.
(Blog是Weblog的简写，在中国Weblog被称作博客, 我想多半是来自Blog这个词，台湾的翻译叫做部落客，感觉也很形象)

《Memory Management Algorithms and Implementation in C/C++》
少有的介绍内存管理比较深入的书, 从Intel x86的内存管理的硬件构架, 到操作系统(DOS,Linux,Windows)的内存管理策略直到上层应用软件的内存管理. 深入透彻.
相比那些泛泛而谈的书, 我更喜欢这类面向特定专题, 讲解深入的书, 尤其是介绍内存管理的书, 比较少见. 可惜没有中文版, 我看起来费劲多了.
Amazon上的链接。

这个也画的不好, 上色的时候只用了PT里的极少的几个笔刷"Soft Charcoal", "2B Pencil", "Captured Bristle", 因为其它笔刷一概不会用. 并且经常是无从下笔, 那些教程里的一句话, 诸如"上底色", "刻画细部"等都够描上半天的, 而且往往效果出不来. 慢慢练习吧 ...

由于以前不知道b2中RDF/RSS功能的用处, 所以将此功能给禁止了, 现在才稍有些明白, 将RDF/RSS功能重新打开(看看页面右边内容下的两个XML图标), RDF/RSS可以看成对XML语义的定义(不是语法). 在Weblog里主要用来做Weblog的串连(基于XML), 达到自动更新的效果. 很多的网站都提供有RDF/RSS格式的更新资料, 如slashdot等.
RSS(RDF Site Summary)本身就是基于XML格式,它给出Web网站的更新描述, 当拿到一个站点的RSS以后,就可以自动分析出网站最近更新的内容,时间等详细信息, 注意这里是自动分析, 而不是人工分析, 这是RSS的最大功效, 比如可以做一个工具，定期到所有你喜欢的网站上去下载RSS，重新组织后呈现出来，非常方便。RDF和XML的说明可以参考这篇文章, 更多XML的资料可以参考IBM中国的XML专区, 上面有不错的文章.

DjVu是一种电子书格式, 据说是AT&T研究，专门针对扫描的图像，有相当高的压缩率。DjVu的官方说明是"The Technology for Scanned Documents on the Web"。现在DjVu格式的电子书还不是很多，这里可以看到一些DjVu文档的效果演示，但首先需要安装DjVu的IE插件，这样就可以象PDF一样在IE里面浏览了。
对于原有的扫描的图像格式的电子书，如JPG，GIF等，DjVu Solo这个软件可以将它们转换为DjVu格式。我手上原有一本扫描版的电子图书，GIF格式(对于一般的扫描电子书来说，黑白GIF应该是一个不错的选 择)，一共大概有50M，使用DjVu Solo转换之后，大小为5.8M左右，相当的不错。可惜DjVu Solo这个软件好像耗费内存过大，每次不能转太多页，在我的机器上，我每次转50页，然后再将转换后的DjVu拼合起来成一个文件, 这显得相当麻烦。

CStdioFile继承自CFile，区别在于:
CFile不支持text模式，而CStdioFile支持text和binary两种模式，缺省在text模式.
CFile不会对回车换行做任何转换操作。
CStdioFile在text模式下会将
转换为
，所以如果输出
，反而转成了

CStdioFile在binary模式下和CFile一致，不作回车换行的自动转换
CStdioFile比CFile多支持了WriteString接口，可以支持直接输出CString字符串，使用方便，
但此时输出字符串中不可能含字符0，因为0为CString的结束符。如果需要输出0到文件，还是要使用Write接口。WriteString的另一个区别是它会做字符表的转换，在Unicode版本的代码中(Project中定义了_Unicode)，WriteString会自动将参数从 Unicode转到MBCS，再存入文件。而Write就不会做这个转换，Write只是按BYTE一个接一个写入文件，所以如果是Unicode的字符串，写到文件中也是Unicode的。不过WriteString在做字符转换时用了wctomb函数，这个函数又要求setlocale来设置正确的代码页，否则wctomb会在转中文时返回失败，所以WriteString在输出Unicode字符串时稍微麻烦一些。
相对来说，我更喜欢使用CStdioFile。
(要在控制台(win32 console)程序中使用MFC，只需包含afx .h并在工程设置中加入MFC支持即可。)

最近编程时需要用到将中文字符串在GB2312和UTF-8之间转换，UTF-8是Unicode的一种常见编码方式(便于和老的只处理ASCII 的系统兼容)，GB2312则是中国国家汉字编码标准(与GBK兼容),UTF-8与GB2312在汉字编码上是完全不同的，在网上找这方面的中文资料很困难，最后是在一些片断代码中找到转换方法:

char strU [100]; //UTF-8编码
WCHAR* strW; //Unicode编码
int c = MultiByteToWideChar (CP_UTF8, 0, strU, -1 ,NULL,0);
strW = new WCHAR[i];
MultiByteToWideChar (CP_UTF8, 0, strU, -1, strW, c);
c = WideCharToMultiByte(CP_ACP, 0, strW,-1, NULL, 0, NULL, NULL);
char *strG = new char[c]; //GB2312编码
WideCharToMultiByte (CP_ACP, 0, strW, -1, strG, i, NULL, NULL);

上面的代码可以将strU(UTF-8字符串)转换到strG(GB2312)，过程是先将strU转到Unicode(WCHAR)的strW，再从 Unicode转换到GB2312的strG，反之从GB2312转到UTF-8也是一样，需要用Unicode中转一下。

虽然我已经测试这段代码工作正常，可我不太明白的是后一步的转换使用的是CP_ACP代码页(ANSI代码页),为什么不用936代码页(GBK)呢? 可能是因为我的中文win2000缺省ANSI代码页是936。

update:现在发现，GB18030才能和UTF-8更好的转换，因为GB18030兼容GB2312和GBK，但提供更多的字符。

最近发现的PocketPC下的PDF终极解决方案
以前用Acrobat PocketPC版本和Primer在PPC上看PDF都不能让我满意，有几个问题：
1)中文支持差，Acrobat和Primer的缺省安装都不能支持中文，要显示中文PDF，需要另安装字库，麻烦，且字库很大。
2)页面显示，Acrobat和Primer都是按页面显示PDF的，这在PC上没问题，因为显示器够大，而在PPC上可就不行了，正常的PDF页面在PPC上都要左右上下来回拖动才能阅读，好累。
3)速度太慢，对于稍大的PDF文档，Acrobat和Primer都象蜗牛一般，很久才能调入

Repligo可以解决上面的问题，但它不能直接支持PDF文档，Repligo会在PC上安装一个虚拟打印机，任何可打印的文档(当然包括PDF)都可 通过虚拟打印机转成rgo文档，然后在PPC上阅读，令人惊喜的是rgo文档无需任何附加字库即可支持中文，在PPC上用Repligo阅读rgo文档速 度也非常快，还支持自动断行。真是太酷了, 唯一遗憾的是使用自动断行时，Repligo有时断的不完全准确，这时可以用页模式辅助一下。