浅谈Java中Unicode的编码和实现
unicode码和ascii码区别
Unicode的编码和实现
⼤概来说，Unicode编码系统可分为编码⽅式和实现⽅式两个层次。
编码⽅式
字符是抽象的最⼩⽂本单位。它没有固定的形状（可能是⼀个字形），⽽且没有值。“A”是⼀个字符，“€”也是⼀个字符。字符集是字符的集合。编码字符集是⼀个字符集，它为每⼀个字符分配⼀个唯⼀数字。
Unicode 最初设计是作为⼀种固定宽度的 16 位字符编码。也就是每个字符占⽤2个字节。这样理论上⼀共最多可以表⽰
216（即65536）个字符。上述16位统⼀码字符构成基本多⽂种平⾯。基本多⽂种平⾯的字符的编码为U+hhhh，其中每个h代表⼀个⼗六进制数字。
很明显，16 位编码的所有 65，536 个字符并不能完全表⽰全世界所有正在使⽤或曾经使⽤的字符。于是，Unicode 标准已扩展到包含多达 1，112，064 个字符。那些超出原来的 16 位限制的字符被称作增补字符。Unicode 标准 2.0 版是第⼀个包含
启⽤增补字符设计的版本，但是，直到 3.1 版才收⼊第⼀批增补字符集。
Unicode字符平⾯映射
⽬前的Unicode字元分为17组编排，每组称为平⾯（Plane），⽽每平⾯拥有65536（即216）个代码点。然⽽⽬前只⽤了少数平⾯。
平⾯始末字元值中⽂名称英⽂名称
0号平⾯U+0000 -
U+FFFF基本多⽂种平⾯Basic Multilingual Plane，简称BMP
1号平⾯U+10000 -
U+1FFFF多⽂种补充平⾯
Supplementary Multilingual Plane，简
称SMP
2号平⾯U+20000 -
U+2FFFF表意⽂字补充平⾯
Supplementary Ideographic Plane，简
称SIP
3号平⾯U+30000 -
U+3FFFF
表意⽂字第三平⾯（未正
式使⽤）
Tertiary Ideographic Plane，简称TIP
4号平
⾯
⾄
13号平⾯U+40000 -
U+DFFFF（尚未使⽤）
14号平⾯U+E0000 -
U+EFFFF特别⽤途补充平⾯
Supplementary Special-purpose
Plane，简称SSP
15号平⾯U+F0000 -
U+FFFFF
保留作为私⼈使⽤区（A
区）
Private Use Area-A，简称PUA-A
16号平⾯U+100000 -
U+10FFFF
保留作为私⼈使⽤区（B
区）
Private Use Area-B，简称PUA-B
增补字符是代码点在 U+10000 ⾄ U+10FFFF 范围之间的字符（上述表格中1号平⾯~16号平⾯之间的），也就是那些使⽤原始的 Unicode 的 16 位设计⽆法表⽰的字符。从 U+0000 ⾄ U+FFFF 之间的字符集有时候被称为基本多语⾔⾯（BMP）。因此，每⼀个 Unicode 字符要么属于 BMP，要么属于增补字符。
实现⽅式
UTF-32、UTF-16 和 UTF-8 是具体的实现⽅案。Unicode的实现⽅式不同于编码⽅式。⼀个字符的Unicode编码是确定的。但是在实际传输过程中，由于不同系统平台的设计不⼀定⼀致，以及出于节省空间的⽬的，对Unicode编码的实现⽅式有所不同。Unicode的实现⽅式称为Unicode转换格式（Unicode Transformation Format，简称为UTF）。
例如，如果⼀个仅包含基本7位ASCII字符的Unicode⽂件，如果每个字符都使⽤2字节的原Unicode编码传输，其第⼀字节的8位始终为0。这就造成了⽐较⼤的浪费。对于这种情况，可以使⽤UTF-8编码，这是⼀种变长编码，它将基本7位ASCII字符仍⽤7位编码表⽰，占⽤⼀个字节（⾸位补0）。⽽遇到与其他Unicode字符混合的情况，将按⼀定算法转换，每个字符使⽤1-3个字节编码，并利⽤⾸位为0或1进⾏识别。这样对以7位ASCII字符为主的西⽂⽂档就⼤幅节省了编码长度（具体⽅案参见UTF-8）。类似的，对未来会出现的需要4个字节的辅助平⾯字符和其他UCS-4扩充字符，2字节编码的UTF-16也需要通过⼀定的算法进⾏转换。
再如，如果直接使⽤与Unicode编码⼀致（仅限于BMP字符）的UTF-16编码，由于每个字符占⽤了两个字节，在麦⾦塔电脑（Mac）机和个⼈电脑上，对字节顺序的理解是不⼀致的。这时同⼀字节流可能会被解释为不同内容，如某字符为⼗六进制编码4E59，按两个字节拆分为4E和59，在Mac上读取时是从低字节开始，那么在Mac OS会认为此4E59编码为594E，到的字符为“奎”，⽽在Windows上从⾼字节开始读取，则编码为U+4E59的字符为“⼄”。就是说在Windows下以UTF-16编码保存⼀个字符“⼄”，在Mac OS环境下打开会显⽰成“奎”。此类情况说明UTF-16的编码顺序若不加以⼈为定义就可能发⽣混淆，于是在UTF-16编码实现⽅式中使⽤了⼤端序（Big-Endian，简写为UTF-16 BE）、⼩端序（Little-Endian，简写为UTF-16 LE）的概念，以及可附加的字节顺序记号解决⽅案，⽬前在PC机上的Windows系统和Linux系统对于UTF-16编码默认使⽤UTF-16 LE。（具体⽅案参见UTF-16）
此外Unicode的实现⽅式还包括UTF-7、Punycode、CESU-8、SCSU、UTF-32、GB18030等，这些实现⽅式有些仅在⼀定的国家和地区使⽤，有些则属于未来的规划⽅式。⽬前通⽤的实现⽅式是UTF-16⼩端序（LE）、UTF-16⼤端序（BE）和UTF-8。在微软公司Windows XP附带的记事本（Notepad）中，“另存为”对话框可以选择的四种编码⽅式除去⾮Unicode编码的ANSI（对于英⽂系统即ASCII编码，中⽂系统则为GB2312或Big5编码）外，其余三种为“Unicode”（对应UTF-16 LE）、“Unicode big endian”（对应UTF-16 BE）和“UTF-8”。
代码点、码位
在字符编码术语中，码位或称编码位置，即英⽂的code point或code position，是组成码空间（或代码页）的数值。例
如，ASCII码包含128个码位，范围是016进制到7F16进制，扩展ASCII码包含256个码位，范围是016进制到FF16进制，⽽Unicode包含1,114,112个码位，范围是016进制到10FFFF16进制。Unicode码空间划分为17个Unicode字符平⾯（基本多⽂种平⾯，16个辅助平⾯），每个平⾯有65,536（= 216）个码位。因此Unicode码空间总计是17 × 65,536 = 1,114,112.
代码单元、码元
码元（Code Unit，也称“代码单元”）是指⼀个已编码的⽂本中具有最短的⽐特组合的单元。对于UTF-8来说，码元是8⽐特长；对于UTF-16来说，码元是16⽐特长；对于UTF-32来说，码元是32⽐特长。码值（Code Value）是过时的⽤法。
明⽩了上述两个概念，我们就可以认为UTF-N（N为8,16,32）⼲的事就是把Unicode字符集的抽象码位映射为N位长的整数（即码元）的序列，⽤于数据存储或传递。
UTF-32 即将每⼀个 Unicode 代码点表⽰为相同值的 32 位整数。很明显，它是内部处理最⽅便的表达⽅式，但是，如果作为⼀般字符串表达⽅式，则要消耗更多的内存。
UTF-16 使⽤⼀个或两个未分配的 16 位代码单元的序列对 Unicode 代码点进⾏编码。值 U+0000 ⾄ U+FFFF 编码为⼀个相同值的 16 位单元。增补字符编码为两个代码单元，第⼀个单元来⾃于⾼代理范围（U+D800 ⾄ U+DBFF），第⼆个单元来⾃于低代理范围（U+DC00 ⾄ U+DFFF）。这在概念上可能看起来类似于多字节编码，但是其中有⼀个重要区别：值 U+D800 ⾄U+DFFF 保留⽤于 UTF-16；没有这些值分配字符作为代码点。这意味着，对于⼀个字符串中的每个单独的代码单元，软件可以识别是否该代码单元表⽰某个单单元字符，或者是否该代码单元是某个双单元字符的第⼀个或第⼆单元。这相当于某些传统的多字节字符编码来说是⼀个显著的改进，在传统的多字节字符编码中，字节值 0x41 既可能表⽰字母“A”，也可能是⼀个双字节字符的第⼆个字节。
UTF-8 使⽤⼀⾄四个字节的序列对编码 Unicode 代码点进⾏编码。U+0000 ⾄ U+007F 使⽤⼀个字节编码，U+0080 ⾄
U+07FF 使⽤两个字节，U+0800 ⾄ U+FFFF 使⽤三个字节，⽽ U+10000 ⾄ U+10FFFF 使⽤四个字节。UTF-8 设计原理为：字节值 0x00 ⾄ 0x7F 始终表⽰代码点 U+0000 ⾄ U+007F（Basic Latin 字符⼦集，它对应 ASCII 字符集）。这些字节值永远不会表⽰其他代码点，这⼀特性使 UTF-8 可以很⽅便地在软件中将特殊的含义赋予某些 ASCII 字符。
下表所⽰为⼏个字符不同表达⽅式的⽐较：
Unicode 代码点U+0041U+00DF U+6771U+10400
表⽰字形
UTF-32 代码单元00000041000000DF0000677100010400
UTF-16 代码单元004100DF6771D801DC00
UTF-8 代码单元41C39F E69D B1F0909080
注：上述编码中的数字均是⼗六进制表⽰的。
总结
以上就是本⽂关于浅谈Java中Unicode的编码和实现的全部内容，希望对⼤家有所帮助。感兴趣的朋友可以继续参阅本站：、等，如有不⾜之处，欢迎留⾔指出。感谢朋友们对本站的⽀持！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。