操作系统和程序设计语言的API使用的字符编码分析

 1、Java的运行环境中，String是什么编码？

使用java做程序设计语言，字符编码是和jvm相关的，和操作系统无关。

java默认的编码是jvm在安装的时候就确定了的，它是根据你的系统的环境确定并默认的。

我们可以通过java的Charset类的defaultCharset()方法来获取它默认的字符编码。

我安装的JDK是1.7，系统环境是64位，获取的默认的字符编码是utf16的，并且是Big-Endian(这点我比较奇怪，我的机器是Little-endian的，而虚拟机竟然默认是大端的编码)。

看如下代码：

String name = "张三";

Charset def    = Charset.defaultCharset();             // 获取系统默认的编码   def = utf-16(Big-Endian)
Charset utf8   = Charset.forName("UTF-8");       
Charset gbk   = Charset.forName("GBK");

byte[] bdefult     = name.getBytes();                    //    获取的name的字节流  = [-2, -1, 95, 32, 78, 9]
byte[] butf16Big = name.getBytes(def);               //    name转换为utf16(Big-Endian)后的字节流  =  [-2, -1, 95, 32, 78, 9]
byte[] bgbk       = name.getBytes(gbk);               //    name转换为gbk后的字节流  =  [-43, -59, -56, -3]
byte[] butf8       = name.getBytes(utf8);             //     name转换为utf8后的字节流  =  [-27, -68, -96, -28, -72, -119]

由此我们可以看出执行String name = "张三"后String存储的就已经是系统默认的字符编码了utf16(Big-Endian)。

可能细心的人会发现，为什么"张三"的字节数是[-2, -1, 95, 32, 78, 9]有6个字节呢？不是utf16每个字符是占用两个字节来表示的呀。

对的，往下看：

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。

(Unicode是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。)

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。

我们知道单字节的字符的表示(char)是没有大小端之分的，而ushort、int、long、int64等类型才有大小端之分，故gbk和utf8的字节流不需要表示它是否是大小端，而utf-16(即ushort)的字节流是需要告知它是大端or小端。

由于 Java 中的String默认采用带有 UCS2 的 UTF-16BE 拆分的，所以我们需要在字节流前面加上(FE, FF)告知是大端的。

其实 [-2, -1, 95, 32, 78, 9] = [FE, FF, 95, 32, 78, 9]，所以前面两个字节的含义只是表明存储的字节流是大端还是小端的，方便传输的时候识别，并无其它的含义。

总结：

(1)、java默认的字符编码是虚拟机决定的，并与系统无关。

(2)、Unicode和UTF-16：1个字符占2个字节（不管是哪国语言）

(3)、Java中的char默认采用Unicode编码，所以Java中一个char也占2个字节

 2、c和c++语言

 大家都知道c和c++语言是没有java一样的虚拟机的，它们最终都是调用的系统的API，这就注定了它最终调用的接口是和系统相关的。

(1)、windows系统

VC/VS的C++开发环境，它实现的标准C++接口有不少肯定是需要使用windows api的。

要了解Win32子系统的DLL们提供了哪些API，最直接的方法就是用Win32dsm直接查看DLL们的导出表。这时我们会发现Win32 API中带字符串的API一般都有两个版本，例如CreateFileA()和CreateFileW()。当然也有例外，例如GetProcAddress函数。

A代表ANSI代码页，W是宽字符，即Unicode字符。Windows中的Unicode字符一般指UCS2的UTF16-LE编码。让我们通过几个实例观察A/W版本间的关系。

我们用WIn32dsm查看gdi32.dll的汇编代码，可以看到CreateFileA()调用GdiGetCodePage()获取当前代码页，再调用MultiByteToWideChar()转换输入的字符串，然后调用一个内部函数。而CreateFileW()直接调用这个内部函数。

故可以判断windows系统API内部实现是用UCS2的UTF16-LE编码。故windows api我们尽量使用宽字符的接口。

了解windows的API实现是用UCS2实现的后，那它的单字节的接口怎么转换成UCS2的呢？

windows的API提供setlocale接口可以设置当前程序使用的字符编码信息。故你通过此接口告诉windows你当前程序中char*使用的字符编码是什么。

获取当前程序的字符编码信息：      char* pLocale = setlocale(LC_ALL, NULL);     可以了解到C++默认的字符编码是C locale。

设置当前程序为系统环境字符编码：char* pLocale = setlocale(LC_ALL, "");          如果是简体中文版的话，即等同与setlocale(LC_ALL, ".936")。

(2)、Linux系统

本人对linux系统的API实现了解不深，不过据网上资料说它是用的UTF-8字符编码实现的。

有兴趣的人可以研究libstdc++，它实现了linux上的标准C++接口，可以看它的源码了解了解，其中应该有不少调用linux系统函数的方法。

3、总结：

(1)、Windows的系统API使用UCS2的UTF16-LE编码实现，linux的系统API使用UTF-8编码实现。

(2)、JAVA默认的字符编码与jvm相关，一般默认为UCS2的UTF-16BE编码，与系统无关。

(3)、C/C++的默认字符编码为C locale，用户可以通过setlocale()修改当前程序的字符编码环境。