计算机字符编码及文件编码格式解析

最近因为项目需要从网络上获取文本数据并解析，然而获取的文本文件的编码格式未知，所以解析比较麻烦。为此，我专门研究了一下中文编码，看了网络上的许多文章，现在对计算机中的信息编码理解逐渐清晰。下面，我就网络上所学到的以及自己的一些理解做一个简单的梳理。

 

计算机编码的发展

很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物，他们把这称为”字节”。再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去，他们就把这机器称为”计算机”。

开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作。遇上 00×10, 终端就换行，遇上0×07, 终端就向人们嘟嘟叫，例好遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。他们看到这样很好，于是就把这些0×20以下的字节状态称为”控制码”。

他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字 了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的”Ascii”编码（American Standard Code forInformation Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。

后来计算机发展越来越广泛，世界各国为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称”扩展字符集”。但是原有的编号方法，已经再也放不下更多的编码。

等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。于是国人就自主研发，把那些127号之后的奇异符号们直接取消掉。规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。

中国人民看到这样很不错，于是就把这种汉字方案叫做 “GB2312″。GB2312 是对 ASCII 的中文扩展。但是中国的汉字太多了，后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。

因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码。当时的中国人想让电脑显示汉字，就必须装上一个”汉字系统”，专门用来处理汉字的显示、输入的问题，装错了字符系统，显示就会乱了套。这怎么办？就在这时，一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它”UniversalMultiple-Octet Coded Character Set”，简称 UCS,俗称 “UNICODE”。

UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于 ascii 里的那些”半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于”半角”英文符号只需要用到低8位，所以其高 8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。

但是，UNICODE在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与 UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。

UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8 就是每次8个位传输数据，而 UTF16 就是每次16个位，只不过为了传输时的可靠性，从UNICODE到 UTF时并不是直接的对应，而是要过一些算法和规则来转换。

 

看完这些，相信你对于这几个编码关系等，了解的比较清楚了吧。我再来简单的总结一下：

美国最早定制了适合美国国内使用的字符编码规则，即ASCII码，后面欧洲各国又对其加以扩展以方便使用。

中国人民通过对ASCII 编码的中文扩充改造，产生了 GB2312 编码，可以表示6000多个常用汉字。

汉字实在是太多了，包括繁体和各种字符，于是产生了 GBK 编码，它包括了 GB2312 中的编码，同时扩充了很多。

中国是个多民族国家，各个民族几乎都有自己独立的语言系统，为了表示那些字符，继续把 GBK 编码扩充为 GB18030 编码。

每个国家都像中国一样，把自己的语言编码，由此产生了 GB2312, BIG5, JIS 等各自的编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。如果你不安装相应的编码，就无法解释相应编码想表达的内容。

终于，有个叫ISO 的组织看不下去了。他们一起创造了一种编码 UNICODE ，这种编码非常大，大到可以容纳世界上任何一个文字和标志。所以只要电脑上有 UNICODE 这种编码系统，无论是全球哪种文字，只需要保存文件的时候，保存成 UNICODE 编码就可以被其他电脑正常解释。

UNICODE 在网络传输中，出现了两个标准 UTF-8 和 UTF-16，分别每次传输 8个位和 16个位。

于是就会有人产生疑问，UTF-8既然能保存那么多文字、符号，为什么国内还有这么多使用 GBK 等编码的人？因为 UTF-8 等编码体积比较大，占电脑空间比较多，如果面向的使用人群绝大部分都是中国人，用 GBK 等编码也可以。但是目前的电脑来看，硬盘都是白菜价，电脑性能也已经足够无视这点性能的消耗了。所以推荐所有的网页使用统一编码：UTF-8。

 

几点注意：

从ASCII、 GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码 中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。

Unicode规定了怎么用2字节（也有4字节）表示各种文字。而怎样传输这些编码，是由UTF(Unicode TransformationFormat)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16

 

 

在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统下，ANSI 编码代表 JIS 编码。 不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。

计算机程序设计中中文文本编码解析

看完上面的内容，我想大家对计算机编码及其发展应该有了一个清晰的认识，下面我们来看一下如何解析一个中文的文本文件，由于中文编码有许多格式，为了方便解析一个中文文件，在文件头往往会包含一个编码格式的标示，这就是BOM（Byte Order Mark），对于不同的编码，其对应的BOM不同：

UTF-8：0xEF BB BF

UTF-16(BE)：0xFE FF

UTF-16(LE)：0xFF FE

上面的BE和LE表示大端(big edian)和小端(little edian)格式，它们是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C(高字节)写在前面，还是将49(低字节)写在前面？如果将6C写在前面，就是big endian。如果将49写在前面，就是little endian。也就是说“高字节”写在“低地址”就是大端，“低字节”写在“低地址”就是小端。

对于有BOM的文件，我们知道其编码格式就很容易解析，对于没有BOM的文件，我们又如何判断该文件是UTF-8还是GBK码呢？在网上找了很久都没找到现成的代码，于是自己去查了一下UTF-8具体的编码格式，如下：

 

在ASCII码的范围，用一个字节表示，超出ASCII码的范围就用字节表示，这就形成了我们上面看到的UTF-8的表示方法，这様的好处是当UNICODE文件中只有ASCII码时，存储的文件都为一个字节，所以就是普通的ASCII文件无异，读取的时候也是如此，所以能与以前的ASCII文件兼容。

大于ASCII码的，就会由上面的第一字节的前几位表示该unicode字符的长度，比如110xxxxxx前三位的二进制表示告诉我们这是个2BYTE的UNICODE字符；1110xxxx是个三位的UNICODE字符，依此类推；xxx的位置由字符编码数的二进制表示的位填入，依次从右向左填入该字符对应的Unicode编码，左边多出的补0。越靠右的x具有越少的特殊意义。只用最短的那个足够表达一个字符编码数的多字节串。注意在多字节串中，第一个字节的开头"1"的数目就是整个串中字节的数目。

ASCII码占一个字节；GB2312和GBK码英文字符占一个字节，中文字符占2个字节；UTF-8编码下字符所占字节数从1到6个不等，英文字符占一个字节，中文字符通常占3个字节。

 

在知道UTF-8的具体编码格式之后，我就自己写了一个程序来识别文件编码格式，下面直接上代码：

<span style="white-space:pre">    </span>/**
     * 判断文件的编码格式
     * @param fileName :file
     * @return 文件编码格式
     * @throws Exception
     * 无法识别utf-8 without BOM
     */
    public static String getFileCodeString(String fileName) throws Exception{
        BufferedInputStream bin = new BufferedInputStream(new FileInputStream(fileName));
        int p = (bin.read() << 8) + bin.read();//读取文件头前16位
        String code = null;
        switch (p) {
            case 0xefbb:
                code = "UTF-8";
                break;
            case 0xfffe:
                code = "UTF-16LE";
                break;
            case 0xfeff:
                code = "UTF-16BE";
                break;
            default:
                if(isUTF8(fileName)){
                    Log.i(TAG, "getFileCodeString: 编码格式为无BOM的UTF-8");
                    code="UTF-8";
                }else {
                    code = "GBK";
                }
        }
        bin.close();
        return code;
    }

    /**
     * 判断文件是否是无BOM的UTF-8编码
     * @param fileName
     * @return
     */
    public static boolean isUTF8(String fileName){
        boolean state=true;
        BufferedInputStream bin=null;
        try {
            bin = new BufferedInputStream(new FileInputStream(fileName));
            int count=10;//设置判断的字节流的数量
            int firstByte = 0;
            //根据字节流是否符合UTF-8的标准来判断
            while(true){
                if(count--<0 || (firstByte=bin.read())==-1){
                    break;
                }
                //判断字节流
                if((firstByte & 0x80)==0x00){
                    //字节流为0xxxxxxx
                    continue;
                }else if((firstByte & 0xe0)==0xc0){
                    //字节流为110xxxxx 10xxxxxx
                    if( (bin.read() & 0xc0)==0x80)
                        continue;
                }else if((firstByte & 0xf0)==0xe0){
                    //字节流为1110xxxx 10xxxxxx 10xxxxxx
                    if((bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80)
                        continue;
                }else if((firstByte & 0xf8)==0xf0){
                    //字节流为11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
                    if((bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80)
                        continue;
                }else if((firstByte & 0xfc)==0xf8){
                    //字节流为111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
                    if((bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80
                            && (bin.read() & 0xc0)==0x80)
                        continue;
                }else if((firstByte & 0xfe)==0xfc){
                    //字节流为1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
                    if((bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80
                            && (bin.read() & 0xc0)==0x80 && (bin.read() & 0xc0)==0x80)
                        continue;
                }
                state=false;
                break;
            }
        } catch (FileNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            state=false;
            e.printStackTrace();
        }finally{
            try {
                if(bin!=null)
                    bin.close();
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }

        return state;
    }

 

参考内容：

http://www.cnblogs.com/xiaomia/archive/2010/11/28/1890072.html

http://www.qianxingzhem.com/post-1499.html

http://www.cnblogs.com/adforce/archive/2013/01/02/2842042.html

 

 

前段时间学习web知识，开始以为浏览器对html的解码是按标签<meta>中指定的字符集进行解码的，但是仔细想想发现又存在问题，因为要知道<meta>中指定的字符集，必须先对html文件进行解码，但事先是不知道编码的。于是在网上找了些资料（见附录）。发现浏览器对html文件编码的确定过程还是很复杂的。编码的确定按优先级如下：

1.如果用户指定了编码，则按用户指定的编码进行解码。

2.先对文件进行预解析，如果文件存在BOM（Byte Order Mark），则按BOM确定的编码解码。

3.如果HTTP响应头中存在编码信息，则按响应头中的编码进行解码。

4.先按浏览器的编码选择算法选择一个编码进行预解析，如果解析出<meta>标签中存在字符集设置，则按<meta>标签中的字符集进行解码。

5.按浏览器的默认编码。