联通之所以拼不过移动的原因

只看该作者 · 2012-3-14 11:55

其实很简单：
输入汉字，保存时系统以默认字体Times New Roman保存。
如果你输入汉字后，在格式->字体里将字体改为“宋体”，就一切OK了。

1万 · 2012-3-14 11:56

因为记事本支持UTF-8编码的问题。
找个不支持UTF-8编码的文本编辑器看就好了。

你可以点文件菜单，另存为，里面的文本编码已经变了。

只看该作者 · 2012-3-14 12:03

在计算机中字符通常并不是保存为图像，每个字符都是使用一个编码来表示的，而每个字符究竟使用哪个编码代表，要取决于使用哪个字符集(charset)。

　　在最初的时候，Internet上只有一种字符集——ANSI的ASCII字符集，它使用7 bits来表示一个字符，总共表示128个字符，其中包括了英文字母、数字、标点符号等常用字符。之后，又进行扩展，使用8 bits表示一个字符，可以表示256个字符，主要在原来的7 bits字符集的基础上加入了一些特殊符号例如制表符。
　　后来，由于各国语言的加入，ASCII已经不能满足信息交流的需要，因此，为了能够表示其它国家的文字，各国在ASCII的基础上制定了自己的字符集，这些从ANSI标准派生的字符集被习惯的统称为ANSI字符集，它们正式的名称应该是MBCS(Multi-Byte Chactacter System，即多字节字符系统)。这些派生字符集的特点是以ASCII 127 bits为基础，兼容ASCII 127，他们使用大于128的编码作为一个Leading Byte，紧跟在Leading Byte后的第二(甚至第三)个字符与Leading Byte一起作为实际的编码。这样的字符集有很多，我们常见的GB-2312就是其中之一。
　　例如在GB-2312字符集中，“联通”的编码为C1 AC CD A8，其中C1和CD就是Leading Byte。前127个编码为标准ASCII保留，例如“0”的编码是30H(30H表示十六进制的30)。软件在读取时，如果看到30H，知道它小于128就是标准ASCII，表示“0”，看到C1大于128就知道它后面有一个另外的编码，因此C1 AC一同构成一个整个的编码，在GB-2312字符集中表示“连”。
　　由于每种语言都制定了自己的字符集，导致最后存在的各种字符集实在太多，在国际交流中要经常转换字符集非常不便。因此，提出了Unicode字符集，它固定使用16 bits(两个字节、一个字)来表示一个字符，共可以表示65536个字符。将世界上几乎所有语言的常用字符收录其中，方便了信息交流。标准的Unicode称为UTF-16。后来为了双字节的Unicode能够在现存的处理单字节的系统上正确传输，出现了UTF-8，使用类似MBCS的方式对Unicode进行编码。注意UTF-8是编码，它属于Unicode字符集。Unicode字符集有多种编码形式，而ASCII只有一种，大多数MBCS(包括GB-2312)也只有一种。
　　例如“联通”两个字的Unicode标准编码UTF-16 (big endian)为：DE 8F 1A 90
　　而其UTF-8编码为：E8 BF 9E E9 80 9A
　　最后，当一个软件打开一个文本时，它要做的第一件事是决定这个文本究竟是使用哪种字符集的哪种编码保存的。软件有三种途径来决定文本的字符集和编码：
　　最标准的途径是检测文本最开头的几个字节，如下表：
　　例如插入标记后，联通”两个字的UTF-16 (big endian)和UTF-8码分别为：
　　FF FE DE 8F 1A 90
　　EF BB BF E8 BF 9E E9 80 9A
　　但是MBCS文本没有这些位于开头的字符集标记，更不幸的是，一些早期的和一些设计不良的软件在保存Unicode文本时不插入这些位于开头的字符集标记。因此，软件不能依赖于这种途径。这时，软件可以采取一种比较安全的方式来决定字符集及其编码，那就是弹出一个对话框来请示用户，例如将那个“联通”文件拖到MS Word中，Word就会弹出一个对话框。
　　如果软件不想麻烦用户，或者它不方便向用户请示，那它只能采取自己“猜”的方法，软件可以根据整个文本的特征来猜测它可能属于哪个charset，这就很可能不准了。使用记事本打开那个“联通”文件就属于这种情况。
　　我们可以证明这一点：在记事本中键入“联通”后，选择“Save As”，会看到最后一个下拉框中显示有“ANSI”，这时保存。当再当打开“联通”文件出现乱码后，再点击“File”->“Save As”，会看到最后一个下拉框中显示有“UTF-8”，这说明记事本认为当前打开的这个文本是一个UTF-8编码的文本。而我们刚才保存时是用ANSI字符集保存的。这说明，记事本猜测了“联通”文件的字符集，认为它更像一个UTF-8编码文本。这是因为“联通”两个字的GB-2312编码看起来更像UTF-8编码导致的，这是一个巧合，不是所有文字都这样。可以使用记事本的打开功能，在打开“联通”文件时在最后一个下拉框中选择ANSI，就能正常显示了。反过来，如果之前保存时保存为UTF-8编码，则直接打开也不会出现问题。
　　如果将“联通”文件放入MS Word中，Word也会认为它是一个UTF-8编码的文件，但它不能确定，因此会弹出一个对话框询问用户，这时选择“简体中文(gb2312)”，就能正常打开了。记事本在这一点上做得比较简化罢了，这与这个程序的定位是一致的。

只看该作者 · 2012-3-14 12:05

这是一个字符编码应用的奇怪现象，讲的明白点，可以说是记事本开小差了！记事本为什么会犯错误？记事本犯了怎样的错误呢？也许你会迫不及待的想知道这些问题，如果是这样，我不会让你空腹而归的。
在简体中文操作系统中默认的本地字符集编码是GBK编码，除非你在保存记事本文本文件时候选择了其他编码方式，否则用记事本录入的字符信息将使用GBK编码进行储存。巧合的是，“联通”这两个字符的GBK编码具有UTF-8编码的特征，记事本犯下的错误正是将GBK编码存放的记录有“联通”两个字符的文件误认为UTF-8编码的文件。或许你会问，UTF-8编码的文件不是以“EF BB BF”三个特殊字节开头吗？既然这样，记事本怎么会犯这么低级的错误呢？没错，UTF-8编码规定使用UTF-8编码的文件以“EF BB BF”三个特殊字节开头，但并不是强制性要求，早期的UTF-8编码文件就不遵循这个规定。因此记事本不能依靠文件的开头字节判断一个文件是否是UTF-8编码，而只能对文件中的数据进行简单的编码分析来确定。正是这个原因，才有了字符编码应用中的这个奇怪又无法避免的现象。

如果上面的解释对于你来说只是杯开胃红酒，那我还是块点把主食呈上吧，一份大峡谷香烤猪肋排。UTF-8编码采用1-3个字节对字符进行编码，编码字节数与字符的Unicode编码值有严格的对应关系，让我们回忆下UTF-8编码和Unicode的对应关系吧。
Unicode编码值 UTF-8编码结构
u0001 - u007E 0XXXXXXX
u0080 - u07FF 和 u0000 110XXXXX 10XXXXXX
u0800 - uFFFF 1110XXXX 10XXXXXX 10XXXXXX
“联通”这两个字符的GBK编码值是“C1 AA CD A8"，GBK编码方式使用两个字节对一个字符进行编码，因此以GBK编码方式存放的录有“联通”两个字符的文件的大小为四个字节。接下来分别观察“联通”这两个字符GBK编码值的二进制形式，你有发现有趣的事。
联 GBK 十六进制：C1 AA 二进制：1100 0001,1010 1010
通 GBK 十六进制：C1 AA 二进制：1100 1101,1010 1000
请注意上面二进制数据的着色部分，你想到了什么？对，它们和UTF-8编码结构中的补充位完全一致，UTF-8编码的补充位使得编码值更有规律，而记事本刚好凭借这个特征区分UTF-8编码的文件。存有“联通”两个字符的文件的所有数据都符合这个特征，就是这样，记事本彻底的将文件误认为UTF-8编码的文件。
将错就错，让我们来看看这个错误是怎样收场的。如果把“联通”的GBK编码值当作UTF-8编码值，那文件就成为一个写有数据“C1 AA CD A8”并以UTF-8编码的文件，当使用记事本再次打开的时候会看到什么呢？只要将UTF-8编码转换成Unicode编码就知道了。UTF-8编码“C1 AA CD A8”转换成Unicode编码后，编码值为“6A 00 68 03”（转换方法请参考本Blog中的《字符编码》一文）。0x006A这个Unicode编码值位于u0001 - u007E之间，若要转换为UTF-8编码，显然只能用一个字节进行编码，因此“联”的GBK编码“C1 AA”虽然特征上貌似UTF-8编码，但它却不对应任何一个UTF-8编码。接着看0x0368这个Unicode编码值，这个值对应了字符“?”，这也正是我们将在记事本中看到的内容。或许你会说我看到的是一个黑色矩形啊，这只是字体的原因，你将字体改为宋体或者其他字体，看到的就是字符“?”。
对于中文字符，UTF-8编码要用三个字节进行编码，因此，如果你使用记事本录入“联通”，然后选择以UTF-8编码方式保存的话，文件大小应为9个字节（包含三个字节的开头数据），而同样的文件GBK编码却是4个字节。最后附上“联通”的GBK、UTF-8、Unicode编码值，以及记事本的错误思维。
联通 GBK C1 AA CD A8 UTF-8 E8 81 94 E9 80 9A Unicode 54 80 1A 90
联通 GBK C1 AA CD A8 UTF-8 C1 AA CD A8 Unicode 6A 00 68 03 （将GBK值误认为UTF-8值的结果）