了解字符编码

当源码中出现中文(宽字符)时，编译抱怨出错，或者编译后运行输出有误，或者网页，邮件打开为乱码，此时很可能是编码出现了问题。

找到两篇文章，对了解字符编码很有用：

1）字符编码笔记：ASCII，Unicode 和 UTF-8

2）彻底理解字符编码

如果想更深入的理解编码时如何实现的，不妨下载libiconv库看下：


常见编码方式总结：
GB2312 ：针对简体中文，2字节编码
BIG5: 针对繁体中文，2字节编码
GBK：扩展了GB2312，完全兼容GB2312，包含繁体，但是不兼容BIG5，2字节编码
(所以BIG5编码的文档采用GBK打开是乱码，GB2312采用GBK打开可以正常浏览)

Unicode 全球通用的单一字符集，包含人类迄今使用的所有字符，但只规定了符号的编码，没有规定如何存储，针对Unicode有两种编码方案：
1)UCS：包括UCS-2（2字节编码）和UCS-4（4字节编码）
2)UTF：
  a.utf-8  (1-4个字节变长编码)
  b.utf-16 (2或4字节编码)
  c.utf-32 (4字节编码)

凡是定长编码的文本文件，开头均需要 BOM(Byte Order Mark)来告知编辑器如何解读字节序(大小端)。utf-8变长编码不需要BOM。 PHP源码一定不要包含BOM，编辑器保存时通常有不含BOM的选项。

大部分源码编辑器默认保存时均为不含BOM的utf-8，比如Sublime。而WIN上的记事本保存选择utf-8时则会加上"EF BB BF"作为BOM。

按照第一篇文章【字符编码笔记：ASCII，Unicode 和 UTF-8】所说针对记事本做一个实验，均只打入“严”字，分别保存为四种格式，并在linux环境下分析：

# hexdump -C ANSI.txt
00000000  d1 cf |..|

# hexdump -C UNICODE.txt
00000000  ff fe 25 4e |..%N|

# hexdump -C UNICODE_BE.txt
00000000  fe ff 4e 25 |..N%|

# hexdump -C UTF8_BOM.txt // 自动添加了BOM
00000000  ef bb bf e4 b8 a5 |......|

# file ANSI.txt
ANSI.txt: ISO-8859 text, with no line terminators

# file UNICODE.txt         // UCS-2 小端编码
UNICODE.txt: Little-endian UTF-16 Unicode text, with no line terminators

# file UNICODE_BE.txt      // UCS-2 大端编码
UNICODE_BE.txt: Big-endian UTF-16 Unicode text, with no line terminators

# file UTF8_BOM.txt

通过以上方法对使用的编辑器可以做相关测试，通常源码编辑时选择utf-8无BOM保存就不会出问题了。