成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Unicode、UTF-8、UTF-16 終于懂了

系統(tǒng) Linux
計算機起源于美國,上個世紀,他們對英語字符與二進制位之間的關系做了統(tǒng)一規(guī)定,并制定了一套字符編碼規(guī)則,這套編碼規(guī)則被稱為ASCII編碼。

[[398954]]

本文轉(zhuǎn)載自微信公眾號「Linux開發(fā)那些事兒」,作者 LinuxThings。轉(zhuǎn)載本文請聯(lián)系Linux開發(fā)那些事兒公眾號。

計算機起源于美國,上個世紀,他們對英語字符與二進制位之間的關系做了統(tǒng)一規(guī)定,并制定了一套字符編碼規(guī)則,這套編碼規(guī)則被稱為ASCII編碼

ASCII 編碼一共定義了128個字符的編碼規(guī)則,用七位二進制表示 ( 0x00 - 0x7F ), 這些字符組成的集合就叫做 ASCII 字符集

隨著計算機的普及,在不同的地區(qū)和國家又出現(xiàn)了很多字符編碼,比如: 大陸的 GB2312、港臺的 BIG5, 日本的 Shift JIS等等

由于字符編碼不同,計算機在不同國家之間的交流變得很困難,經(jīng)常會出現(xiàn)亂碼的問題,比如:對于同一個二進制數(shù)據(jù),不同的編碼會解析出不同的字符

當互聯(lián)網(wǎng)迅猛發(fā)展,地域限制打破之后,人們迫切的希望有一種統(tǒng)一的規(guī)則, 對所有國家和地區(qū)的字符進行編碼,于是 Unicode 就出現(xiàn)了

Unicode 簡介

Unicode 是國際標準字符集,它將世界各種語言的每個字符定義一個唯一的編碼,以滿足跨語言、跨平臺的文本信息轉(zhuǎn)換

Unicode 字符集的編碼范圍是 0x0000 - 0x10FFFF , 可以容納一百多萬個字符, 每個字符都有一個獨一無二的編碼,也即每個字符都有一個二進制數(shù)值和它對應,這里的二進制數(shù)值也叫 碼點 , 比如:漢字 "中" 的 碼點是 0x4E2D, 大寫字母 A 的碼點是 0x41, 具體字符對應的 Unicode 編碼可以查詢 Unicode字符編碼表

字符集和字符編碼

字符集是很多個字符的集合,例如 GB2312 是簡體中文的字符集,它收錄了六千多個常用的簡體漢字及一些符號,數(shù)字,拼音等字符

字符編碼是 字符集的一種實現(xiàn)方式,把字符集中的字符映射為特定的字節(jié)或字節(jié)序列,它是一種規(guī)則

比如:Unicode 只是字符集,UTF-8、UTF-16、UTF-32 才是真正的字符編碼規(guī)則

Unicode 字符存儲

Unicode 是一個符號集, 它只規(guī)定了每個符號的二進制值,但是符號具體如何存儲它并沒有規(guī)定

前面提到, Unicode 字符集的編碼范圍是 0x0000 - 0x10FFFF,因此需要 1 到 3 個字節(jié)來表示

那么,對于三個字節(jié)的 Unicode字符,計算機怎么知道它表示的是一個字符而不是三個字符呢 ?

如果所有字符都用三個字節(jié)表示,那么對于那些一個字節(jié)就能表示的字符來說,有兩個字節(jié)是無意義的,對于存儲來說,這是極大的浪費,假如 , 一個普通的文本, 大部分字符都只需一個字節(jié)就能表示,現(xiàn)在如果需要三個字節(jié)才能表示,文本的大小會大出三倍左右

因此,Unicode 出現(xiàn)了多種存儲方式,常見的有 UTF-8、UTF-16、UTF-32,它們分別用不同的二進制格式來表示 Unicode 字符

UTF-8、UTF-16、UTF-32 中的 "UTF" 是 "Unicode Transformation Format" 的縮寫,意思是"Unicode 轉(zhuǎn)換格式",后面的數(shù) 字表明至少使用多少個比特位來存儲字符, 比如:UTF-8 最少需要8個比特位也就是一個字節(jié)來存儲,對應的, UTF-16 和 UTF-32 分別需要最少 2 個字節(jié) 和 4 個字節(jié)來存儲

UTF-8 編碼

UTF-8: 是一種變長字符編碼,被定義為將碼點編碼為 1 至 4 個字節(jié),具體取決于碼點數(shù)值中有效二進制位的數(shù)量

UTF-8 的編碼規(guī)則:

對于單字節(jié)的符號,字節(jié)的第一位設為 0,后面 7 位為這個符號的 Unicode 碼。因此對于英語字母,UTF-8 編碼和 ASCII 碼是相同的, 所以 UTF-8 能兼容 ASCII 編碼,這也是互聯(lián)網(wǎng)普遍采用 UTF-8 的原因之一

對于 n 字節(jié)的符號( n > 1),第一個字節(jié)的前 n 位都設為 1,第 n + 1 位設為 0,后面字節(jié)的前兩位一律設為 10 。剩下的沒有提及的二進制位,全部為這個符號的 Unicode 碼

下表是Unicode編碼對應UTF-8需要的字節(jié)數(shù)量以及編碼格式

Unicode編碼范圍(16進制) UTF-8編碼方式(二進制)
000000 - 00007F 0xxxxxxx ASCII碼
000080 - 0007FF 110xxxxx 10xxxxxx
000800 - 00FFFF 1110xxxx 10xxxxxx 10xxxxxx
01 0000 - 10 FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

表格中第一列是Unicode編碼的范圍,第二列是對應UTF-8編碼方式,其中紅色的二進制 "1" 和 "0" 是固定的前綴, 字母 x 表示可用編碼的二進制位

根據(jù)上面表格,要解析 UTF-8 編碼就很簡單了,如果一個字節(jié)第一位是 0 ,則這個字節(jié)就是一個單獨的字符,如果第一位是 1 ,則連續(xù)有多少個 1 ,就表示當前字符占用多少個字節(jié)

下面以 "中" 字 為例來說明 UTF-8 的編碼,具體的步驟如下圖, 為了便于說明,圖中左邊加了 1,2,3,4 的步驟編號

首先查詢 "中" 字的 Unicode 碼 0x4E2D, 轉(zhuǎn)成二進制, 總共有 16 個二進制位, 具體如上圖 步驟1 所示

通過前面的 Unicode 編碼和 UTF-8 編碼的表格知道,Unicode 碼 0x4E2D 對應 000800 - 00FFFF 的范圍,所以, "中" 字的 UTF-8 編碼 需要 3 個字節(jié),即格式是 1110xxxx 10xxxxxx 10xxxxxx

然后從 "中" 字的最后一個二進制位開始,按照從后向前的順序依次填入格式中的 x 字符,多出的二進制補為 0, 具體如上圖 步驟2、步驟3 所示

于是,就得到了 "中" 的 UTF-8 編碼是 11100100 10111000 10101101, 轉(zhuǎn)換成十六進制就是 0xE4B8AD, 具體如上圖 步驟4 所示

UTF-16 編碼

UTF-16 也是一種變長字符編碼, 這種編碼方式比較特殊, 它將字符編碼成 2 字節(jié) 或者 4 字節(jié)

具體的編碼規(guī)則如下:

  • 對于 Unicode 碼小于 0x10000 的字符, 使用 2 個字節(jié)存儲,并且是直接存儲 Unicode 碼,不用進行編碼轉(zhuǎn)換
  • 對于 Unicode 碼在 0x10000 和 0x10FFFF 之間的字符,使用 4 個字節(jié)存儲,這 4 個字節(jié)分成前后兩部分,每個部分各兩個字節(jié),其中,前面兩個字節(jié)的前 6 位二進制固定為 110110,后面兩個字節(jié)的前 6 位二進制固定為 110111, 前后部分各剩余 10 位二進制表示符號的 Unicode 碼 減去 0x10000 的結果
  • 大于 0x10FFFF 的 Unicode 碼無法用 UTF-16 編碼

下表是Unicode編碼對應UTF-16編碼格式

Unicode編碼范圍(16進制) 具體Unicode碼(二進制) UTF-16編碼方式(二進制) 字節(jié)
0000 0000 - 0000 FFFF xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 2
0001 0000 - 0010 FFFF yy yyyyyyyy xx xxxxxxxx 110110yy yyyyyyyy 110111xx xxxxxxxx 4

表格中第一列是Unicode編碼的范圍,第二列是 具體Unicode碼的二進制 ( 第二行的第二列表示的是 Unicode 碼 減去 0x10000 后的二進制 ) , 第三列是對應UTF-16編碼方式,其中紅色的二進制 "1" 和 "0" 是固定的前綴, 字母 x 和 y 表示可用編碼的二進制位, 第四列表示 編碼占用的字節(jié)數(shù)

前面提到過,"中" 字的 Unicode 碼是 4E2D, 它小于 0x10000,根據(jù)表格可知,它的 UTF-16 編碼占兩個字節(jié),并且和 Unicode 碼相同,所以 "中" 字的 UTF-16 編碼為 4E2D

我從 Unicode字符表網(wǎng)站 找了一個老的南阿拉伯字母, 它的 Unicode 碼是: 0x10A6F , 可以訪問 https://unicode-table.com/cn/10A6F/ 查看字符的說明, Unicode 碼對應的字符如下圖所示

下面以這個 老的南阿拉伯字母的 Unicode 碼 0x10A6F 為例來說明 UTF-16 4 字節(jié)的編碼,具體步驟如下,為了便于說明,圖中左邊加了 1,2,3,4 、5的步驟編號

首先把 Unicode 碼 0x10A6F 轉(zhuǎn)成二進制, 對應上圖的 步驟 1

然后把 Unicode 碼 0x10A6F 減去 0x10000, 結果為 0xA6F 并把這個值轉(zhuǎn)成二進制 00 00000010 10 01101111,對應上圖的 步驟 2

然后 從二進制 00 00000010 10 01101111 的最后一個二進制為開始,按照從后向前的順序依次填入格式中的 x 和 y 字符,多出的二進制補為 0, 對應上圖的 步驟 3、 步驟 4

于是,就計算出了 Unicode 碼 0x10A6F 的 UTF-16 編碼是 11011000 00000010 11011110 01101111 , 轉(zhuǎn)換成十六進制就是 0xD802DE6F, 對應上圖的 步驟 5

UTF-32 編碼

UTF-32 是固定長度的編碼,始終占用 4 個字節(jié),足以容納所有的 Unicode 字符,所以直接存儲 Unicode 碼即可,不需要任何編碼轉(zhuǎn)換。雖然浪費了空間,但提高了效率。

UTF-8、UTF-16、UTF-32 之間如何轉(zhuǎn)換

前面介紹過,UTF-8、UTF-16、UTF-32 是 Unicode 碼表示成不同的二進制格式的編碼規(guī)則,同樣,通過這三種編碼的二進制表示,也能獲得對應的 Unicode 碼,有了字符的 Unicode 碼,按照上面介紹的 UTF-8、UTF-16、UTF-32 的編碼方法 就能轉(zhuǎn)換成任一種編碼了

UTF 字節(jié)序

最小編碼單元是多字節(jié)才會有字節(jié)序的問題存在,UTF-8 最小編碼單元是一字節(jié),所以 它是沒有字節(jié)序的問題,UTF-16 最小編碼單元是 2 個字節(jié),在解析一個 UTF-16 字符之前,需要知道每個編碼單元的字節(jié)序

比如:前面提到過,"中" 字的 Unicode 碼是 4E2D, "?" 字符的 Unicode 碼是 2D4E, 當我們收到一個 UTF-16 字節(jié)流 4E2D 時,計算機如何識別它表示的是字符 "中" 還是 字符 "?" 呢 ?

所以,對于多字節(jié)的編碼單元,需要有一個標記顯式的告訴計算機,按照什么樣的順序解析字符,也就是字節(jié)序,字節(jié)序分為 大端字節(jié)序 和 小端字節(jié)序

小端字節(jié)序簡寫為 LE( Little-Endian ), 表示 低位字節(jié)在前,高位字節(jié)在后, 高位字節(jié)保存在內(nèi)存的高地址端,而低位字節(jié)保存在內(nèi)存的低地址端

大端字節(jié)序簡寫為 BE( Big-Endian ), 表示 高位字節(jié)在前,低位字節(jié)在后,高位字節(jié)保存在內(nèi)存的低地址端,低位字節(jié)保存在在內(nèi)存的高地址端

下面以 0x4E2D 為例來說明大端和小端,具體參見下圖:

數(shù)據(jù)是從高位字節(jié)到低位字節(jié)顯示的,這也更符合人們閱讀數(shù)據(jù)的習慣,而內(nèi)存地址是從低地址向高地址增加

所以,字符0x4E2D 數(shù)據(jù)的高位字節(jié)是 4E,低位字節(jié)是 2D

按照大端字節(jié)序的高位字節(jié)保存內(nèi)存低地址端的規(guī)則,4E 保存到低內(nèi)存地址 0x10001 上,2D 則保存到高內(nèi)存地址 0x10002 上

對于小端字節(jié)序,則正好相反,數(shù)據(jù)的高位字節(jié)保存到內(nèi)存的高地址端,低位字節(jié)保存到內(nèi)存低地址端的,所以 4E 保存到高內(nèi)存地址 0x10002 上,2D 則保存到低內(nèi)存地址 0x10001 上

BOM

BOM 是 byte-order mark 的縮寫,是 "字節(jié)序標記" 的意思, 它常被用來當做標識文件是以 UTF-8、UTF-16 或 UTF-32 編碼的標記

在 Unicode 編碼中有一個叫做 "零寬度非換行空格" 的字符 ( ZERO WIDTH NO-BREAK SPACE ), 用字符 FEFF 來表示

對于 UTF-16 ,如果接收到以 FEFF 開頭的字節(jié)流, 就表明是大端字節(jié)序,如果接收到 FFFE, 就表明字節(jié)流 是小端字節(jié)序

UTF-8 沒有字節(jié)序問題,上述字符只是用來標識它是 UTF-8 文件,而不是用來說明字節(jié)順序的。"零寬度非換行空格" 字符 的 UTF-8 編碼是 EF BB BF, 所以如果接收到以 EF BB BF 開頭的字節(jié)流,就知道這是UTF-8 文件

下面的表格列出了不同 UTF 格式的固定文件頭

UTF編碼 固定文件頭
UTF-8 EF BB BF
UTF-16LE FF FE
UTF-16BE FE FF
UTF-32LE FF FE 00 00
UTF-32BE 00 00 FE FF

根據(jù)上面的 固定文件頭,下面列出了 "中" 字在文件中的存儲 ( 包含文件頭 )

編碼 固定文件頭
Unicode 編碼 0X004E2D
UTF-8 EF BB BF 4E 2D
UTF-16BE FE FF 4E 2D
UTF-16LE FF FE 2D 4E
UTF-32BE 00 00 FE FF 00 00 4E 2D
UTF-32LE FF FE 00 00 2D 4E 00 00

常見的字符編碼的問題

  • Redis 中文key的顯示

有時候我們需要向redis中寫入含有中文的數(shù)據(jù),然后在查看數(shù)據(jù),但是會看到一些其他的字符,而不是我們寫入的中文

上圖中,我們向redis 寫入了一個 "中" 字,通過 get 命令查看的時候無法顯示我們寫入的 "中" 字

這時候加一個 --raw 參數(shù),重新啟動 redis-cli 即可,也即 執(zhí)行 redis-cli --raw 命令啟動redis客戶端,具體的如下圖所示

  • MySQL 中的 utf8 和 utf8mb4

MySQL 中的 "utf8" 實際上不是真正的 UTF-8, "utf8" 只支持每個字符最多 3 個字節(jié), 對于超過 3 個字節(jié)的字符就會出錯, 而真正的 UTF-8 至少要支持 4 個字節(jié)

MySQL 中的 "utf8mb4" 才是真正的 UTF-8

下面以 test 表為例來說明, 表結構如下:

  1. mysql> show create table test\G 
  2. *************************** 1. row *************************** 
  3.        Table: test 
  4. Create TableCREATE TABLE `test` ( 
  5.   `namechar(32) NOT NULL 
  6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 
  7. 1 row in set (0.00 sec) 

向 test 表分別插入 "中" 字 和 Unicode 碼為 0x10A6F 的字符,這個字符需要從 https://unicode-table.com/cn/10A6F/ 直接復制到 MySQL 控制臺上,手工輸入會無效,具體的執(zhí)行結果如下圖:

從上圖可以看出,插入 "中" 字 成功,插入 0x10A6F 字符失敗,錯誤提示無效的字符串,\xF0\X90\XA9\xAF 正是 0x10A6F 字符的 UTF-8 編碼,占用 4 個字節(jié), 因為 MySQL 的 utf8 編碼最多只支持 3 個字節(jié),所以插入會失敗

把 test 表的字符集改成 utf8mb4 , 排序規(guī)則 改成 utf8bm4_unicode_ci, 具體如下圖所示:

字符集和排序方式修改之后,再次插入 0x10A6F 字符, 結果是成功的,具體執(zhí)行結果如下圖所示

上圖中,set names utf8mb4 是為了測試方便,臨時修改當前會話的字符集,以便保持和 服務器一致,實際解決這個問題需要修改 my.cnf 配置中 服務器和客戶端的字符集

小結

本文從字符編碼的歷史介紹了 Unicode 出現(xiàn)的原因,接著介紹了 Unicode 字符集中 三種不同的編碼方式:UTF-8、UTF-16、UTF-32 以及它們的的編碼方法,緊接著介紹了 字節(jié)序、BOM ,最后講到了字符集在 MySQL 和 Redis 應用中常見的問題以及解決方案 ,更多關于 Unicode 的介紹請參考 Unicode 的 RFC 文檔

 

責任編輯:武曉燕 來源: Linux開發(fā)那些事兒
相關推薦

2023-01-26 00:31:25

ASCIIBase64UTF-8

2024-05-29 13:05:44

2020-09-21 08:56:00

GolangUnicode編碼

2023-12-08 08:18:41

代號UnicodeUTF-8

2011-08-25 09:43:51

UTF-8中文man

2016-12-13 10:13:18

PHPUTF-8實踐

2011-03-07 12:31:54

Filezilla

2010-09-29 11:29:18

UnicodeJ2ME

2024-01-04 12:53:00

Unicode字符UTF-8

2016-09-23 13:07:41

JavaScript字符編碼UCS-2

2019-04-15 14:05:56

MySQLUTF-8數(shù)據(jù)庫

2020-09-22 09:05:45

MySQLUTF-8utf8mb4

2009-12-17 11:45:38

Linux UTF-8

2016-11-15 14:29:14

Linux文件編碼轉(zhuǎn)換

2010-01-08 11:52:37

ibmdwDB2

2011-07-29 14:08:26

iPhone UTF-8 XML

2024-02-20 13:12:00

UnicodeUTF-8GB2312

2009-12-16 09:45:13

UbuntuUbuntu ServUTF-8

2009-10-29 12:27:54

2018-06-25 14:29:45

MySQLbug數(shù)據(jù)庫
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 男女在线免费观看 | 精品国产青草久久久久福利 | 国产国产精品久久久久 | 久久高清精品 | 久久夜色精品国产 | 另类二区 | 精品欧美一区二区在线观看欧美熟 | 国产精品美女久久久 | 中文字幕91 | 国产精品国产a级 | 青青久久 | 成人免费在线观看 | 国产精品成人在线 | 福利视频一区 | 91综合网| 999免费视频 | 久久精品国产99国产 | 日本在线一二 | 久久精品国产99国产精品 | 超碰97免费 | 成人福利在线视频 | 蜜月va乱码一区二区三区 | av一区二区三区 | 欧美一区 | 99精品一区二区三区 | 亚洲高清一区二区三区 | 成人深夜福利在线观看 | www.青青草| www国产精品 | 一级片在线视频 | 国产欧美日韩一区二区三区在线观看 | 欧美综合在线观看 | 人人叉 | 中文字幕在线视频免费观看 | 国产精品亚洲一区二区三区在线 | 91xh98hx 在线 国产 | 亚洲视频二区 | 日本在线一区二区三区 | 黄网站涩免费蜜桃网站 | 色偷偷噜噜噜亚洲男人 | 中文字幕在线观看一区二区 |