Windows Notepad里可选的字符编码 |
您所在的位置:网站首页 › notepad未响应 › Windows Notepad里可选的字符编码 |
▲ Windows Notepad的编码包含ANSI、Unicode、Unicode big endian和UTF-8。 警告 注意 测试用例测试用例为:“锟斤拷【断行】a【断行】”。(锟斤拷是一种信仰。) 所有字符的GBK和Unicode编码为: 锟 GBK=EFBF Unicode=U 951F 斤 GBK=BDEF Unicode=U 65A4 拷 GBK=BFBD Unicode=U 62F7以下ASCII字符的GBK和Unicode编码与ASCII一致: ANSI在简体中文系统下,ANSI就是中华人民共和国国家标准定义的GBK编码。 Windows Notepad使用ANSI存储这个文件的结果如下: EF BF BD EF BF BD 0D 0A 61 0D 0A ----- ----- ----- -- -- -- -- --简单的使用GBK编码存储了所有的字符。最高位不是1的单字节并等同于ASCII,否则双字节。 这里要注意字节序(Endian)的问题[注A]。可以看到这里的字节序是大端在先(big-endian)的。 但是不必特意强调“大端在先的GBK”——因为从GB2312开始,标准就规定了存储方式是大端在先的[注B]。后来的GBK和GB18030-2000向下兼容。 ANSI的麻烦就是依赖系统——其他语言系统的ANSI就不是GBK了,打开GBK的文件必然乱码。并且GBK的字符集本身也太小。(千万不要说“我只用中文”——少了Unicode那些符号,网上那些颜文字都打不出来) Unicode系列Windows Notepad所说的“Unicode”、“Unicode big endian”和UTF-8,全都是同样的Unicode编码的不同的字节序列化存储方法。 UTF-16 和 BOM这里的Unicode指UTF-16[注C]。UTF-16是极其简单粗暴的序列化方法——绝大多数的Unicode字符都在U 0000~U FFFF的范围内[注D],那就每个字符用两个字节,把Unicode编码的原始值写盘。 注意ASCII字符也必须浪费一倍的空间存储高8位的0x00——因为如果把高8位的0略了,解析时就再也没有其他的依据去断字。 对于UTF-16就存在大端和小端的问题了——UTF-16并不规定字节的大端在前还是小端在前。但UTF-16并不包含表示字节序的信息,总不能人工看看哪个解析是不乱码的吧…… Unicode提供的解决方式是,把一个零宽无断字空格符(U FEFF ZERO WIDTH NO-BREAK SPACE)以UTF-16的方式序列化之后,塞到文件的最前边。这样UTF-16解析器读取文件的前两个字节,如果是FE FF就是大端在前,FF FE就是小端在前。 这个塞进去的东西就叫BOM(Byte Order Mark,字节顺序标记)。 记事本的“Unicode”和“Unicode big endian”单写“Unicode”,根本就不是一种存储方法的完整表达。因为这只包含编码而没有字节序列化。 M$出现这种错误,我一点都不觉得奇怪。死记结论就可以了:Windows Notepad的“Unicode”就是UTF-16。 Windows Notepad使用“Unicode” = 小端在先的UTF-16,存储这个文件的结果如下: FF FE 1F 95 A4 65 F7 62 0D 00 0A 00 61 00 0D 00 0A 00 -BOM- ----- ----- ----- ----- ----- ----- ----- ----- U FEFF 951F 65A4 62F7 000D 000A 0061 000D 000A |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |