linuxiconvlatin1转utf8

Posted 2023-04-14

参考技术A linux下使用iconv命令转换gbk编码为UTF-8编码
1.
通过iconv -l 命令查看,其支持的编码格式还不少,之间可以互相转换
2.
转换gbk编码文件为utf-8编码文件简洁命令:iconv -f gbk -t utf-8 index.html > aautf8.html -f指的是原始文件编码,-t是输出编码 index.html 是原始文件 aautf8.html是输出结果文件
3.
转换gbk编码文件为utf-8编码文件详细命

转: utf16编码格式（unicode与utf16联系）

转自： http://www.cnblogs.com/dragon2012/p/5020259.html

 

UTF-16是Unicode字符集的一种转换方式，即把Unicode的码位转换为16比特长的码元串行，以用于数据存储或传递。UTF-16编码规则如下：

2.2.1 从U+D800到U+DFFF的码位（代理区）

因为Unicode字符集的编码值范围为0-0x10FFFF，而大于等于0x10000的辅助平面区的编码值无法用2个字节来表示，所以Unicode标准规定：基本多语言平面内，U+D800..U+DFFF的值不对应于任何字符，为代理区。因此，UTF-16利用保留下来的0xD800-0xDFFF区段的码位来对辅助平面的字符的码位进行编码。

但是在使用UCS-2的时代，U+D800..U+DFFF内的值被占用，用于某些字符的映射。但只要不构成代理对，许多UTF-16编码解码还是能把这些不符合Unicode标准的字符映射正确的辨识、转换成合规的码元. 按照Unicode标准，这种码元串行本来应算作编码错误.

2.2.2 从U+0000至U+D7FF以及从U+E000至U+FFFF的码位

第一个Unicode平面（BMP），码位从U+0000至U+FFFF（除去代理区），包含了最常用的字符。UTF-16与UCS-2编码在这个范围内的码位为单个16比特长的码元，数值等价于对应的码位。BMP中的这些码位是仅有的码位可以在UCS-2被表示。

2.2.3 从U+10000到U+10FFFF的码位

辅助平面(Supplementary Planes)中的码位，大于等于0x10000，在UTF-16中被编码为一对16比特长的码元（即32bit，4Bytes），称作 code units called a 代理对（surrogate pair），具体方法是：

Ø 码位减去0x10000, 得到的值的范围为20比特长的0..0xFFFFF（因为Unicode的最大码位是0x10ffff，减去0x10000后，得到的最大值是0xfffff，所以肯定可以用20个二进制位表示），写成二进制形式：yyyy yyyy yyxx xxxx xxxx。

Ø 高位的10比特的值（值的范围为0..0x3FF）被加上0xD800得到第一个码元或称作高位代理（high surrogate）, 值的范围是0xD800..0xDBFF。由于高位代理比低位代理的值要小，所以为了避免混淆使用，Unicode标准现在称高位代理为前导代理(lead surrogates)。

Ø 低位的10比特的值（值的范围也是0..0x3FF）被加上0xDC00得到第二个码元或称作低位代理（low surrogate）, 现在值的范围是0xDC00..0xDFFF。 由于低位代理比高位代理的值要大，所以为了避免混淆使用，Unicode标准现在称低位代理为后尾代理(trail surrogates)。

Ø 最终的UTF-16（4字节）的编码（二进制）就是：110110yyyyyyyyyy 110111xxxxxxxxxx。

按照上述规则，Unicode编码0x10000-0x10FFFF的UTF-16编码有两个WORD，第一个WORD的高6位是110110，第二个WORD的高6位是110111。可见，第一个WORD的取值范围（二进制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。上面所说的从U+D800到U+DFFF的码位（代理区），就是为了将一个WORD（2字节）的UTF-16编码与两个WORD的UTF-16编码区分开来。

由于高位代理、低位代理、BMP中的有效字符的码位，三者互不重叠，搜索是简单的: 一个字符编码的一部分不可能与另一个字符编码的不同部分相重叠。这意味着UTF-16是自同步（self-synchronizing）：可以通过仅检查一个码元就可以判定给定字符的下一个字符的起始码元。 UTF-8也有类似优点，但许多早期的编码模式就不是这样，必须从头开始分析文本才能确定不同字符的码元的边界。

由于最常有的字符都在基本多文种平面中，许多软件的处理代理对的部分往往得不到充分的测试。这导致了一些长期的bug与潜在安全漏洞，甚至在广为流行得到良好评价的应用软件