30多年了,微软连个dir也做不对

2013年04月25日 by admin

e:\corpus\cna>dir 2007*
驱动器 E 中的卷是 新加卷
卷的序列号是 9C42-6F41

e:\corpus\cna 的目录

2013-04-25 07:06 88,918 201107280355.aspx
2013-04-25 03:23 89,089 200911250343.aspx
2013-04-25 05:00 88,995 201006300345.aspx
2013-04-25 09:10 89,159 200708210265.aspx
2013-04-25 09:10 89,187 200708210266.aspx
2013-04-25 09:11 89,353 200708210267.aspx
2013-04-25 09:11 89,176 200708210268.aspx
2013-04-25 09:11 89,415 200708210269.aspx
2013-04-25 01:15 92,577 200808130354.aspx
2013-04-25 01:52 88,887 200903100353.aspx
2013-04-25 05:16 88,862 201009200341.aspx
2013-04-25 00:56 88,938 200806120359.aspx
……….

藏文有多少个字?

2012年07月7日 by admin

20120707初稿,20120708补充,20120714再次修订。

这个问题不难回答,但是我现在还回答不出来,因为没有足够大的语料库。

我把藏文字定义为一个纵向叠加单位,不管有多少层。有人称之为字丁,我嫌罗嗦,还是用字(字符)。

据卢老师说,现代藏文字的个数约360个。当然,我们现在需要处理的藏文还包括佛经里的古典藏文。

从一个小的分词语料库(4M)中统计出藏文字的个数是481个,字的总数962954个。

从一个大点的语料库(95M,也是来自卢老师,以下简称卢老师库)中统计出藏文字个数是1703个,字的总数33080574个。

从卢老师给的大藏经语料库(100M,以下简称卢老师大藏经库)中统计出藏文字个数是1214个,字的总数38172758个。

从我搜集转换的大藏经语料库中统计出藏文字个数是1728个,字的总数87911349个。

合并了卢老师库、卢老师大藏经库、青海新闻网、西藏新闻网的数据形成了一个稍大的语料库,共统计得到藏文字符总数是84596287个,其中不同的字是2342个。

合并了卢老师库、卢老师大藏经库、我的大藏经库、青海新闻网、西藏新闻网、一本词典、一个藏汉双语语料库的数据形成了一个更大的语料库,共统计得到藏文字符总数是178633697个,其中不同的字是2794个。

我们在上面计算的是用藏文的Unicode编码(也称为藏文编码字符集基本集)表示的不同藏文字的个数。藏文编码字符集基本集编码范围:U+0F00 到 U+0FD4。复杂的藏文字通过纵向叠加组合而得。一个藏文字对应一串变长的编码。基本集已足够表示所有藏文字。

说到了藏文编码,我们不得不提到除了基本集以外的藏文其他编码:

藏文编码字符集 扩充集A共有字符1536个,主要根据上述卢老师库的统计而定(卢老师说是张轴材从其统计的数据中减去了若干字)。编码在Unicode 0平面的私用区(PUA),编码范围:U+F300 到 U+F8FF。

藏文编码字符集 扩充集B共有字符5702个,编码在Unicode 平面A的辅助私用区(Supplementary Private Use Area-A in Plane 15)。编码范围:U+F0000 到 U+F1645。

注意,扩充集中一个码点对应于一个字符,和汉字编码类似,因此也称为预组字(precomposed character)。扩充集A和扩充集B都是国家标准,并不是国际标准,但是因为利用了Unicode的私用区,与unicode并不冲突。

采用扩充集的主要优点是简化排版和字符计算。但是因为扩B不在0平面,需要采用16或32位编码。其中,16位编码(UTF-16)可表示U+10FFFF以下的编码(实际为2^16-2^11+2^20=1112064个字符),32位编码则可以表示更多。32位编码最简单,但是浪费很多空间。

虽然引入扩充集的初衷是简化处理,但是实际上一个软件既要能处理基本集,又要能处理扩充集,反而使得软件更加复杂。对于纯藏文处理而言,当然可以先把所有基本集的叠加字符先转化为扩充集来进行预处理从而简化后续计算,但是这样做有一个前提条件,就是扩充集必须能表示基本集能表示的所有字符。目前我的猜测肯定是不行,否则也不需要扩充集C(我听说这个标准还在报批)了。当然,藏文处理软件并不只是处理藏文,所以这种预处理实际上是行不通的(见下文)。

我在网上查找藏文基本集和扩充集的有关资料时,发现了一些有用的信息:

以下2个网址可找到Unicode的藏文编码部分文档:

https://sites.google.com/site/chrisfynn2/home/tibetanscriptfonts/standarization/tibetanscriptintheucs

http://www.thlib.org/tools/#wiki=/access/wiki/site/26a34146-33a6-48ce-001e-f16ce7908a6a/tibetan%20character%20encoding%20proposals.html

我注意到后一个网址的表格中有一行为:N1095, 1994-09-xx, Proposal for encoding Tibetan script on BMP, China (Nima)。这个Nima应该就是尼玛扎西教授,他很早就参与了藏文编码标准化的过程。卢老师介绍说,以前网上有文章曾称他为“藏文IT之父”。可惜N1095这篇文章我在网上找不到。

我又在网上找到了Andrew West的系列博客。其中不但谈到了藏文编码,还有汉字编码。他的有关藏文编码的一篇博文的地址是:http://www.babelstone.co.uk/Blog/2006/09/precomposed-tibetan-part-1-brdarten.html。在这篇博文里面,他说道:

“The problem is that the Chinese government had never really bought into the decomposed Tibetan model. As far back as January 1994, when the encoding model for Tibetan was still under discussion, China submitted a proposal (N964) to encode Tibetan stacks as individual precomposed characters rather than as a sequence of combining characters, but this model was rejected in favour of the combining model.”

N964我也找不到。他又说道:

“Then six years after Tibetan encoding had been finalised, in December 2002, the Chinese national body submitted a proposal to encode nearly a thousand so-called “BrdaRten” (བརྡ་རྟེན, pronounced daden) precomposed stacks in the BMP at (see N2558, revised the following year as N2621, and further elaborated in N2661).”

也就是说,他不但认为中国是反对基本集的(早在1994),而且中国关于扩充集A的早期提案是被Unicode组织驳回的。但是我从别处看到,基本集是以中国为主提出来的。

我感到很疑惑。因为基本集和扩充集是两种技术路线。如果基本集是以中国为主提出来的,那么再提出扩充集就是自己打自己的嘴巴了。扩充集并不能表示出所有可能的藏文编码(包括梵文转写)。而如果两者并存,那么是一个非常糟糕的局面。藏文字的同一性都无法保证。对软件开发者而言,必须在处理藏文前进行从扩充集到基本集的编码转换(肯定不能反过来转换,因为印度的文字编码和藏文基本集类似,软件既然要处理藏文,没有理由不处理印度的文字)。这对全世界的软件开发者而言,增加了不必要的负担(国外的藏文处理软件如果不改,那么就无法处理中国的采用扩充集的藏文文档)。

我给Andrew West的博客留言,向他请求有关早期的藏文编码提案文档。他说他也没有。下面是他对我问题的一些回答:

我问:Who first proposed the current UCS Tibetan script?

他答:

China and UK both made proposals in early 1994:

N 964 Proposal for encoding Tibetan script; China; 1994-01
N 986 Proposal for Tibetan Script in the BMP; Bruce Paterson, Peter Lofting, U.K.; 1994.03.24

The Chinese proposal was discussed at the April 1994 meeting of WG2 in Turkey, with the Chinese proposal presented by Prof. Nyima Trashi of Tibet University (see N1033 8.4.3).

It seems that China initially proposed a set of 705 precomposed characters for standard Tibetan, and combining characters only for use in writing Sanskrit in Tibetan.

China worked with the Unicode Consortium over the following year, by email and in person at Unicode Technical Committee meetings in the US, to agree a revised encoding for Tibetan that used combining characters rather than precomposed characters. At the Helsinki WG2 meeting in June 1995 the joint China-Unicode code chart for Tibetan was presented, and further technical discussion took place (see N1253 6.4.5).

The result of this meeting was to task China and Unicode to work together to produce the final draft of the amendment (see N1254 M28.5).

A group of experts from China, Ireland and the UK (Nyima Trashi, DaWar Tsering, Tsering Choergyal, Michael Everson, Hugh McGregor Ross, and Mao Yonggang) worked together, and subsequently produced a joint proposed disposition of comments on PDAM6 (N1378), which was presented by China at the Copenhagen WG2 meeting in June 1996 (see N1353 6.2). The China-Ireland-UK document was accepted, and Tibetan was included in Unicode 2.0 released in July 1996.

显然,他这个说法和前面提到的他的博文有明显的不同。我后来在网上找到了WG2的所有文档,但是 N964 和 N986都没有。

我问:If China supported the dynamic stack initially, why on earth did they change their mind many years later?

他答:I don’t know.

我问:It seems to me totally meaningless and absurd … for China to make any sense, it must have objected to the USC encoding scheme from the very beginning.

他答:It did not. The UCS encoding model was developed by experts from China, Ireland, UK and USA, and the final code charts for Tibetan were produced by the China national body.

我说:Someone must be lying.

他说:I think it is not right to say anyone has been lying.

从这些问答里面可以明显看出,中国在藏文的Unicode编码(基本集)中起了关键作用。虽然Andrew West在前面提到的他的博文里对中国有负面的看法,但是他也不能否定基本事实。因此当我做出以下的总结时,他并没有表示反对:

我说:

1. China initially proposed both the precomposed and combining approaches.

2. China worked with the other bodies actively to finally decided on the combining approach. China is the main driving force in the standardization of the Tibetan in Unicode.

基本集的问题到此基本明朗。尼玛扎西教授在西藏大学,而扩充集的提出单位主要也是西藏大学工学院(http://baike.baidu.com/view/2444578.htm)。一个单位前后提出两种相互矛盾的编码,这是非常耐人寻味的。

我做出了一个没有根据的猜测,Andrew West对此发表了评论:

我说:Is it possible that the publishing houses in China actually were behind the scenes and they are so powerful in the government and so mean in technology that they lobbied the government for such a mad move? (原文笔误写成了It is …)

他道:Yes, I think so.

我猜测方正可能鼓动藏大工学院提出了N2558,Andrew West表示赞同。

平心而论,我觉得藏文基本集的编码的提出者是非常有智慧的。当然标准出来后10多年,微软才在OpenType中实现了藏文字形。而中国有名的北大方正,实现藏文印刷时,还是采用汉字的一字一码技术,虽然方正在国内响当当,但是实际上在技术上和国际大公司差距很大。其实,从基本集实现字符的纵向叠加,并没有那么难。微软花10多年,也许是人家没看到这个市场。

注:促使写这篇博文的藏文字(汉字)统计工具下载地址:http://59.77.21.82/mysoft/ccount.exe 注意只支持Windows 命令行下使用。

浅谈计算机安全

2012年06月25日 by admin

首先我要骂微软。从windows 95到windows 7,10多年了,微软的windows操作系统都是默认不显示文件的扩展名。这个假设就是用户都是傻逼,没必要知道细节,看个图标就知道了。其实图标没那么管用,可以容易地修改或伪造(比如exe程序的图标是自带的,可以容易地设成记事本的图标)。好了,我给你2个有意思的例子。第一个例子的是在至善书库中有个文件名“《女总裁爱上我》.txt.txt.txt.txt”。你觉得奇怪吧。但是你要在书库中找以.txt.txt的结尾的文件,那是一抓一大把。为什么?因为都是那些不显示扩展名的机器的用户改的。你告诉他找找“失恋33天.txt”,他说没有啊。的确,因为不显示扩展名,他机器只显示“失恋33天”,因此很可能就顺手再加个“.txt”。这样如果他把这个文件发给别人就变成“失恋33天.txt.txt”了。所以你可以大把地找到.pdf.pdf, .doc.doc之类可笑的例子。如果说这个例子只是浪费点时间和空间,那么下一个例子就是致命了。对于那些不显示扩展名的机器,假设看到的文件是“最美的母亲节的问候.ppt”,那是不是很可能打开看看呢?那么我恭喜你,你的机器很可能马上被格式化!为什么?很简单,这个文件的真正的文件名可能是“最美的母亲节的问候.ppt.exe”!因为万恶的windows隐藏了扩展名!所以这个windows的傻逼特征,客观上助长了病毒和木马的传播。很可笑的是,这么多年过去了,一直没改。反而从vista起弄出个用户帐户控制(UAC),简直是莫名其妙,狗屁不通!要是开着,让用户烦不胜烦,而且还导致了很多问题。为什么很多用户选择用xp?因为这个UAC,很多在xp能做的事情在windows 7 做不了!

其次,很多常用的软件是不安全的,比如最常用的ie可以运行activex,导致严重的安全隐患;比如word可以运行宏,导致宏病毒的传播;甚至adobe的pdf reader也是不安全的!因为它打开某些pdf时,会不经过你的同意连网!所以你千万不要用ie,少用word。最好用txt。凡是支持在文件中可以内嵌具有访问本地资源权限的代码的软件都是不安全的。

最后,我要劝你一句,不要用大陆产的任何非开源的安全产品,典型的如360、金山等。至于QQ,迅雷等,一样非常不安全。我就是要一棍子打死,这些软件都是某种程度的木马。你要看一个单位的安全意识强不强,就看它是否安装了360。凡是安装360的,网管都是人家把你卖了还帮数钱的弱智。

关于至善读书的拒绝服务攻击问题

2012年06月20日 by admin

今天偶尔看到一个网页:http://www.securityfocus.com/archive/1/522696 是Symantec的Security Focus,里面提到了Universal Reader (至善读书),关键部分如下:
Title: Universal Reader Filename Denial Of Service Vulnerability
Software : Universal Reader
……
Bug Description :
Universal Reader is a online/offline reader for reading polytype e-book files.
Universal Reader contains any denial of service vulnerability about openning long-name files. Success in exploiting this vulnerability will crumble uread.exe process.
接着提供了一段perl代码,如下:
———————————————————–
#!/usr/bin/perl -w
$filename=”a”x129;
print “——Generate testfile \”a\”x129.epub——\n”;
open(TESTFILE, “>$filename.epub”);
sleep(3);
close(TESTFILE);
print “——Complete!——\n”;
exit(1);
———————————————————–
这段代码的目的就是生成一个aaa….aaaa.epub这样的0字节文件(129个a)。代码中的sleep(3)纯粹是浪费时间,不知道有什么莫名其妙的目的。此段代码的作用也可以用一个简单的dos命令来替代:echo >aaaaa….aaa.epub (你想加几个a都行,只要不超过250个)

好了,我现在来说明一下。

这的确是至善读书的一个bug,不能打开0字节的epub文件。(其实能打开!当然打开后是一个空文件,但是打开后你只能按Esc退出,不能做其他事)这个bug和长文件名毫无关系。这个bug也和denial of service 毫无关系。denial of service 是指某个网站服务因为受到某种攻击而无法提供正常服务,说这个bug是 denial of service 是文不对题。你拿一个烂epub文件,不能打开是正常的,能打开才奇怪了。错只是错在uread没给出适当的错误信息。

因此,这个安全贴的作者(demonalex@163.com / ChaoYi.Huang@connect.polyu.hk)的技术水平大家可以看清楚了。

问题当然不止于此(否则就没必要写这篇博客了)。上面的安全贴是20120512发布的。在20120522,一个自称是国家互联网应急中心的人要求加入至善读书测试群,说至善读书不能打开长文件名文件,存在拒绝服务攻击问题。我一听就觉得很疑惑。不能打开长文件名文件,肯定是不存在的,当初在整理藏文大藏经时,文件名都相当长,只是连windows都无法处理超过256个字符的长文件名,因此限制了文件名不超过240个字符。至于拒绝服务就更是莫名其妙,至善读书会去攻击至善读书服务器?自己攻击自己?笑掉大牙,我当时认为这是一个骗子,打着国家互联网应急中心的名义来行骗的,说了几句就把他踢出群,并且拉入了黑名单。这年头,三十六行,骗子为王,网上骗子满地走,不得不小心啊。

紧接着,我的QQ莫名其妙就不能用了。我当时猜测和这个“骗子”有关,也罢,那个QQ不用就不用了。

直到今天,偶尔看到 demonalex 的这个帖子,我才知道,那个人不是个骗子,只是把demonalex的烂帖子拿来说事。他还给我发了个邮件,说我得赶紧解决这个漏洞,当时我根本就没处理。直到今天看到 demonalex 的帖子才更新了至善读书的版本(到1.29.807)。我现在把这个邮件的附件“URead阅读器拒绝服务漏洞.doc”贴在这里,大家看看。

这个附件里把epub写成了“upub”,说明对epub是什么毫无所知。里面说可以把长文件名文件上传到至善读书服务器,造成拒绝服务攻击,更是匪夷所思。小弟,你试试看哦,看看能不能造成DOS攻击哦!

原始作者就那个水平,你这抄来的水平更是不堪,我为国家互联网应急中心汗颜,你好歹也弄几个会读书的啊。

不过,还是要真心感谢他们发现了bug,虽然这个bug和安全毫无关系。

相关链接:http://www.cnvd.org.cn/publish/main/47/2012/20120529090224831350637/20120529090224831350637_.html

婺源的茶

2012年04月17日 by admin

婺源四绝,“绿”,“黑”,“红”,“白”,无疑绿茶排首位。穿行于婺源诸乡村,满眼所见,尽是茶蓬。好茶产于深山,在婺源之北,海拔1600多米。不过最好的头道茶,说是专供领导同志享用,是为贡品。二道茶,为当地干部待客之用。市面所见,估计都是三道以后了。

下面是婺源博物馆里面几张茶的照片:


后来在西溪,看到一位老农在手炒茶叶(你说烫不烫?):

我还拍了一段录像,不过有150M,建议你把视频url贴到vlc进行在线播放:
炒茶视频

在linux和mac机上访问至善书库

2012年04月14日 by admin

1. 目前至善书库有个stanza的接口。但是只有ipad/iphone的stanza支持这个接口。
2. linux和mac上可以用firefox来阅读epub,但是需要安装一个addon:EpubReader。效果不怎么好,和至善读书windows版根本没法比,只能凑合了。
3. 安装好EpubReader后,直接在网址输入 http://uread.superfection.com/log/stanza.cgi?p=1000,即可访问至善读书用户上传的最近新书。每天来看看,可能会有不同的收获。
4. 至善书库本体,暂时无法用这个办法访问。

自建有声书库

2012年04月10日 by admin

用至善读书1.24.785版可以不用下载即可听网上自建的有声书库。建库的办法很简单,就是把一些mp3链接放在一个页面即可,只要这些mp3可以直接访问,也不一定要在你自己的网站。如下面我简单传了几个mp3文件:
【品读时分】《15位名人给大学生的34个人生指南》1.mp3
【品读时分】《15位名人给大学生的34个人生指南》2.mp3
【品读时分】《15位名人给大学生的34个人生指南》3.mp3
【品读时分】《15位名人给大学生的34个人生指南》4.mp3
【品读时分】《15位名人给大学生的34个人生指南》5.mp3

用至善读书的内嵌浏览器打开这个博客,然后点一下你要听的mp3就可以了。因为不用下载,节省了你的硬盘空间。

个人自建书库

2012年04月7日 by admin

这个很简单,就是把epub等书籍上传到服务器(如没有自己的服务器,可用免费的dropbox)上,然后加上链接就可以了。比如下面的个人书库只有两本书:
Theft Of Swords: The Riyria Revelations
35岁前要做的33件事
用至善内置的浏览器打开这篇博客的网址,点击两本书的链接就能阅读。目前支持的书籍格式有epub,ubk,.umd,djvu,pdf等。

企业自建书库

2012年03月30日 by admin

现在很多单位,尤其是学校,都有自己的图书馆、图书室、或阅览室。信息化比较好的单位都有数字资源,至少也有很多电子文档。这些文档分散在各个电脑里面,查找、阅读、管理多有不便。尤其是很多图书馆,投资购买很多数字资源,但是使用不便(基本都是采用浏览器访问),还要专人管理维护,效益极低。

其实可以用至善读书,配合至善读书服务器来自建自己的书库,供全单位的人阅读,并可设置不同访问权限。投入很少,不需要专人维护,查找资源方便,界面友好。

以下是一个截图,自建书库为”计算机库

这样是不是很方便呢?

采用至善读书建立一个200万册电子书的数字图书馆只要1个小时!有意给自己单位建立电子书库者请联系博主。

新浪博客的堕落

2012年02月6日 by admin

我一直不喜欢新浪。打个不好的比方,就象个吵闹拥挤的集市。今天为了看韩寒的博客,发现了一个好玩的事情。大家看一下韩寒的这篇新浪博文(这里是这篇博文在20120206的一个备份,以防止新浪删除证据, 一共740868字节)。你在你的浏览器里应该只能看到并搜索到“大家都知道方舟子”的一次出现。但是你在其html源代码里面可以搜索到36次出现(注:用Chrome查看源代码和搜索其中的字符串特别方便),好玩吧?

这样做的后果是,新浪博客的页面字节数要多上很多倍!传输速度要慢很多倍!当然这种做法不是新浪的发明,一些小说网站早就这样做以给搜索引擎之类软件找点麻烦(记忆中2年前的晋江文学城就是如此做的)。这也叫数字水印?还有大网站向小网站这样看齐的。

如果我们把多余的重复删除,则可以把 740868 字节减少到 86754 字节(这是删除多余内容后的网页,内容一样!), 差不多减少9倍吧。注意这肯定不是最精简的版本。(我只是用EmEditor 把 <span class=’MASSf21674ffeef7′>.*?</span> 替换为空,注意要先设置.可匹配换行符)

你觉得是不是新浪博客有点自己搬起石头砸自己的脚呢?