最近再处理一堆网上扒来的页面，原网页是gbk的，需要进行简单处理成utf-8的，自然使用iconv命令:

iconv -f gbk -t utf-8 ./path/to/wantConv.htm >/tmp/temp.txt && mv -f /tmp/temp.txt ./path/to/wantConv.htm

批量执行时有报错：

iconv: illegal input sequence at position 2062

无效的输入序列。。这说明gbk仍然无法“覆盖”原文档中的所有字符。突然想起gbk字符集范围问题。先粘贴最终命令：

iconv -f GB18030//TRANSLIT -t utf-8 ./wgwx/cpxs/hbsk/178.htm >/tmp/temp.txt && mv -f /tmp/temp.txt ./wgwx/cpxs/hbsk/178.htm

首先使用GB18030字符集（7W多汉字），其次增加转换选项 //TRANSLIT。关于这里的选项还有一个是//IGNORE。

//IGNORE：这是在指定目标编码时附加的一个标志，它告诉 iconv 忽略无法转换的字符而不是停止转换。例如，如果一个字符在目标编码中不存在，iconv 将简单地跳过该字符并继续转换其余部分。

//TRANSLIT：与 //IGNORE 类似，但它尝试用最接近的等效字符来替换无法直接转换的字符。如果找不到近似的字符，则会使用一个替代符号（如问号）。

再封装一下：

function gbk2utf8() { iconv -f GB18030//TRANSLIT -t utf-8 "$1" >/tmp/temp.txt && mv -f /tmp/temp.txt "$1" ; }

征引网络的资料放在下面：

兼容性关系是GB18030兼容GBK，GBK兼容GB2312，GB2312兼容ASCII。所谓兼容，你可以简单理解为子集、不冲突的关系。例如GB2312编码的文件中可以出现ASCII字符，GBK编码的文件中可以出现GB2312和ASCII字符，GB18030编码的文件可以出现GBK、GB2312、ASCII字符。
【1】ASCII 每个字符占据1bytes，用二进制表示的话最高位必须为0（扩展的ASCII不在考虑范围内），因此ASCII只能表示128个字
【2】GB2312 最早一版的中文编码，每个字占据2bytes。由于要和ASCII兼容，那这2bytes最高位不可以为0了（否则和ASCII会有冲突）。在GB2312中收录了6763个汉字以及682个特殊符号，已经囊括了生活中最常用的所有汉字。
【3】GBK 由于GB2312只有6763个汉字，我汉语博大精深，只有6763个字怎么够？于是GBK中在保证不和GB2312、ASCII冲突（即兼容GB2312和ASCII）的前提下，也用每个字占据2bytes的方式又编码了许多汉字。经过GBK编码后，可以表示的汉字达到了20902个，另有984个汉语标点符号、部首等。值得注意的是这20902个汉字还包含了繁体字。
【4】GB18030 然而，GBK的两万多字也已经无法满足我们的需求了，还有更多可能你自己从来没见过的汉字需要编码。这时候显然只用2bytes表示一个字已经不够用了（2bytes最多只有65536种组合，然而为了和ASCII兼容，最高位不能为0就已经直接淘汰了一半的组合，只剩下3万多种组合无法满足全部汉字要求）。因此GB18030多出来的汉字使用4bytes编码。当然，为了兼容GBK，这个四字节的前两位显然不能与GBK冲突（实操中发现后两位也并没有和GBK冲突）。我国在2000年和2005年分别颁布的两次GB18030编码，其中2005年的是在2000年基础上进一步补充。至此，GB18030编码的中文文件已经有七万多个汉字了，甚至包含了少数民族文字。