中文乱马大全

telnet://bbs.tsinghua.edu.cn

http://bbs.tsinghua.edu.cn

http://www.tornado.be/~johnfg/

http://www.cis.ohio-state.edu/~fine/rot13.html

[email protected]

http://otto.cmr.fsu.edu/~davis_t/rot13.cgi

http://as.alliancestudio.com/tk/rot13.html

http://www.rtg.se/~niclas/reddwarf/rot13.htm

telnet://bbs.tsinghua.edu.cn

http://bbs.tsinghua.edu.cn

vJ9SCHm<~9}3LVPSv5=5DJ5 ~{NJLb!#1>NDT-TXSZK.D>Ge;*~} BBS~{5D~} Internet ~{LVB[Gx!#5XV7JG#:~}
telnet://bbs.tsinghua.edu.cn ~{#,~}WWW ~{7CNJ5D5XV7JG~}
http://bbs.tsinghua.edu.cn~{!#~} ~{51OBCf5DLu<~H+2?BzWcJ1#,W*TX~}

~{1>ND?IRT2;>-9}WwU_TJPm#:~}(1) ~{W*TXK.D>Ge;*~} BBS ~{5DPEM7#;~}(2)

~{2;P^8DT-ND#;~}(3) ~{W*TX=vO^SZ8wVV~} BBS ~{:M7GILR5PTVJ5D8vHKMx5c!#~}
~{QO={8wVVPNJ=5D3-O.#,QO={7GWwU_=+1>ND;r>V2?SCSZHN:NU}J=3v~}
~{0f5D?/No!#1>WTH;6NJGH+ND5DR;2?7V!#~}
很多海外中文杂志，如著名的《华夏文摘》( http://www.cnd.org )等都仍
然采用 HZ 编码方法。HZ 编码用额外的控制序列来控制字形的显示，字母和数
字是不被编码的，它们在 ~{ 和 ~} 标记对的外面。这种编码不符合汉字与文本
字符的固定映射规律，处理起来相对麻烦。著名的汉字平台──南极星 ( NJWIN
1.6，http://www.njstar.com ) 对HZ 提供了灵活和强大的支持。
海峡两岸的语言经过长期的发展，实际上已经不能形成一一对应的关系，GB
和BIG5的转换也是如此。因此这种转换往往具有不可逆性，倒不是说一段文字不
能在 GB 和 BIG5 之间互相转换，而是说一旦你转换错了，信息就不能复原。比
如你拿一段本来的是 GB 的文字当作 BIG5，然后再实施 BIG5 -> GB 的转换，
就会损失信息，这时逆变换将不能完全得到原来的文字。比如 SMTH WWW 发文时，
本是 GB 的，错选了 BIG5 按钮就会如此，反之也类似。
汉字的另一个问题是所谓的“半个汉字”乱码，由于很多英文编辑软件以字
符为单位来处理文本，汉字被删除一半后，剩余的部分会和相邻的汉字重新组合，
使得文本面目全非。因此，除了注意在输入、删除的时候注意这种问题外，还要
注意不要在英文字处理软件中轻易使用“字符替换”功能，这往往会把一个汉字
的后一个字符和相邻汉字的前一个字符当成一个汉字被替换掉。这种乱码最后往
往令人莫名其妙、找不到原因。
需要说明的是，简体和繁体这两个概念和GB、BIG5并没有逻辑上的联系，GB
的定义是简体字，BIG5采用的是繁体字，但是为了阅读的方便，在各自的编码中
再做一个内部字形或字体的映射，就形成了所谓 GB繁体或 BIG5简体之类的概念，
他们仅仅是一些汉字软件提供的方便功能，如南极星等。我们常见的WWW 浏览器
Microsoft Internet Explorer 4.x 和 Netscape Navigator 4.x 都已经内置了
比较完善的汉字转换功能。加装了语言包的 IE 4.0 还使得我们脱离汉字平台也
可以进行中文处理，并且可以处理大字符集 GBK 。详见Win95_win3.x 讨论区中
“让Pwin95更顺手”系列之(11)。
在中文平台上，很多人有不同的见解。本文的主旨与此无关，仅仅是综合各
个方面的因素，我个人向计算机的初学者建议选择中文 PWindows 95 OSR2 或更
高的版本作为最基本的操作环境。中文之星 ( http://www.chinese-star.com 、
http://www.suntendy.com/ ) ，四通利方Richwin( http://www.srsnet.com/ )
等由于技术和企业行为的不稳定性，不适合作为具有依附性的中文平台。但是这
些软件中的局部，如新拼音输入法、支持剪辑板的码转换器等还是具有一定特色
的。如果有对这个问题感兴趣的讨论，请到Chinese 板搜索以前的标题继续讨论。
在 Chinese Community Information Center (CCIC)，集中了一些中文处理
的比较完整权威的解决方案，该网点地址是 http://www.ifcss.org/software ，
其中包括了各种操作系统、各种汉字编码的处理方案和软件。
除了常见中文平台外，通过 http://www.shareware.com、
http://www.download.com 、http://www.hotfiles.com 等共享软件网点，查询
GB、BIG5、chinese 等关键字可以获得大量的小型应用程序，包括码转换器。尽
管如此，本文还要重点推荐一些用于 DOS 的命令行处理工具，具有使用方便、
可以进行批处理等特点。他们是：
c2t (将 GB 或 BIG5 转化为拼音)
HZ (gb2hz hz2gb zw2hz)
(convert gb to hz, hz to gb, zw to hz respectively)
hc (convert between GB and BIG5)
下载地址为：
http://ftpsearch.ntnu.no/cgi-bin/search?query=c2t.zip
http://ftpsearch.ntnu.no/cgi-bin/search?query=hz-20.zip
http://ftpsearch.ntnu.no/cgi-bin/search?query=hc-30.zip
其他软件请到 http://www.ifcss.org/ftp-pub/software/ 查找。另外，GB
和 BIG5 属于两个不同组织各自制定的标准体系，对应汉字编码的转换都是通过
表格来转换的，他们之间不存在任何内在的逻辑关系或函数，试图寻找这种公式
的人，请不要白费精力。
几乎所有新生的软件在中国使用都会面临一个汉字兼容的问题，比如新生的
Java 及其开发环境、动态HTML领域等都从未幸免。通过NT的资源存取能力可以
实现英文软件的界面/资源汉化，由于 PWindows 95 对话框的缺省宋体的大小为
9 磅，而英文 Windows 95 的相应值为 MS Sans Serif 8，所以很多英文软件在
PWindows 中运行时，界面中的字残缺不全，这些也可以通过资源的重新编辑予
以调整。
但是，软件内核的汉化不是可以轻易实现的。即使是厂家做的汉化工作也有
非常粗糙的痕迹。比如 P-IE 4.0 在安装繁体汉字包后，PWindows Help 就产生
了内码的混乱。这就是个严重的 Bug。有时只能随意选出一个具体的条目弹出帮
助窗口，再反过来调出帮助主题窗口，偶尔还可以对付使用。或者你就再运行一
份 NJwin，在 Option 中选择 Standard English/Western 。其实这一招在以前
讨论 OutLook Express 看 BIG5 邮件的时候就用过了，也是个乱码的问题，详
见 Win95_win3.x 讨论区精华区中的 “让PWin 95更顺手(9)─南极星与OutLook
Express”。

----------------------------------------------------------------------

乱码大全(4)──BBS与ANSI

ANSI (American National Standards Institute ) 规定了一组控制字符和
键盘的扩充规则，本文不作为使用 ANSI 彩色和位置控制在 BBS上进行应用的初
级指南。这方面的内容参见 BBSHelp 和 ASCIIart 板及其精华区。
很多 BBS 的 WWW 版本在文本转换的时候没有解释 ANSI 的效果，而是把控
制符号 01Bh 解释成为 * 号，这就形成了阅读 BBS 文章的特殊乱码效果。比如：
*[1m (高亮度字)、*[1;5;33m (高亮度黄色闪烁字)、*[1;31;44 (高亮度蓝底红
色字) 等等。
目前，国内的著名 BBS，水木清华、网易、蓝天等站的 WWW 转换程序都已
经解决这个问题。在 Telnet 中发表文章可以使用 ANSI 控制，利用 MS-DOS 的
Help 可以获得 ANSI 字符控制的详细信息。(如 C:\\DOS>Help ANSI.SYS)。在使
用位置控制的时候，应该尽量使用 ESC[s 和 ESC[u (存储和恢复光标位置)来控
制文本，以免发生位置错乱，并尽量在每行结束的时候恢复默认的属性，以免因
为翻页而造成ANSI控制的不完整。
NetTerm 有那么点不太引人注目的小秘密，这就是它自己支持一些类似Ansi
控制的扩充控制序列。曾经作为一个调剂的手段，为上 BBS的网虫增添了不少乐
趣。随着清华 BBS 上的一些网虫不断“露一手”，现在全国很多 BBS 都使用了
这些扩充的控制来修改标题栏、状态栏，来表示对网虫的问候。如北方交大、
网易……。NetTerm 的扩充序列参见它的Readme文件或Virus 精华区“反病毒与
黑客/工具/趣闻”目录下面的摘录。
Ansi 作为标准字符的一种扩展的表现手段，起到了丰富色彩，活跃气氛的
作用，这些作用的效果会随着阅读一篇文章的结束而结束，而很多扩展控制却可
以留下来，改变你的标题栏状态栏，甚至打开你的浏览器，乃至死机。 Netterm
在解释自己创立的扩充序列的一些 Bug也很明显地表现了出来，同时，还有很多
终端程序在解释控制序列的时候，程序不够严密，对于非标准的序列往往会产生
意外的后果。利用程序编制上的缺陷，采用类似 Ansi 序列的方法激活这些 Bug，
这就是我们这里说的所谓“BBS ANSI 炸弹”。
扩展控制序列的滥用，引起了 BBS上的一些争论，很多人表示反感。谁当初
会想到围绕这个问题会有这样多的故事呢。不过我们今天不得不通过一种管理的
手段来制约它，这一方面说明完整的管理制度是维护一个全局的必要手段，同时
也说明在网络这个苑囿中，自觉二字还远没有达到理想的程度。经过不太长时间
的讨论，终于有了结果。就是最终由 Leeward 站长修改 BBS 软件，把扩充序列
的解释权交给用户，允许用户从个人参数设定中禁止这些效果。详细的信息请参
考sysop 板的讨论，以及最后 Leeward 公布的解决办法。

----------------------------------------------------------------------

乱码大全(5)──UUENCODE

UUENCODE 在我们水木清华 BBS 已经讨论得很多了，关于 UUENCODE 的详细
内容参见水木清华 BBS Virus 和Hacker 精华区中的“UUENCODE/decode 知识与
使用入门”(一)～(四)。这里只简单提一下并作一些补充。 UUENCODE 的 UU 指
用于 Unix 之间传送二进制文件，就是 Unix to Unix。在Email 或 News 中
UUENCODE 经常用于 Attach 二进制文件。目前不仅Netscape、Eudora、MS-mail，
甚至包括 Hotmail、usa.net之类的 Webmail 在内的绝大多数email程序都支持
UUENCODE 的自动解码。在一些软件网点，如 http://www.shareware.com 等，
可以找到 UUENCODE 的源程序。
UUENCODE 代码有下面的样子：当软件不能自动解码(如在telnet中访问BBS)
时可以转寄到 email 中或通过剪辑板将 UUENCODE 代码存入文本文件，改文件
名后缀为 UUE，然后通过 Winzip 解码。
begin 666 test.zip
M4$L#!!0````(`)%]0B2`HV;;&P$``$8!```(````=&5S=\"YT>\1=C\\%.PD`4
M1? M)AI;HL\(R$J7[^7<^\\X#``#8 M9ALT&B=`@S=VR-U\;]-;\\U(?,Q4BU::D6F$*FZ7S/S`FX+C9DBZ:4FN?@0BK
MD3MZPB3\\N/OV.YKC?N:K0-QLL]F^QQDG3#-MY78K/%@0OR\"C=E`\@OC7\M]/
M!\\BL\=8U,UX,\"5,HV8U\@MWYS*PB6J3S8(#)L/`GTPU>
M000>(NM+4#$-+$QT)>HB6>P&7EY6*]G2Z@@S\\\\WFFI..TKE/#9IM`TLO>KM/
……
……
MG&OZ\"M$/4$L!`A0`%`````@`D7U\")(\"C9ML;`0``1@$```@````````````@
E`+:!`````\1E `
end
由于 UUENCODE 的编码中有小于号“<”，和某些 HTML 标记会造成冲突或
歧义，因此，在 BBS 中出现的 UUENCODE 代码，通过 BBS2WWW 程序被 WWW 用
户阅读的时候，会得到混乱的不正确的结果。除非 BBS2WWW 程序做相应的修改。
但是这些修改一般是针对 HTML 标记，因此可能不会考虑周全所有的可能情况。
因此，即使是目前的水木清华 BBS 也没有完全解决这个问题。从 WWW 直接阅读
文章或下载精华区都会出现 UUENCODE 代码出错的情况，目前还没有很好的解决
方法，只能从 telent 上站，直接阅读文章。
用 UUENCODE 传送文件经常用于 ftpmail 或其他传送较大文件的场合，这
个时候往往是将 UUENCODE 编码后的文件切成小块再传送。所以在编号为第二、
第三……的 email 中，我们会见到没有“begin ………”开头的 UUENCODE代码。
(UUENCODE 代码除了最后两行外每行都是以字母 M 开头的)。接收这类 email，
最好不要使用 Eudora，因为 Eudora 会将 Attached 文件恢复成二进制文件并
存放在另一个目录里。对于分成多块传送的 UUENCODE 代码， Eudora 会将这些
代码的第一部分恢复成文件──显然这是个不完整的东西，后面的就不管了。这
会妨碍后面你人工合并这些邮件。很多人使用 The_bat 这种邮件程序，它对
Attached 文件是恢复到目录中还是留在信体中，是有一个选项可以选择的，在
这种情况下也要注意正确的选择。

----------------------------------------------------------------------

乱码大全(6)──MIME/BASE64介绍

MIME: Multipurpose Internet Mail Extensions
英国帝国大学计算机在线字典FOLDOC对 MIME 的解释为：“多部分( multi-
part)、多媒体电子邮件和 WWW 超文本的一种编码标准，用于传送诸如图形、声
音和传真等非文本数据。MIME 定义于 RFC 1341，用 MIMENCODE 的方法将二进
制数据转换成为一种被称为 BASE64 的 ASCII 子集的字符的组合。”
Internet 上有专门讨论 MIME 的新闻组：comp.mail.mime。该新闻组的FAQ
可以从下面的网点获得：
http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/mime0/faq.html
MIMENCODE 最早称为 MMENCODE，提出用 MIMENCODE 代替 UUENCODE，是因
为 UUENCODE 使用了一些字符在一些邮件网关(特别是那些转换ASCII 和 EBCDIC
码的网关)中造成传输障碍，(还有一些软件不能对所有 UUENCODE 的算法进行正
确解码而导致邮件的阅读困难)，因此 MIME 被设计用于替代 UUENCODE，但是结
果是这些协议共存。
MIME/BASE64 的算法很简单，它将字符流顺序放入一个 24 位的缓冲区，缺
字符的地方补零。然后将缓冲区截断成为 4 个部分，高位在先，每个部分 6 位，
用下面的64个字符重新表示：“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop
qrstuvwxyz0123456789+/”。如果输入只有一个或两个字节，那么输出将用等号
“=”补足。这可以隔断附加的信息造成编码的混乱。这就是BASE64。
那么 MIME/BASE64 是什么样子呢？通常很多程序都做成每行70-80个字符，
由于我们前面已经说了组成 MIME/BASE64 的编码是 A-Z、a-z、0-9、+ 和 /，
那么这个编码很容易认出来，如：
UEsDBBQAAgAIAEapPiS/mrkHoQEAAEECAAAMAAAAYWNhZDd+dWUudHh0dVFRb5swGHyPlP9Q5Iet
TUICzCUJASTiFuIQhwbHRJnUqmRsndqmVQO0CsK/fXbRVvVh+AV9vrvv7txunYiPV8rAW3n33w5B
R9FAN3ld34Axr9OHIjtkt7wC3bmKHD+zznjteTGvjBnVFGCdxz265XW7dfI+ZVFyRjegO3hix8nl
fGcdjeLqy/rGTp0Sj+Jp8Djho9oIWRSX0IYIwwmWbF4RHKYK0ByCaI9u4u3HukYZIvE32+fZyz7L
含有 MIME/BASE64 编码的邮件，你查看它的源码时，一般都含有：“This
is a multi-part message in MIME format.”这样的句子。也可以被绝大多数
的 email 程序进行解码，包括 Netscape、MS Mail、Eudora等。这些程序可以
正确识别邮件的正文，恢复 MIME/BASE64 编码的部分为正确的文字或夹带的二
进制文件。
如果这些文件不能正确被恢复，可以将邮件原文存成文本文件，改文件名后
缀为 .UUE，让 Winzip 自动识别并恢复。推荐使用 Winzip 6.3 SR-1 或更高的
版本。也可以将文件后缀改为 .EML , 由 Microsoft Mail 或 OutLook Express
打开，该软件也可以自动解码。另外很多网点，如 http://www.shareware.com 、
http://www.download.com 、 http://www.hotfiles.com 、
http://www.alberts.com 等都可以通过查询 MIME 关键字得到大量的小型应用
程序支持 MIME 的转换。

----------------------------------------------------------------------

乱码大全(7)──MIME/BASE64处理实例

但是，即使是正确的 MIME 编码也可能因为文本格式不规范而不能正确解码，
这个时候，你从 email 程序或 Hotmail 里面只能得到 BASE64 编码的乱码，而
不能正确解码。我们在 Pwindiws 95 中推荐使用 UltraEdit 5.0，并以此为例
来讲处理过程。我们来看这样一封典型信：( 行号是为阅读清楚，不属于信的内
容)。这封信是根据我帮助一个朋友解码的实例改的。
01: From: \"bluesea\" <[email protected]>
02: To: \"=?gb2312?B?sKLEvg==?=\" <[email protected]>
03: Subject: A test :)
04: Date: Sat, 3 Jan 1998 15:31:38 +0800
05: X-Mime-Autoconverted: from 8bit to BASE64 by ms1.inet.tw id PAA06553
06: Content-Length: 222
07:
08:
ICAgIKGwwtLC67TzyKuhsaOs1/fV36O6Ymx1ZXNlYaOsy67Evsflu6pCQlOzydSxoaO7ttOt1Nog
09:
QkJT1tDXqtTYo6yw7w0K1vq8xsvju/qz9dGn1d+94r72yrnTw8jtvP65/bPM1tDT9rW9tcTKtbzK
10: zsrM4qGjsb7OxNSt1NjT2suuxL7H5buqIEJCUw0KtcQgSW50ZXJuZXQgzNbC28f4oaO12N
这封信不能通过 OutLook Express 和 Winzip 恢复，当然，我们还可以找
其他程序，或者其他的 email 程序自动恢复信的内容，我们假设这些条件不符
合，需要适当的手工恢复。我们能够认定信体是MIME/BASE64 编码，那么一定可
以找到相应的解决办法。首先备份你的信。然后进行下面的处理：
第一种方法，我们可以把原信的5、6两行换成下面的两行，注意第4、5行之
间不要有空行。
Content-Type: text/plain;charset=\"gb2312\"
Content-Transfer-Encoding: BASE64
然后将文件名后缀改为 EML，再由 OutLook Express 打开。如果不是 GB汉字，
而像是 BIG5，只需将 \"gb2312\" 改为 \"big5\" 再试验。如果你最终认定不是文
本，而是二进制文件；或者是明显的二进制文件，email 程序却不能还原成夹带
(Attached) 的文件，那么需要将信件中的 “Content-Type: text/plain;” 改
为 “Content-Type: application/x-download;”。
第二种方法，假如没有 OutLook Express，我们还可以借助 Winzip 6.3。
你只需在原信中，在 MIME 编码的那三行中间的任意位置加一个回车，把它搞成
四行，然后将文件后缀改为 UUE，再用 Winzip 6.3 打开。信体就会被正确解码。
说起来你可能不相信，觉得这个方法闻所未闻，像天方夜谭。这方法连我自己都
不信，但是实践证明是有效的。
最后，还差一点，就是原信第二行的内容：To: \"=?gb2312?B?sKLEvg==?=\"
<[email protected]>，这信是发给谁的呢？这是 email 程序中在标题运用 MIME/
BASE64 编码的例子。我们请南极星 NJWIN 出山。NJWIN 1.58(1.6) 的 Option
有这样一项：Support Internet MIME encoding，选中此项，即刻可以看到中文。
在 Pwindows 95 中，如果用 Notepad 或选择了GB2312字体的 Ultraedit来
看信，那么，请不要选中 NJWIN Option 中 My Windows System - Simplified
GB 一项，而选择 Standard English/Western。这样的目的是让 NJWIN 的汉字
显示起作用。可以看到收信人这一行是：“To: \"阿木\" <[email protected]>”。

----------------------------------------------------------------------

乱码大全(8)──Quoted-Printable

先认一认，一定很熟悉了，常见的被称为乱码的东西。经常出现在email中，
这就是 Quoted-Printable，是 MIME 的另一种编码方式。
=A1=B0=C2=D2=C2=EB=B4=F3=C8=AB=A1=B1=A3=AC=D7=F7=D5=DF bluesea
=A3=AC=CB=AE=C4=BE=C7=E5=BB=AABBS=B3=C9=D4=B1=A1=A3=BB=B6=D3=AD=D4=DA
BBS=D6=D0=D7=AA=D4=D8=A3=AC=B0=EF=D6=FA=BC=C6=CB=E3=BB=FA=B3=F5=D1=A7
=D5=DF=BD=E2=BE=F6=CA=B9=D3=C3=C8=ED=BC=FE=B9=FD=B3=CC=D6=D0=D3=F6=B5=BD
=B5=C4=CA=B5=BC=CA=CE=CA=CC=E2=A1=A3=B1=BE=CE=C4=D4=AD=D4=D8=D3=DA
=CB=AE=C4=BE=C7=E5=BB=AA BBS =B5=C4 Internet =CC=D6=C2=DB=C7=F8=A1=A3
在所有邮件处理的各式各样的编码中，很多编码的目的都是通过编码手段使
得七位字符的邮件协议体系可以传送八位的二进制文件、双字节语言文字等等。
Quoted-Printable 也是这样一些编码中的一个，它的目的同样是帮助非 ASCII
编码的信件传输通过 SMTP。Quoted-Printable 编码是字符对应的编码，每个未
编码的二进制字符被编码成三个字符，即一个等号和一个十六进制的数字，如
“=A8”。1:3，这种编码效率实在很低。有关 Quoted-Printable 详细技术信息
可以参考 RFC 2045。
一些 email 程序，它们不能正确解释这种编码。最方便的方法是使用 (如
Forward 到) 支持Quoted-Printable 解码的 email 程序如 Netscape、Eudora、
OutLook Express 和 Calypso 2.4 等。Calypso在将邮件另存成纯文本的时候，
甚至全都采用的是 Quoted-Printable 格式。 Winzip 仍然是最方便的解码工具
之一。
用 Winzip 对 Quoted-Printable 解码的关键有两条：(1) 在email 信头中
检查、添加这样的两行，如果没有信头，那么这两行就构成信头，比如这两行可
以添加到本文开始的那段例子前面。
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
(2) 信头中间不要空行，信头和信体之间要有一个空行。这样形成的文件，改后
缀名为 UUE，即可双击启动 Winzip 得到解码。email 中的标题或收发信人等信
头位置带有的 quoted-printable 编码都可以被一起解决。满足上面条件的信件
也可以改后缀名为 EML, 用 OutLook Express 来解码，类似这样的标题：
Subject: =?gb2312iso-8859-1?Q?=D4=DA=C7=E5=BB=AA=B5=C4BBS=C9=CF?=
Subject: =?gb2312?Q?=D4=DA=C7=E5=BB=AA=B5=C4BBS=C9=CF?=
也可以被 OutLook Express 正确复原。
与 BASE64 不同的是 Quoted-Printable 编码不处理原文中的换行，因此要
注意一个汉字是由两个字符组成的，会对应于 Quoted-Printable 编码的六个字
符，如果经过重新编辑并且换行不当则会造成半个汉字的乱码，需要相应调整。
除此之外，还有很多方法用于解决 Quoted-Printable 的解码，例如著名的
Quick View Plus 4.5 ( http://www.inso.com ) 也支持 Quoted-Printable 的
解码和直接阅读。有些网点以在线 CGI 方式提供Quated-printable 解码，例如：
http://cactus.aist-nara.ac.jp/~yosita-h/jap/quote.html
在Unix中，被 BASE64 或 quoted-printable 编码的邮件可以用metamail等
方法来解决。下面这份程序是本 BBS 的 jyj 编写的，现在收录在 Networking
板的精华区中，用于quoted-printable解码，适合于 Unix/DOS/windows。本文
引用时对源程序的版式做了一些调整。
#include
void main(int argc, char * argv[])
{
FILE * fp; char ch, ch1, ch2; unsigned char hz;
fp = fopen(argv[1], \"rt\");
for (;;) {
ch = getc(fp); if (ch == EOF) break;
if (ch == \=\) {
ch1 = getc(fp); if (ch1 == \\\n\) continue;
ch2 = getc(fp);
hz = (ch1>\9\?ch1-\A\+10:ch1-\0\)*16+
(ch2>\9\?ch2-\A\+10:ch2-\0\);
putchar(hz);
}
else putchar(ch);
}
fclose(fp);
}
在 http://www.kobira.com.jp/sakura/d_net_mail.htm 可以获得 Quoted-
Printable 编码和译码的 Pascal 源程序。很多支持 MIME 编解码的程序都提供
了 MIME BASE64 或 Quoted-Printable 的源程序。

----------------------------------------------------------------------

乱码大全(9)──中文HTML与Netscape(第二版)

乱码大全(9) 的第一版发于 BBS 水木清华站 (Tue Feb 3 01:04:01 1998)
Internet 信区，现对原内容做一些补充。
一个好的中文网点，应该能够做到让大多数浏览者能够舒服地阅读网页，退
而求其次应该是让访问者可以读懂。但是，中文 Web 的浏览环境是一个复杂的
多维空间。对于上面的要求，即便是后者也并不是每个网点都做到了。为了迁就
系统功能的某个设置，往往会忽略另一个设置，网点的设计者需要从很多选择中
进行折衷。
中文 Web 的浏览环境这个复杂的多维空间的组成是什么呢？我想至少包括
这样几个因素： (1) 操作系统及其版本、语种；(2) 中文平台的种类； (3) 浏
览器的品种及其版本。由上面的几个因素相互组合，可以形成几十种浏览环境，
它们在浏览同一个网页时的效果都会有所不同。我们有理由认为：由中英文
Windows95/NT、常见中文环境(NjWin、Cstar、Richwin)和常见浏览器(Netscape
3.x/4.x、中英文IE3/4)构成了中国 Web 访问的主要浏览环境。
顺便说一句我们曾经多次提到的一个问题，很多网页的设计者都在追求中文
文本的自动折行，但是只要你承认上面的浏览环境的构成因素，那么请不要费劲
了，这个特性不仅取决于网页的制作，还取决于浏览环境。当然，还有无数自信
的网页设计者在设计其他特性时也是在自己那里试验通过后就认为一切都大功告
成了。
在上面提到的浏览环境中，常见的汉字乱码有两种。这两种情况依靠调节浏
览器的各项参数和选项是无法克服的。
一、所有的汉字都显示成矩形的小方块。比如：
□□□□ Windows 95 □□□□□□□□□□□□,□□□□ 70% □□□□
□□ 25% □□□□□□□□, Microsoft □□□□ Netscape □□□□...
(实际的方块是瘦一些的矩形，是 Windows 的某种字体。) 这种情况的发生有这
样四个条件： (1) 浏览网页用的是 Netscape Communicator(Navigator) 4.x 版
本；(2) 使用的操作系统是英文 Windows； (3) 使用的汉字平台是中文之星或
RichWin； (4) 出现这种情况的网页一定使用了包含“gb2312”的标记：

没有遇到过这个问题的人也许觉得不可思议， Netscape 会有这么低级的问题。
但是事实上却是如此的。
解决方法之一是使用南极星 NJwin 1.5x/1/6x 做中文环境。在 SMTH 中，
yuhj 是首先提出用 NJwin 来解决这个问题的人。他在述及这个问题时曾提到：
“具体我没有去研究过，总之用了 Njstar + 英文win95 + Netscape 4.x 看一
般中文网页都没有问题了。 Njstar 使用中文 95 模式主要是不要它用自己的字
体，那个字体比较难看，因为是和 Richwin 同时运行，这样屏幕上显示的是
Richwin 的 Truetype 字体。而 Njstar 在前面提供中文识别。这里 Richwin
换做 Cstar 应该一样有效，没有其他什么要求。”
在 USENET 的 alt.chinese.text 讨论组中，G.Chen<[email protected]> 最近
发文章说：“Netscape Communicator 默认使用 Unicode，而现有大多数汉字平
台不支持，这可以通过修改 Windows 95 注册簿来解决这个问题”。即将下面的
内容存成 fix-mozilla.reg，然后双击解决：
----------- fix-mozilla.reg cut from here --------------
REGEDIT4
[HKEY_CURRENT_USER\\Software\\Netscape\\Netscape Navigator\\INTL]
\"useUnicodeFont\"=dword:00000000
----------- fix-mozilla.reg file end -------------------
当然，绕道解决也是克服这个问题方法，比如：换用 Netscape Navigator
3.x、Microsoft Internet Explorer 3.x/4.x；或干脆换用 PWindows (95) 等。
对于本文的问题，就涉及到一个主页制作的问题。中文 HTML 尚无标准可循，
所以我个人认为让现有浏览环境的大多数人可以读懂应该是网页设计者的主要目
标。“charset=gb2312”的用法是 Netscape 首先提出的 (Microsoft 开始采用
的是gb_2312-80)，那么这种用法到底是用，还是不用？这样用的好处是能够让
Netscape 浏览器在阅读网页的时候支持汉字自动折行。至少出现乱码的读者和
英文 Windows/IE 的用户无法享受这个特性。因此 charset=gb2312 不如不用。
或者在主页明确提示用户可能会发生的麻烦及其解决方法。

----------------------------------------------------------------------

乱码大全(10)──中文HTML与MSIE

二、所有的汉字都是不可辨认的乱码，有点像在英文环境下阅读中文时没有
启动中文环境似的。这种问题都出现在中文 Internet Explorer 中，造成这个
现象的具体原因有两种情况，我们先说第一种。因为无法用 GB 汉字来表达那些
乱码，下面就给出

发布人:Crystal 来自:蓝森林

站点导航

赞助商链接