字符集问题

被各种乱码整得焦头烂额，查了些资料，理了理，挺有意思的。

首先是ASCII码，美国搞出来时用32至127表示可打印字符，0至31为控制字符，如0x0A （LF换行),0x0D（CR回车)。然而随着计算机普及，非英语地区开始想使用自己的语言，于是8位ASCII码的最高位也被用上了，而亚洲地区出现使用两个字节表示一个字符的编码，如天朝的GB-2312，台湾的Big5，Japs的JIS等等，造成了很混乱的局面，ANSI于是制定了个标准：对小于128的编码和ASCII值一样，而如果使用双字节编码则要求每个字节最高位为1。也就是说ANSI码并不是一种编码，它只是提供了一种规范，在大陆ANSI码，也就是GB-2312发展到今天的GBK，我们中文windows系统用记事本存储时默认的是采用ANSI，存储的值也就是GBK值，如“汉”的值为:0xBA 0xBA。                                                                                                                                                                                                                                                            

然而并没有解决不同字符集的通用问题，Unicode就诞生了，在Unicode普及之前，MS采用了Code Pages的机制来实现不同ANSI码到Unicode的映射。两个字节表示范围内的为UCS-2,四个字节的为UCS-4，UCS-4的最高字节的最高位为0，然后根据第一个字节分成128个group，根据第二个字节把每个组分成256个plane...（BMP:把0组0平面前面的两个字节去掉就得到UCS-2字符）应当注意的是，Unicode并不提供具体的编码方法，也就是说字符在内存中存储的并不一定是Unicode值。Unicode的编码方法有UTF-8 UTF-16 UTF-32...(UTF:UCS Transformation Format)，具体编码如下：

 

UTF-8：

UCS-2编码(16进制) UTF-8 字节流(二进制) 模板

0000 - 007F 0xxxxxxx 

0080 - 07FF 110xxxxx 10xxxxxx 

0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx 

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89

这里有段小插曲，就是记事本新建txt文件，输入“联通”保存退出，再打开出现乱码的问题，就是由于记事本在默认情况下用ANSI码也就是GBK存储，“联通”的GBK码为C1AA

CDAB，二进为11000001 10101010 11001101 10101011正好符合UTF-8的第二个模板，一般情况下不同编码都有文件头，但Unicode刚开始时很多程序都不写文件头，记事本便对文件编码方式进行猜测，就以UTF-8解读，按照UTF-8模板2的逆运算，得到006a 0368对应的Unicode为j。很明显只要新建的txt格式为0xAA,0xBB,满足0≤AA≤DF 80≤BB≤BF时，就会出现上述情况。

UTF-16:

UTF-16以16位为单位对UCS进行编码，对小于0x10000的UCS码，编码值等于16位无符号整数，这也许也是人们为什么说Unicode编码和UTF-16编码一样的原因吧，而对于高于0x10000的值稍微麻烦些，不过现在也用不着。

UTF-32:

直接用32位无符号整数表示

到这里我基本了解了，记事本中ANSI,Unicode,UTF-8的出处，然而记事本中还有一个Unicode big endian是哪里来的呢？这就要说，UTF-16与UTF-8的区别了，UTF-8是按字节编码，不存在码序的问题，而UTF-16以16位为单位就存在一个高端存储(big endian）和低端存储的问题(little endian)的问题，Unicode规范推荐先传输个字节顺序标记，UCS中有个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，编码为FEFF,还有一个UCS中不存在的字符FFFE。接收端如果收到FEFF就按高端存储解码，收到FFFE就按低端存储解码。这就是记事本中Unicode和Unicode big endian的区别。下面为“汉”按unicode和Unicode big endian存储的结果：

Unicode：  00000000h:FF FE 49 6C                                     ; 蘒l 

Unicode big endian ：00000000h: FE FF 6C 49                                     ; ?lI

而UTF-8实际上也会在文件开头存储"ZERO WIDTH NO-BREAK SPACE"来标识文件格式，

UTF-8：          00000000h:EF BB BF E6 B1 89                           ; 锘挎眽

综上所述，ASCII派生了GB-2312,Big5等等的DBCS，ANSI为此制定了标准，然后Unicode提出了统一的字符集，UTF-8,UTF-16为Unicode的编码方式，其中UTF-16又由于自身的特点和Unicode的值非常像，于是就直接用Unicode指代UTF-16，而用Unicode big endian指代UTF-16大端存储方式。

参考：

http://www.joelonsoftware.com/articles/Unicode.html

http://www.cppblog.com/qiujian5628/archive/2008/01/24/41773.html

问题补充一：

windows默认文件名编码方式ANSI,而Linux默认文件名编码为UTF-8，复制后文件名乱码。

解决翻案：Linux工具 convmv

问题补充二：

vim配置文件~/.vimrc中的配置项fileencodings，fileencoding和encoidng的含义？

encoding:encoding是Vim的内部使用编码，encoding的设置会影响Vim内部的Buffer、消息文字等。在Unix环境下，encoding的默 认设置等于locale；Windows环境下会和当前代码页相同。在中文Windows环境下encoding的默认设置是cp936（GBK）

fileencodings:Vim在打开文件时会根据fileencodings选项来识别文件编码，fileencodings可以同时设置多个编码，Vim会根据设置的顺序来猜测所打开文件的编码。

fileencoding:Vim在保存新建文件时会根据fileencoding的设置编码来保存。如果是打开已有文件，Vim会根据打开文件时所识别的编码来保存，除非在保存时重新设置fileencoding。

 

Vim内部使用iconv库进行编码转换，如果这几个选项所设置的编码不一致，Vim就有可能会转换编码。打开已有文件时会从文件编码转换到 encoding所设置的编码；保存文件时会从encoding设置的编码转换到fileencoding对应的编码。经常会看到Vim提示[已转换]， 这是表明Vim内部作了编码转换。终端环境下使用Vim，会从termencoding设置的编码转换到encoding设置的编码。
可以用|:help encoding-values|列出Vim支持的所有编码。

 

问题补充三：

某个整数转UTF-8字符串的小程序

 

char *utf8_encode(int num)
{
    char *res = (char*)malloc(512000 * sizeof(char));

    int byte[4];
    int count = 0;

    if (num <= 0x7f){
        byte[0] = num | 0x80;
        count = 1;
    }
    else if (num <= 0x7ff)
    {
        byte[0] = (num & 0x3f) | 0x80;
        byte[1] = (num >> 6) | 0xc0;
        count = 2;
    }
    else if (num <= 0xffff){
        byte[0] = (num & 0x3f) | 0x80;
        byte[1] = ((num >> 6) & 0x3f) | 0x80;
        byte[2] = (num >> 12) | 0xe0;
        count = 3;
    }
    else{
        byte[0] = (num & 0x3f) | 0x80;
        byte[1] = ((num >> 6) & 0x3f) | 0x80;
        byte[2] = ((num >> 12) & 0x3f) | 0x80;
        byte[3] = (num >> 18) | 0xf0;
        count = 4;
    }

    for (int i = 0; i < count; i++){

        char byte_str[9];

        _itoa(byte[count - i - 1], byte_str, 2);
        strncpy(res + i * 9, byte_str, 8);

        if (i != count - 1){
            res[i * 9 + 8] = ' ';
        }
    }

    res[count * 9 - 1] = '\0';

    return res;
}