目录
2.2.2 UTF - Unicode Transformation Format
7.1.1 命令行工具iconv、enca、enconv - 文本文件内码转换
1 locale与字符集
1.1 locale
locale，意思是“一套和地域有关的习惯而形成的程序运行上下文”，locale 就是某一个地域内的人们的语言习惯和文化传统和生活习惯，一个地区的locale就是根据这几大类的习惯定义的。在Linux下，这些locale定义文件放在/usr/share/i18n/locales目录下面，例如en_US, zh_CN and de_DE@euro都是locale的定义文件。
由上述可以知道，locale 由很多方面组成，包括货币单位（LC_MONETARY）、数字形式（LC_NUMERIC）、时间显示格式（LC_TIME）等等，其中我们在本文中最关心的是字符类型（LC_CTYPE）。LC_CTYPE 规定了系统内有效的字符以及这些字符的分类，诸如什么是大写字母，小写字母，大小写转换，标点符号、可打印字符和其他的字符属性等方面。
1.2 字符集
字符集就是字符（尤其是非英语字符）在系统内的编码方式，也就是通常所说的内码。通俗地说，字符集就是一个字符在网络传输，计算机内部通信的时候的编码方式，对于不同字符的不同表达方式。
例如，UTF-8是目前流行的字符编码方式，UTF-8用一个字节表示常用的拉丁字母，用两个字节表示常用的符号，包括常用的中文字符，用三个表示不常用的字符，用四个字节表示其他的古怪的字符。而GB2312字符集就是用两个字节表示所有的字符。
2 常见字符集
2.1 Native ANSI 字符集
2.1.1 ASCII
ANSI 发布的字符编码标准，编码空间 0x00-0x7F，占用1个字节。
2.1.2 ISO-8859-1
ISO 发布的字符编码标准，又称 Latin-1 字符集，编码空间 0x00-0xFF，占用1个字节，可以编码大多数的西欧地区语言。
2.1.3 GB2312，GBK，GB18030
GB 系列是由中国国标局发布的字符编码方案（其中 GBK 不是正式标准），后期发布的版本兼容之前的（是之前的超集）。
GB2312
为1-2字节变长编码，汉字区中编码 6763 个字符。
GBK
是微软对 GB2312 的扩展，后由国标局作为指导性标准，为1-2字节变长编码，编码 21886 个字符，分为汉字区和图形符号区。汉字区编码 21003 个字符，支持CJK汉字（简体、繁体、常用日韩文），Windows 代码页为 CP936。
GB18030
为1-2-4字节变长编码，汉字区编码 27484 个字符，支持CJK汉字、常用藏文、蒙文、维吾尔文等，Windows 代码页为 CP54936。
补充：关于ANSI的由来
开始计算机只在美国用，所以一个八位的字节（可以组合出256（2的8次方）种不同状态）就已经够用了。
其中，编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机等遇上这些约定好的字节，就要做一些约定的动作。例如，遇上0x0a, 终端就换行，遇上0x07, 终端就响铃等等。于是就把这些0x20以下的字节状态称为”控制码”。
编号从33到127，则是把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是把这个方案叫做 ANSI 的”Ascii”编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
随着世界各地都开始使用计算机，很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称”扩展字符集”。从此之后，人类再没有新的状态可以用了，也许那个时候美帝国主义还没有想到第三世界国家的人们也希望可以用到计算机吧！
补充：关于GB2312/GBK/GB18030以及全角/半角字符的由来
等中国得以使用计算机时，已经没有可以利用的字节状态来表示汉字，而我们国家有6000多个常用汉字需要保存。于是中国把那些127号之后的奇异符号们直接取消掉，规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，这样就可以组合出大约7000多个简体汉字了。在这种编码方式里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。
这种汉字编码方案叫做 “GB2312”。可以看出，GB2312 是对 ASCII 的中文扩展。
随着计算机的普及，我们发现GB2312编码方案还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
再后来，少数民族也开始普及使用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
补充：关于ANSI与GB系列编码的关系
从前面的讲述可以看出，GB2312，GBK，GB18030本质上都是从ANSI衍生出来的，这些编码方案都将ASCII作为自己的子集实现，所以这些字符集又叫做本地化的（Native）ANSI 字符集。在windows平台下建立文本文件，只能看到ANSI、Unicode、Unicode big endian、UTF-8这四种编码，就是这个道理。
每个地区、国家都有自己的 Native ANSI 字符集，它们在 ASCII 子集部分是相同的，其它部分都不尽相同。
2.2 Unicode 字符集
Unicode要比以前我们所以为的复杂的多，它是一种编码设计标准或者说思路。
2.2.1 UCS
Native ANSI字符集的问题在于，各个国家甚至各个地区都在搞出一套自己的编码标准，导致互相之间谁也不懂谁的编码，谁也不支持其他人的编码。此时，ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：设计一个可以包括地球上所有文化、所有字母和符号的编码方案！他们打算叫它”Universal Multiple-Octet Coded Character Set”，简称 UCS，俗称 “UNICODE”。
UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间不再成为问题。于是 ISO 直接规定编码必须用两个字节，也就是16位来统一表示所有的字符，这也就是UCS-2。对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于”半角”英文符号只需要用到低8位，所以其高8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
如前所述，UNICODE 是用两个字节来表示为一个字符，总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！
UNICODE 的问题在于，它在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与 UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。
2.2.2 UTF - Unicode Transformation Format
与 UNICODE 一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，例如UTF8、UTF16等。顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到UTF时并不是直接的对应，而是要过一些算法和规则来转换。
简单来说，UNICODE规定符号的二进制代码，但没有定义符号的存储和传输方案。UTF就是解决这个问题的，它是对 UCS 再次编码映射得到的字符集，某种程度可以看作是Unicode的具体实现方式。
2.2.3 UTF-8
UTF-8 使用 8 位单元（1字节）变长编码，并将 ASCII 作为子集，这样就可以将 UTF-8 当做一种 MBCS 的 Native ANSI 字符集的实现，因此 UTF-8 需要使用1字节流方式解析字符。
UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8 和所有的 Native ANSI 字符集一样，当数据块中只有 ASCII 子集部分的字符时，是无法区分这个数据块用哪种 Native ANSI 字符集进行编码的，因为这部分的编码映射关系对于所有的 Native ANSI 字符集是共享的，只有当未来数据块中包含像CJK汉字这种在 ASCII 子集之外的字符时，采用不同 Native ANSI 字符集的数据块才会表现出不同。
2.2.4 BOM
如前所述，当数据块中只有 ASCII 子集部分的字符时，是无法区分这个数据块用哪种 Native ANSI 字符集进行编码的。那么如何标识使用的是编码是UTF-8呢？
方法就是在UTF-8 文件头部放置 BOM（byte order mark）。
先来说说BOM的本义：
BOM（byte order mark）本来是为 UTF-16 和 UTF-32 准备的，用于标记字节序（byte order）的标识，也就是用于标识一个 UCS 字符数据块是采用 Big Endian 还是 Little Endian 进行存储。在 Unicode 概念中有一个字符，它不映射到任何地区、国家中的可能字符，Unicode 标准对它的注释为：ZERO WIDTH NO-BREAK SPACE）。当开始处理 UCS 数据块时，UCS 标准建议先处理这个 ZERO WIDTH NO-BREAK SPACE 字符，比如 UCS-2 数据块，如果一开始读到/写入的字节序列是 FF FE（8 进制：377 376），那么说明后续的 UCS-2 按 Little Endian 存储；如果是 FE FF（8进制：376 377），则说明后续的 UCS-2 按 Big Endian 存储。
BOM的主要用途是网络传输时候标明字节的序列（先传高位还是低位），后续会有说明。然而微软将BOM作为区分UTF-8和ASCII的标识。
标识UTF-8的BOM字节序列是：EF BB BF，在文件中放置该BOM字节序列是微软的习惯，因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，但此时，BOM 已经失去其在 UCS-2 中作为标识字节序大小端的作用，而仅把 EF BB BF 作为 UTF-8 编码的标识功能。当数据块的开始有这个字节序列时就说明后续字符采用 UTF-8 编码。
但是BOM不受欢迎主要是在UNIX环境下，这方面资料可以参考： http://www.cnblogs.com/findumars/p/3620078.html
3 单字节字符集与多字节字符集
ASCII、ISO-8859-1 这种用1个字节编码的字符集，叫做单字节字符集（SBCS - Single-Byte Character Set）。
UTF-8、GB 系列这种用1-2、4个不等字节编码的字符集，叫做多字节字符集（MBCS - Multi-Byte Character Set）。
由 SBCS 编码的数据可以随机访问，从任意字节偏移开始解编码都能保证解析出的字符和后继字符是正确的。
而由MBCS编码的数据，只能将其作为字节流进行解析，如果从随机任意的字节偏移开始解编码，有可能定位到切断一个字符的中间位置，导致后继解析出的字符连续出错。作为字节流时，是从某个标识位置进行解析字符，比如从数据的开始位置，或从每个新行符 ‘\n’ 之后开始解析字符。
4 记事本程序（notepad）里的编码
在Windows平台下的记事本小程序Notepad.exe有四种编码方案：ANSI，Unicode，Unicode big endian 和 UTF-8。
1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。
2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。
3）Unicode big endian编码与上一个选项相对应。
4）UTF-8编码，也就是上一节谈到的编码方法。
5 关于Little endian和Big endian
Unicode码可以采用UCS-2格式直接存储。以汉字”严“为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。
这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。
因此，第一个字节在前，就是”大头方式“（Big endian），第二个字节在前就是”小头方式“（Little endian）。
那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？
Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。
如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。
Little endian和Big endian主要应用在数据的的网络传输中。在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构，而另一些是采用高位先发送的方式。在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位，那就发送”FEFF”，反之，则发送”FFFE”。
6 如何利用程序检查文件的字符集编码
6.1 检查头两个字节
从前面的讲述可以知道，不同的编码方式，在文件的头几个字节还是差别的，具体如下：
存在的问题是：
1）无法进一步精确区分ANSI下的具体字符集，例如ASCII，GB2312等；
2）如果编码是UTF-8 no BOM，那用上述方法就无法判断文件是ANSI还是UTF-8 no BOM。
6.2 利用linux的file命令
file命令可以查看文件的编码信息，例如：file test.txt
test.txt: ISO-8859 text, with CRLF line terminators
test.txt: ASCII text, with CRLF line terminators
test.txt: UTF-8 Unicode (with BOM) text, with CRLF line terminators
可以利用popen函数执行shell命令并对结果进行分析，从而获得文件的字符集编码。
6.3 uchardet
识别UTF-16、UTF-32是轻而易举的（感兴趣可以查一下，这些编码在最前面的几个字节有着奇妙的规律），但是识别它的编码是GB2312还是big5，却没那么容易。
uchardet是一个开源的用于文本编码检测的C语言库，其功能模块是用C++实现的，通过一定数量的字符样本独立的分析出文本的编码，当前已经支持UTF-8/GB13080/BIG5等共30多种编码。
使用uchardet库的方法：
1、下载安装uchardet库，以debian系举例：
sudo apt install libuchardet-dev uchardet
2、引入libuchardet-dev代码使用(不区分文件名、文件内容，只需指定检测的字符串数据)
- uchardet_new创建handle
- uchardet_handle_data送入数据
- uchardet_data_end表示数据到此结束
- uchardet_get_charset取得字符串编码的名称。进行对应处理。
- uchardet_delete释放资源。
样例：
#include <uchardet/uchardet.h>
const gchar * detection_encoding(const gchar *src)
{
const gchar *original = g_strdup(src);
const gchar *encoding = NULL;
uchardet_t ud = NULL;
/* 1.创建一个编码检测器 */
ud = uchardet_new();
/* 2.将数据馈送到编码检测器 */
uchardet_handle_data(ud, original, strlen(original));
/* 3.向编码检测器通知数据结束 */
uchardet_data_end(ud);
/* 4.获取检测到的编码的iconv兼容名称，失败返回空串"" */
encoding = g_strdup(uchardet_get_charset(ud));
/* 5.删除编码检测器 */
uchardet_delete(ud);
g_free(original);
return encoding;
}我们拿uchardet取得编码的名称，同样通过下面映射也可以找到代码页id
// define
#define MAP_ITEM(str, name, id) { str, CodePage(id, CharEncoding:: ## name) }
// struct
struct CodePage
{
int locid; // 代码页id(只有多字节编码会有这个值)
CharEncoding encoding; // 编码方式
CodePage() = default;
CodePage(int _id, CharEncoding _enc) noexcept
{
locid = _id;
encoding = _enc;
}
};
// enum
enum class CharEncoding // 支持的字符编码
{
UTF16_LE, UTF16_BE, UTF32_LE, UTF32_BE,
UTF8_BOM, UTF_8, ASCII,
ISO_8859_1, ISO_8859_2, ISO_8859_3, ISO_8859_4,
ISO_8859_5, ISO_8859_6, ISO_8859_7, ISO_8859_8,
ISO_8859_9, ISO_8859_13, ISO_8859_15,
WINDOWS_1250, WINDOWS_1251, WINDOWS_1252, WINDOWS_1253,
WINDOWS_1254, WINDOWS_1255, WINDOWS_1256, WINDOWS_1257,
WINDOWS_1258,
EUC_JP, BIG5, IBM855, GB2312,
ISO_2022_JP, KOI8_R, SHIFT_JIS, GB18030,
MAC_CYRILLIC,
UNKNOWN
};
// table
static const std::map<std::string, CodePage> codePage =
{ // 受支持的编码表
MAP_ITEM("BIG5", BIG5, 950),
MAP_ITEM("IBM855", IBM855, 855),
MAP_ITEM("GB2312", GB2312, 936),
MAP_ITEM("ASCII", ASCII, CP_ACP),
MAP_ITEM("UTF-8", UTF_8, CP_UTF8),
MAP_ITEM("EUC_JP", EUC_JP, 20932),
MAP_ITEM("KOI8-R", KOI8_R, 20866),
MAP_ITEM("GB18030", GB18030, 54936),
MAP_ITEM("SHIFT_JIS", SHIFT_JIS, 932),
MAP_ITEM("ISO-8859-1", ISO_8859_1, 28591),
MAP_ITEM("ISO-8859-2", ISO_8859_2, 28592),
MAP_ITEM("ISO-8859-3", ISO_8859_3, 28593),
MAP_ITEM("ISO-8859-4", ISO_8859_4, 28594),
MAP_ITEM("ISO-8859-5", ISO_8859_5, 28595),
MAP_ITEM("ISO-8859-6", ISO_8859_6, 28596),
MAP_ITEM("ISO-8859-7", ISO_8859_7, 28597),
MAP_ITEM("ISO-8859-8", ISO_8859_8, 28598),
MAP_ITEM("ISO-8859-9", ISO_8859_9, 28599),
MAP_ITEM("ISO-2022-JP",ISO_2022_JP, 50222),
MAP_ITEM("ISO-8859-13", ISO_8859_13, 28603),
MAP_ITEM("ISO-8859-15", ISO_8859_15, 28605),
MAP_ITEM("WINDOWS-1250", WINDOWS_1250, 1250),
MAP_ITEM("WINDOWS-1251", WINDOWS_1251, 1251),
MAP_ITEM("WINDOWS-1252", WINDOWS_1252, 1252),
MAP_ITEM("WINDOWS-1253", WINDOWS_1253, 1253),
MAP_ITEM("WINDOWS-1254", WINDOWS_1254, 1254),
MAP_ITEM("WINDOWS-1255", WINDOWS_1255, 1255),
MAP_ITEM("WINDOWS-1256", WINDOWS_1256, 1256),
MAP_ITEM("WINDOWS-1257", WINDOWS_1257, 1257),
MAP_ITEM("WINDOWS-1258", WINDOWS_1258, 1258),
MAP_ITEM("MAC-CYRILLIC", MAC_CYRILLIC, 10007),
};
std::string temp(code);
if (codePage.count(temp) == 0) // 不被支持的编码
{
break;
}
else {
ret = codePage.find(temp)->second;
}
// 现在, ret就是代码页信息, ret.id就是我们需要的代码页id3、命令行使用方式
uchardet [File]...
7 转码
7.1 iconv/libiconv转码工具
linux/glibc字段的转码工具。
7.1.1 命令行工具iconv、enca、enconv - 文本文件内码转换
iconv一般系统自带。
kylin@kylin-pc:~/文档$ iconv --help
用法： iconv [选项...] [文件...]
转换给定文件的编码。
输入/输出格式规范：
-f, --from-code=名称 原始文本编码
-t, --to-code=名称 输出编码
信息：
-l, --list 列举所有已知的字符集
输出控制：
-c 从输出中忽略无效的字符
-o, --output=文件 输出文件
-s, --silent 关闭警告
--verbose 打印进度信息
-?, --help 给出此帮助列表
--usage 给出简要的用法信息
-V, --version 打印程序版本号
长选项的强制或可选参数对对应的短选项也是强制或可选的。enca和enconv需要安装：
sudo apt install enconv enca
使用方式：iconv -f GBK -t UTF-8 file1 -o file2
iconv命令用于转换指定文件的编码,默认输出到标准输出设备,亦可指定输出文件。 例子: iconv -f utf-8 -t gb2312 aaa.txt >bbb.txt 这个命令读取aaa.txt文件，从utf-8编码转换为gb2312编码,其输出定向到bbb.txt文件。
更好的傻瓜型命令行工具enca，它不但能智能的识别文件的编码，而且还支持成批转换。
注:enca和enconv命令是一样的
1.安装 $sudo apt-get install enca 2.查看当前文件编码 enca -L zh_CN ip.txt Simplified Chinese National Standard; GB2312 Surrounded by/intermixed with non-text data 3.转换 命令格式如下 $enca -L 当前语言 -x 目标编码 文件名 例如要把当前目录下的所有文件都转成utf-8 enca -L zh_CN -x utf-8 * enca -L zh_CN file 检查文件的编码 enca -L zh_CN -x UTF-8 file 将文件编码转换为"UTF-8"编码 enca -L zh_CN -x UTF-8 < file1 > file2 如果不想覆盖原文件可以这样，很简单吧。
7.1.2 libiconv转码库(不区分文件名、文件内容，只需指定转码的字符串数据，故也能用户文件名转码)
#include <iconv.h>
iconv_t iconv_open(const char *tocode, const char *fromcode);
size_t iconv(iconv_t cd,
char **restrict inbuf, size_t *restrict inbytesleft,
char **restrict outbuf, size_t *restrict outbytesleft);
int iconv_close(iconv_t cd);【iconv_open】
iconv_open打开iconv描述符
tocode指定目标字符编码，fromcode指定源字符编码，不区分大小写
返回-1表示错误（errno==EINVAL表示不支持该转换），成功返回iconv描述符
常见通用字符编码：
- ""（空字符串）：当前locale下char对应的编码，使用前需setlocale(LC_CTYPE, "");
- libiconv和musl还支持"CHAR"，但glibc不支持，因此此处应使用""（空字符串）
- "WCHAR_T"：wchar_t对应的编码（Linux下是UCS-4也叫UTF-32）
- "UTF-8"：UTF-8编码（8位变长Unicode编码）
- "UTF-16[LE|BE]"：UTF-16编码[小端|大端]（16位变长Unicode编码）
- "UCS-4[LE|BE]"或"UTF-32[LE|BE]"：UCS-4编码[小端|大端]（也叫UTF-32，32位定长Unicode编码）
- "UCS-2[LE|BE]"：UCS-2编码（16位定长Unicode编码，已过时）
- "ASCII"：7位ASCII编码
- "ISO-8859-1"：8位ISO-8859-1编码，对应Unicode前256个字符（可用于无损将字节升级为UTF-16、UCS-4也叫UTF-32等Unicode编码）
常见简体中文字符编码（需要库支持才能使用，glibc和libiconv支持较好，musl当前只有非常原始的支持，而且只能作为fromcode，不能作为tocode）：
- "GB18030"：当前的国标中文字符编码（1,2,4字节变长）
- GB18030从未被Windows作为默认字符编码，只是以兼容包和可安装代码页的形式提供支持，本世纪初的早期Linux和Unix发行版曾将其作为默认字符编码
- 简体中文DOS和Windows使用的中文字符编码：
- DOS、Windows 3.x（"GB2312"）：基于GB2312标准
- Windows 95（"GBK"）：基于GBK标准
- Windows 98 SE：添加了欧元符号0x80（非标准扩展）
- Windows 2000（"CP936"）：又添加了一些映射到Unicode的PUA区的新汉字（非标准扩展）
- 当前Windows使用Windows 2000版本，即"CP936"
- GB18030基于GBK，GBK基于GB2312，GB18030并不包含Windows 98 SE和Windows 2000添加的非标准扩展部分
- glibc中"CP936"和"GBK"相同，均为Windows 2000版本，libiconv中两者不同，"CP936"指Windows 2000版本，"GBK"指Windows 95版本，musl中当前只有只能作为fromcode的"GBK"，被实现为不支持欧元符号的GB18030的1,2字节子集
【iconv】
iconv函数转换字符
cd是iconv_open返回的描述符
inbuf/outbuf指向char*变量，该变量记录输入/输出缓冲区输入/输出字符的位置
inbytesleft/outbytesleft指向size_t变量，该变量记录输入/输出缓冲区还剩下多少字节未使用
返回-1表示部分失败（errno==EINVAL,EILSEQ,E2BIG），全部成功返回>=0的值，表示转换的字符个数
- 返回>=0，表示成功进行所有转换
- 如果inbytesleft==0，一般表示全部转换完毕
- 完成所有转换之后，再将inbuf或*inbuf置为NULL再调用一次iconv，以输出所有尚未输出的字符
- 返回-1，errno==EINVAL，表示在字符串末尾遇到了不完全的多字节序列，*inbuf指向该序列开头
- 可以对源字符串进行拼接后再次调用iconv
- 如果没有新字符串用于拼接了，说明最后一个字符非法，可以*inbuf++;、*inbytes--;，手动输出替换字符
- 返回-1，errno==EILSEQ，表示遇到了不合法的多字节序列，*inbuf指向该序列开头
- 可以*inbuf++;、*inbytes--;，手动输出替换字符，然后再次尝试调用iconv
- 返回-1，errno==E2BIG，表示缓冲区太小，*inbuf指向未完成转换的第一个字符
- 如果*outbuf/*outbytesleft没有变化，说明没有任何字符输出，需要扩大缓冲区
- 如果*outbuf/*outbytesleft有变化，说明已输出部分字符，可以扩大缓冲区，也可以指定一个新缓冲区，最后进行拼接（或输出到stdout）
- iconv返回失败并不表示全部失败，只表示遇到了异常字符，需要按照部分成功处理
【iconv_close】
iconv_close关闭iconv描述符
7.2 glib库的api转码
// #include <glib/gconvert.h>
typedef struct _GIConv *GIConv;
GLIB_AVAILABLE_IN_ALL
GIConv g_iconv_open (const gchar *to_codeset,
const gchar *from_codeset);
GLIB_AVAILABLE_IN_ALL
gsize g_iconv (GIConv converter,
gchar **inbuf,
gsize *inbytes_left,
gchar **outbuf,
gsize *outbytes_left);
GLIB_AVAILABLE_IN_ALL
gint g_iconv_close (GIConv converter);
GLIB_AVAILABLE_IN_ALL
gchar* g_convert (const gchar *str,
gssize len,
const gchar *to_codeset,
const gchar *from_codeset,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC;
GLIB_AVAILABLE_IN_ALL
gchar* g_convert_with_iconv (const gchar *str,
gssize len,
GIConv converter,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC;
GLIB_AVAILABLE_IN_ALL
gchar* g_convert_with_fallback (const gchar *str,
gssize len,
const gchar *to_codeset,
const gchar *from_codeset,
const gchar *fallback,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC;
/* Convert between libc's idea of strings and UTF-8.
*/
GLIB_AVAILABLE_IN_ALL
gchar* g_locale_to_utf8 (const gchar *opsysstring,
gssize len,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC;
GLIB_AVAILABLE_IN_ALL
gchar* g_locale_from_utf8 (const gchar *utf8string,
gssize len,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC;
/* Convert between the operating system (or C runtime)
* representation of file names and UTF-8.
*/
GLIB_AVAILABLE_IN_ALL
gchar* g_filename_to_utf8 (const gchar *opsysstring,
gssize len,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC;
GLIB_AVAILABLE_IN_ALL
gchar* g_filename_from_utf8 (const gchar *utf8string,
gssize len,
gsize *bytes_read,
gsize *bytes_written,
GError **error) G_GNUC_MALLOC; GIConv cd = g_iconv_open("UTF-8", file_name_coding);
if (cd == NULL) {
fprintf(stderr, "coding conver open fail!\n");
return false;
}
gsize result = g_iconv(cd, &src_str_ptr, &src_str_len, &dest_str_ptr, &dest_str_len);
if (result == (gsize)-1) {
g_iconv_close(cd);
fprintf(stderr, "first coding conver failed! \n");
return false;
}
g_iconv_close(cd);
7.3 convmv-文件名转码工具
convmv就是更改文件名编码方式的一个工具。也是一个开源源码的命令行工具。
安装命令：sudo apt install convmv
kylin@kylin-pc:~/文档$ convmv --help
Your Perl version has fleas #22111 #37757 #49830
convmv 2.05 - converts filenames from one encoding to another
Copyright (C) 2003-2018 Bjoern JACKE <bjoern@j3e.de>
This program comes with ABSOLUTELY NO WARRANTY; it may be copied or modified
under the terms of the GNU General Public License version 2 or 3 as published
by the Free Software Foundation.
USAGE: convmv [options] FILE(S)
-f enc encoding *from* which should be converted
-t enc encoding *to* which should be converted
-r recursively go through directories
-i interactive mode (ask for each action)
--nfc target files will be normalization form C for UTF-8 (Linux etc.)
--nfd target files will be normalization form D for UTF-8 (OS X etc.)
--qfrom be quiet about the "from" of a rename (if it screws up your terminal e.g.)
--qto be quiet about the "to" of a rename (if it screws up your terminal e.g.)
--exec c execute command instead of rename (use #1 and #2 and see man page)
--list list all available encodings
--lowmem keep memory footprint low (see man page)
--map m apply an additional character mapping
--nosmart ignore if files already seem to be UTF-8 and convert if posible
--notest actually do rename the files
--replace will replace files if they are equal
--unescape convert%20ugly%20escape%20sequences
--upper turn to upper case
--lower turn to lower case
--parsable write a parsable todo list (see man page)
--help print this help
命令使用样例：convmv -f gbk -t utf-8 -r –notest /your_path_or_file
在c代码中使用此命令，样例：
static void
decode_file_name_by_convmv( const gchar *file_path,
const gchar *to_codeset,
const gchar *from_codeset)
{
GPtrArray *argv = NULL;
gchar *stdout_str = NULL;
gchar *stderr_str = NULL;
gint estatus = 0;
GError *error = NULL;
int i = 0;
argv = g_ptr_array_new ();
g_ptr_array_add (argv, (gpointer)"/usr/bin/convmv");
g_ptr_array_add (argv, (gpointer)"-f");
/* 当前系统中convmv不识别GB18030编码，故转为GBK; windows上文件名编码为GB18030，linux系统上文件名编码为utf-8 */
if (from_codeset == NULL || strlen(from_codeset) == 0 || strcmp(from_codeset, "GB18030") == 0)
g_ptr_array_add (argv, (gpointer)"GBK");
else
g_ptr_array_add (argv, (gpointer)from_codeset);
g_ptr_array_add (argv, (gpointer)"-t");
g_ptr_array_add (argv, (gpointer)to_codeset);
g_ptr_array_add (argv, (gpointer)"--notest");
g_ptr_array_add (argv, (gpointer)"-r");
g_ptr_array_add (argv, (gpointer)file_path);
g_ptr_array_add (argv, NULL);
#ifdef MATE_ENABLE_DEBUG
{
for(i = 0;i < argv->len;i++) {
g_print("%s ", (gchar *)(argv->pdata[i]));
}
g_print("\n");
}
#endif
g_spawn_sync (NULL, (char**)argv->pdata, NULL, G_SPAWN_DEFAULT, NULL, NULL, &stdout_str, &stderr_str, &estatus, &error);
g_print("%s \n", stdout_str);
g_print("%s \n", stderr_str);
g_free(stdout_str);
g_free(stderr_str);
g_ptr_array_free (argv, TRUE);
return ;
}参考：
[C++基础] 字符编码_uchardet_WangBo_NLPR的博客-CSDN博客
各种编码UNICODE、UTF-8、ANSI、ASCII、GB2312、GBK详解
http://blog.csdn.net/lvxiangan/article/details/8151670
浅谈C/C++编程中的字符编码转换
http://blog.csdn.net/benkaoya/article/details/59522148
字符集编码与 C/C++ 源文件字符编译乱弹
http://jimmee.iteye.com/blog/2165685
UTF8最好不要带BOM，附许多经典评论
http://www.cnblogs.com/findumars/p/3620078.html
用C语言检测文本编码的方法
http://blog.csdn.net/turingo/article/details/8136644
5882
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
