Unicode, UTF-8/16/32, Introduction

最新推荐文章于 2024-07-17 09:42:12 发布

mci2004

最新推荐文章于 2024-07-17 09:42:12 发布

阅读量1.3k

点赞数

分类专栏： Unicode/UTF-*/Codepage 文章标签： Unicode UTF-16 UTF-8 UTF-32 Codepage

本文链接：https://blog.csdn.net/mci2004/article/details/9290483

版权

Unicode/UTF-*/Codepage 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

What is Unicode

1. 統一碼/標準萬國碼

2. Unicode給每個字元提供了一個唯一的數位，
不論是什麼平臺、
不論是什麼程式、
不論是什麼語言。

What is UTF-8, UTF-16, UTF-32

回答这个问题之前先得弄明白，什么是UTF？

UTF： Unicode transformation format

UTF是一种“算法”，该“算法”将Unicode中每一个码点转元成唯一的唯一的字节序列。

其中 UTF-8/16/32是UTF的具体实现.

下面来介绍什么是UTF-8：

UTF-8 ( UCS Transformation Format—8-bit [1] )：

is a variable-width encoding that can represent every character in the Unicode character set. It was designed for backward compatibility with ASCII and to avoid the complications of endianness and byte order marks in UTF-16 and UTF-32.

1，UTF-8是变长的编码方式，其code unit为8bit即一个字节长度。
cyrillic
2，UTF-8可以很好的向后兼容ASCII

3，UTF-8由于其编码单元（code unit）长度为8bit（1 byte）所以和UTF-16/32相比，UTF-8可以完全不考虑大小端的问题

因为，内存的最小访问单元为8bit（1byte）。

Example:

Let us consider how to encode the Euro sign, €.

1. The Unicode code point for "€" is U+20AC.
2. According to the scheme table above, this will take three bytes to encode, since it is between U+0800 and U+FFFF.
3. Hexadecimal 20AC is binary 0010000010101100. The two leading zeros are added because, as the scheme table shows, a three-byte encoding needs exactly sixteen bits from the code point.
4. Because it is a three-byte encoding, the leading byte starts with three 1s, then a 0 (1110...)
5. The remaining bits of this byte are taken from the code point (11100010), leaving ...000010101100.
6. Each of the continuation bytes starts with 10 and takes six bits of the code point (so 10000010, then 10101100).
The three bytes 11100010 10000010 10101100 can be more concisely written in hexadecimal, as E2 82 AC.
The following table summarises this conversion, as well as others with different lengths in UTF-8. The colors indicate how bits from the code point are distributed among the UTF-8 bytes. Additional bits added by the UTF-8 encoding process are shown in black.

下面来介绍什么是UTF-16：

A: UTF-16 uses a single 16-bit code unit to encode the most common 63K characters, and a pair of 16-bit code units, called surrogates, to encode the 1M less commonly used characters in Unicode.

Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16. [AF]

1，UTF-16的code unit的长度是 16-bit，同样是变长编码方式一个编码单元和两个编码单元之间的变化。（即要么编码长度占2两个字节，要么占4个字节）

2，大部分的字符（码位从U+0000至U+FFFF）都可以使用一个code unit来表示，该平面被称为基本多语言平面BMP，注意在BMP内，基本多语言平面內，從U+D800到U+DFFF之間的码位區段是永久保留不映射到Unicode字符。UTF-16就利用保留下来的0xD800-0xDFFF区段的码位來對輔助平面的字符的码位進行編碼。
所以，UTF-16 BMP内所包含的字符个数为，2^16 - (0xDFFF - 0xD800) = 65536 - 2^11 - 1 = 63K

3，从U+10000到U+10FFFF的码位[编辑]辅助平面(Supplementary Planes)中的码位，在UTF-16中被编码为一对16比特长的码元(即32bit,4Bytes)，称作 代理对(surrogate pair).

4，UTF-16是基于多平面的，要考虑大小端问题（BE/LE），用BOM（Byte order marker）来描述大小端。BOM标示通常出现在一个文件的文件头。

接上面第三项，代理对的具体方法：

• 码位减去0x10000, 得到的值的范围为20比特长的0..0xFFFFF.
• 高位的10比特的值(值的范围为0..0x3FF)被加上0xD800得到第一个码元或称作高位代理(high surrogate), 值的范围是0xD800..0xDBFF. 由于高位代理比低位代理的值要小，所以为了避免混淆使用，Unicode标准现在称高位代理为前导代理(lead surrogates).
• 低位的10比特的值(值的范围也是0..0x3FF)被加上0xDC00得到第二个码元或称作低位代理(low surrogate), 现在值的范围是0xDC00..0xDFFF. 由于低位代理比高位代理的值要大，所以为了避免混淆使用，Unicode标准现在称低位代理为后尾代理(trail surrogates).
上述算法可理解为：辅助平面中的码位从U+10000到U+10FFFF，共计FFFFF个，即220=1,048,576个，需要20位的空间来表示。如果用两个16位长的整数组成的序列来表示，第一个整数（称为前导代理）要容纳上述20位空间的前10位，第二个整数（称为后尾代理）容纳容纳上述20位空间的后10位。还要能根据16位整数的值直接判明属于前导整数代理的值的范围（210=1024)，还是后尾整数代理的值的范围（也是210=1024）。因此，需要在基本多语言平面中保留不对应于Unicode字符的2048个码位，就足以容纳前导代理与后尾代理所需要的编码空间。这对于基本多语言平面总计65536个码位来说，仅占3.125%.
由于前导代理、后尾代理、BMP中的有效字符的码位，三者互不重叠，搜索是简单的: 一个字符编码的一部分不可能与另一个字符编码的不同部分相重叠。这意味着UTF-16是自同步(self-synchronizing): 可以通过仅检查一个码元就可以判定给定字符的下一个字符的起始码元. UTF-8也有类似优点，但许多早期的编码模式就不是这样，必须从头开始分析文本才能确定不同字符的码元的边界.
由于最常有的字符都在基本多文种平面中，许多软件的处理代理对的部分往往得不到充分的测试。这导致了一些长期的bug与潜在安全漏洞，甚至在广为流行得到良好评价的应用软件[1].
从U+D800到U+DFFF的码位[编辑]Unicode标准规定U+D800..U+DFFF的值不对应于任何字符.
但是在使用UCS-2的时代，U+D800..U+DFFF内的值被占用，用于某些字符的映射。但只要不构成代理对，许多UTF-16编码解码还是能把这些不符合Unicode标准的字符映射正确的辨识、转换成合规的码元[2]. 按照Unicode标准，这种码元序列本来应算作编码错误.

下面来介绍什么是UTF-32：

UTF-32 (或 UCS-4)是一種將Unicode字符編碼的協定，對每一個Unicode碼位使用恰好32位元。其它的Unicode transformation formats則使用不定長度編碼。
因為UTF-32對每個字符都使用4位元組，就空間而言，是非常沒有效率的。特別地，非基本多文種平面的字符在大部分文件中通常很罕見，以致於它們通常被認為不存在佔用空間大小的討論，使得UTF-32通常會是其它編碼的二到四倍。
雖然每一個碼位使用固定長度的位元組看似方便，它並不如其它Unicode編碼使用得廣泛。與UTF-8及UTF-16相比，它有點更容易遭截斷。即使使用了"定寬"字型，除非在一些非常有限的清況下，否則它並不會使得計算顯示一個字串的寬度更加容易。主要原因是，存在著一個字符位置會有多於一種可能的碼點（結合字符）或一個碼點用多於一個字符位置（如CJK表意字符）。結合符號也意味著，文書編輯者不能將一個碼點視同一個編輯上的單位。