当源码中出现中文(宽字符)时,编译抱怨出错,或者编译后运行输出有误,或者网页,邮件打开为乱码,此时很可能是编码出现了问题。
找到两篇文章,对了解字符编码很有用:
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保存就不会出问题了。
阅读(2084) | 评论(0) | 转发(0) |