各种格式ANSI,UTF8,Unicode,Unicode BigEndian的解释

一、ANSI编码

不同的国家和地区制定了不同的标准，由此产生了 GB2312, BIG5, JIS 等各自的编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统下，ANSI 编码代表 JIS 编码。 不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。 当然对于ANSI编码而言，0x00~0x7F之间的字符，依旧是1个字节代表1个字符。这一点是ASNI编码与Unicode编码之间最大也最明显的区别。

    关于ansi编码的BUG编辑

很多细心的人会发现，当新建文本文档只输入“联通”2字保存再打开时将是乱码。

当txt文档中一切字符都在 C0≤AA（第一个字节）≤DF 80≤BB（第二个字节）≤BF 这个范围时，notepad都无法确认文档的格式，没有自动依照UTF-8格式来"Display"。 而"联通"就是C1 AA CD A8，刚好在上面的范围内，所以不能正常显现。

记事本默认是以ANSI编码保存文本文档的，而正是这种编码存在的bug招致了上述怪现象。假如保存时选择Unicode、Unicode(big endian)、UTF-8编码就正常了。此外，假如以ANSI编码保存含有某些特别符号的文本文档，再次打开后符号也会变成英文问号。

 

二、UTF8编码

UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码，又称万国码。由Ken Thompson于1992年创建。现在已经标准化为RFC 3629。UTF-8用1到6个字节编码UNICODE字符。用在网页上可以同一页面显示中文简体繁体及其它语言（如英文，日文，韩文）。

字符集编辑

如果UNICODE字符由2个字节表示，则编码成UTF-8很可能需要3个字节。而如果UNICODE字符由4个字节表示，则编码成UTF-8可能需要6个字节。用4个或6个字节去编码一个UNICODE字符可能太多了，但很少会遇到那样的UNICODE字符。 UTF-8转换表表示如下：

Unicode/UCS-4	bit数	UTF-8	byte数	备注
0000 ~ 007F	0~7	0XXX XXXX	1
0080 ~ 07FF	8~11	110X XXXX 10XX XXXX	2
0800 ~ FFFF	12~16	1110XXXX 10XX XXXX 10XX XXXX	3	基本定义范围：0~FFFF
1 0000 ~ 1F FFFF	17~21	1111 0XXX 10XX XXXX 10XX XXXX 10XX XXXX	4	Unicode6.1定义范围：0~10 FFFF
20 0000 ~ 3FF FFFF	22~26	1111 10XX 10XX XXXX 10XX XXXX 10XX XXXX 10XX XXXX	5	说明：此非unicode编码范围，属于UCS-4 编码 早期的规范UTF-8可以到达6字节序列，可以覆盖到31位元（通用字符集原来的极限）。尽管如此，2003年11月UTF-8 被 RFC 3629 重新规范，只能使用原来Unicode定义的区域， U+0000到U+10FFFF。根据规范，这些字节值将无法出现在合法 UTF-8序列中
400 0000 ~ 7FFF FFFF	27~31	1111 110X 10XX XXXX 10XX XXXX 10XX XXXX 10XX XXXX 10XX XXXX	6

实际表示ASCII字符的UNICODE字符，将会编码成1个字节，并且UTF-8表示与ASCII字符表示是一样的。所有其他的UNICODE字符转化成UTF-8将需要至少2个字节。每个字节由一个换码序列开始。第一个字节由唯一的换码序列，由n位连续的1加一位0组成, 首字节连续的1的个数表示字符编码所需的字节数。

Unicode转换为UTF-8时，可以将Unicode二进制从低位往高位取出二进制数字，每次取6位，如上述的二进制就可以分别取出为如下示例所示的格式，前面按格式填补，不足8位用0填补。

注：Unicode转换为UTF-8需要的字节数可以根据这个规则计算：如果Unicode小于0X80（Ascii字符），则转换后为1个字节。否则转换后的字节数为Unicode二进制位数加3再除以5。

 

Unicode规范中有一个BOM的概念。BOM——Byte Order Mark，就是字节序标记。在这里找到一段关于BOM的说明：

在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little- Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的ef bb bf了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。

如果想去掉bom，如果只包含英文字符(或者说ASCII编码内的字符)，就把文件存成ASCII码方式吧。用UE等编辑器的话，点文件->转换 ->UTF-8转ASCII，或者在另存为里选择ASCII编码。如果是DOS格式的行尾符，可以用记事本打开，点另存为，选ASCII编码。如果包含中文字符的话，可以用UE的另存为功能，选择“UTF-8 无 BOM”即可。

根据Bo-Blog的wiki的说明：Editplus需要先另存为gb，再另存为UTF-8。不过这样做要小心，所有GBK编码中不包含的字符就会都丢了。如果有一些非中文的字符在文件里的话还是不要用这种办法了。(从这一个小方面来看，UE——UltraEdite-32确实比Editplus 好很多，Editplus太轻量级了)

另外我发现了一个办法，就是利用Wordpress提供的文件编辑器。这个办法不受限制，不需要去下载专门的编辑器，毕竟大家都在用 Wordpress嘛。先在ftp里把要编辑的文件的写入权限打开，然后进入Wordpress后台->管理->文件编辑器，输入要编辑文件的路径，点编辑文件。在显示出来的编辑界面中，你是看不到开头的那三个字符的，不过没关系，把光标定位在整个文件的第一个字符前，按一下 Backspace键。OK了，点更新文件吧，在ftp里刷新一下，可以看到文件小了3字节，大功告成。

示例

UNICODE uCA(1100 1010) 编码成UTF-8将需要2个字节：

uCA -> C3 8A

UNICODE uF03F (11110000 0011 1111) 编码成UTF-8将需要4个字节:

u F03F -> EF 80 BF

Unicode 16进制	Unicode 2进制	bit数	UTF-8 2进制	UTF-8 16进制
CA	1100 1010	8	1100 00111000 1010	C3 8A
F0 3F	11110000 0011 1111	16	111011111000 00001011 1111	EF 80 BF