而UTF8中,每一个字符的编码有多少位是通过第一个字节来表述的。并且没有big-endian和little-endian的区分,见后述。
BOMs 文件头: 00 00 FE FF = UTF-32, big-endian FF FE 00 00 = UTF-32, little-endian EF BB BF = UTF-8, FE FF = UTF-16, big-endian FF FE = UTF-16, little-endian另一个要注意的是:UTF-8 的网页代码不应使用 BOM。否则经常会出错:在网页上使用BOM是个错误。BOM设计出来不是用来支持HTML和XML的。要识别文本编码,HTML有charset属性,XML有encoding属性,不是必需拉BOM撑场面。尽管理论上BOM能够用来识别UTF-16编码的HTML页面,但实际project上非常少有人这么干。毕竟UTF-16这样的编码连ASCII都双字节,实在不适用于做网页。
Windows使用BOM的历史原因:通常BOM是用来标示Unicode纯文本字节流的,用来提供一种方便的方法让文本处理程序识别读入的.txt文件是哪个Unicode编码(UTF-8。UTF-16BE,UTF-16LE)。Windows相对对BOM处理比較好,是由于Windows把Unicode识别代码集成进了API里。主要是CreateFile()。打开文本文件时它会自己主动识别并剔除BOM。
Windows用这个有历史原因,由于它最初脱胎于多代码页的环境。而引入Unicode时Windows的设计者又希望能在用户不注意的情况下同一时候兼容Unicode和非Unicode(Multiple byte)文本文件,就仅仅能借助这样的小trick了。
带BOM的文本文件在Linux/unix环境又经常会遇到问题:知乎介绍的非常具体:http://www.zhihu.com/question/20167122文本文件解析: 文本文件相应于人类能够阅读的文本,怎样从2进制转换为文本文件呢?起初由于计算机在美国发明。自然大家考虑的是英语怎样表示,英语字母总共26个。加上特殊字符,128个字符,7位既一个byte就可以表示出来。这个就是大家所熟知的ascill编码。相应关系非常easy,一个字符相应一一个byte。
但非常快发现。其它非英语国家的文字远远超过ascill码,这时候大家当然想统一一下。不同国家出了自己不同的编码方式。中国的gb2312就是自己做出来的编码方式,这样下去每一个国家都有自己的编码方式,来回转换太麻烦了。这时候出现了新的编码方式,unicode编码方式,想将编码统一,所以规定了每一个字符相应的unicode码。 1、非常多文件都是ascii编码,假设用unicode 太浪费。
2、没有标志位说明该几个字节来解析为一个符号。 这时候解救世界的utf出现了。utf是unicode的一种实现,仅仅只是更聪明了。utf16是占用两字节,或者四字节。utf32是占用四字节。
utf8是非常聪明的一种表示方式。
1、对于单字节符号,字节第一位为0,后面7位表示字节编码。
2、对于n字节符号,第一字节的前n位都设为1,第n+1位为0。其余位用于编码。对于不同的编码,在文本的最前方有不同的标志,unicode 通常有两位来表示各自是ff fe, 或者feff, fffe表示litte-endian 编码feff表示big-endian编码。utf8是efbbbf来开头的。
能够看出来utf-8是自解释的。所以不用带这个标志文件,大多数程序是能够识别的。
但有些程序不能识别这个标志,比方php就会直接把这个标志当文本解析,不会忽略。