前端開發中需要搞懂的字元編碼知識

jimojianghu發表於2022-04-29

字符集和字元編碼

字符集就是字元的集合,如常見的 ASCII字符集,GB2312字符集,Unicode字符集等。這些不同字符集之間最大的區別是所包含的字元數量的不同。

字元編碼則代表字符集的實際編碼規則,是用於計算機解析字元的,如 GB2312,GBK,UTF-8 等。字元編碼的本質就是如何使用二進位制位元組來表示字元的問題。

字符集和編碼是一對多的關係,同一字符集可能有多種字元編碼,如Unicode字符集就有 UTF-8,UTF-16 等。

在前端開發中,Javascript程式是使用Unicode字符集,Javascript原始碼文字通常是基於UTF-8編碼。
但js程式碼中的字串型別是UTF-16編碼的,這也是為什麼會碰到api介面返回字串在前端出現亂碼,因為多數服務都使用utf-8編碼,前後編碼方式不一致。

說起字符集的發展歷程,可以總結為一句話:幾乎都是對ASCII字符集的擴充套件。

ASCII

我們知道,計算機是使用二進位制來處理資訊的。
其中,每一個二進位制位(bit)有 0和1 兩種狀態。一個位元組(byte)則有8個二進位制位,可以有256種狀態。

而ASCII就是基於拉丁字母、主要用於顯示英文的一種單位元組字符集,它的編碼和字元是一一對應的,因為它就是使用一個位元組8個二進位制位來表示,不會超過256個字元。

標準的ASCII字元總計有128個字元(2^7),其中前面32個控制字元,後面96個是可列印字元,包括常用的大小寫字母數字標點符號等。因為只佔用了一個位元組的後7位,那位元組的最高位一般設定為0。

'a'.charCodeAt() // 97
'A'.charCodeAt() // 65
'9'.charCodeAt() // 57
'.'.charCodeAt() // 46

如上,每個字元會對應一個編碼(使用數字標識),總共會從0-128。完整的ASCII碼錶,網上很容易找到。

通過ASCII碼錶,我們發現,小寫字母並沒有和大寫字母挨著排序?這是為了方便大小寫之間的轉換, A 排在 65(64 + 1) 位,而 a 排在 97(64 + 32 + 1) 位。

65 ^ 32 = 97
// A ^ 32 = a

字符集的發展歷史

ASCII是幾乎所有字符集的基礎。

標準的ASCII碼最多隻能標識128個字元,歐美國家可以很好的使用,但其他國家的字元變多,自然就不夠用了。
這個時候,最高位就開始被惦記上,通過擴充套件ASCII碼的最高位,又能滿足用於特殊符號的一些國家的需求,這種就是擴充套件ASCII碼。

但是亞非拉更多非拉丁語系的國家,字元成千上萬,只能使用新的方式。
如中文,就又進行了擴充套件,小於127的字元的意義與標準ASCII碼相同,當需要標識漢字時,使用2個位元組,每個位元組都大於127。這種多位元組字符集即GB2312,後續因為不斷的擴充套件,如繁體字和各種符號,甚至少數民族的語言符號等等,又使用了包括GBK等不同字符集。
因此,很多國家都制定了自己的編碼字符集,基本都是在ASCII的基礎上進行的。

各字符集雖然都能夠相容標準ASCII碼,但在使用交流上的不便是顯而易見的,亂碼也是隨處可見。為了解決這種各自為戰的問題,Unicode字符集就誕生了。

Unicode

Unicode是國際組織制定的,用於收納世界上所有文字和符號的字符集方案。
前128個字元同ASCII一樣,進行擴充後,使用數字0-0x10FFFF來對映這些字元,最多可以有1114112個字元。目前仍然只使用了其中的一小部分。
Unicode一般使用兩個位元組來表示一個字元。

  • 碼點
    Unicode 規定了每個字元的數字編號,這個編號被稱為 碼點(code point)。
    碼點以 U+hex 的形式表示,U+是代表Unicode的字首,而 hex 是一個16進位制數。取值範圍是從 U+0000 到 U+10FFFF。

每個碼點對應一個字元,絕大部分的常見字元在最前面的 65536 個字元,範圍是 U+0000到U+FFFF。
一般漢字的碼點區間為 U+2E80 - U+9FFF。

  • 字元平面
    目前的Unicode分成了17個編組,也稱平面,每個平面有65536個碼點。
    第一個平面是基本多語言平面,範圍:U+0000 - U+FFFF,多數常見字元都在該區間。
    其他平面則為輔助平面,範圍:U+10000 到 U+10FFFF,如我們在網上常見 Emoji 表情。

  • 碼元
    碼元(Code Unit)可以理解為對碼點進行編碼時的最小基本單元,碼元是一個整體。而字元編碼的作用就是將Unicode碼點轉換成碼元序列。
    Unicode常用的編碼方式有 UTF-8 、UTF-16 和 UTF-32,UTF是Unicode TransferFormat的縮寫。
    UTF-8是8位的單位元組碼元,UTF-16是16位的雙位元組碼元,UTF-32是32位的四位元組碼元。

編碼方式 碼元 編碼後位元組數
UTF-8 8位 1-4位元組
UTF-16 16位 2位元組或者4位元組
UTF-32 32位 4位元組

另外,為什麼總看到使用十六進位制資料來表示如碼點等各種資料呢?
因為,兩位的十六進位制正好等於一個位元組8位,0xff = 0b11111111。

UTF-8

UTF-8是一種可變長度的字元編碼方式。目前是使用 1 到 4 個位元組來編碼字元。
是網際網路時代應用最廣的一種編碼方式,前端接觸的相對最多。

需要注意的是:漢字一般佔3個位元組,表情符號一般佔4個位元組。

UTF-8的編碼規則:

  • 1個位元組的字元,第一位為0,後7位為碼點,與ASCII相同。
  • n個位元組的字元,第一個位元組前面 n 位都是1,n+1位是0,可據此判斷有幾個位元組。後面的幾個位元組都是 10 為開頭2位。
    這裡規定的都是字首,對於字元的碼點,需要進行擷取後依次放入除字首外的其他位,所以UTF-8又被稱為字首碼。
    格式如表:
位元組數 碼點位數 碼點範圍 編碼方式
1 7 U+0000~U+007F 0×××××××
2 11 U+0080~U+07FF 110××××× 10××××××
3 16 U+0800~U+FFFF 1110×××× 10×××××× 10××××××
4 21 U+10000~U+10FFFF 11110××× 10×××××× 10×××××× 10××××××

通過上表的編碼規則,我們就可以進行各種轉換了。
下面我們以一箇中文字元的編碼轉換為例,如漢字 '好':

'好'的Unicode碼點:'好'.codePointAt() \\ 22909,結果是22909;
22909在UTF-8的3位元組數的編碼區間 U+0800 (2048) ~ U+FFFF (65535);
22909的二進位制值:101100101111101,有15位;
而3位元組數的編碼需要16位,前面補0,根據表中規則分成3組:0101 100101 111101;
依次填入對應的字首:11100101 10100101 10111101,得到3個位元組;
將得到的三個位元組轉成十六進位制資料:E5 A5 BD,所以漢字 '好' 的UTF-8就是:E5 A5 BD。

我們使用 encodeURI 進行驗證————encodeURI函式支援將中文進行 UTF-8 編碼:

encodeURI('好') // '%E5%A5%BD'

去除百分號,結果正好一致。

UTF-16

UTF-16的編碼方式:基本平面的字元佔用 2 個位元組(U+0000到U+FFFF),輔助平面的字元佔用 4 個位元組(U+010000到U+10FFFF)。
也就是說,UTF-16的編碼長度要麼是2個位元組要麼是4個位元組。當為2位元組時,則實際上與Unicode相同。

並且還有個原則,在Unicode基本多語言平面內,從U+D800到U+DFFF之間的碼點區間是不對應字元的。而UTF-16需要利用這塊碼位來對輔助平面的字元進行編碼。
它的具體規則:

  • 碼點小於U+FFFF,基本字元,不需處理,直接使用,佔兩個位元組。
  • 否則,拆分成兩個碼元,四個位元組,cp表示碼點:
    1. 低位——((cp - 65536) / 1024) + 0xD800,值範圍是 0xD800~0xDBFF;
    2. 高位——((cp - 65536) % 1024) + 0xDC00,值範圍是 0xDC00~0xDFFF。

看下面的示例:

  1. 漢字 '好','好'.codePointAt() // 22909,碼點小於U+FFFF,直接進行十六進位制轉換:579D。
  2. 表情符號 '?','?'.codePointAt() // 128516,碼點需要拆分:
    • 低位:Math.floor(((128516 - 65536) / 1024)) + 0xD800 // 55357, 得到 D83D
    • 高位:((128516 - 65536) % 1024) + 0xDC00 // 56836,得到 DE04

使用 String.fromCharCode 方法進行驗證:

String.fromCharCode(0xD83D, 0xDE04)  // '?'

需要明確的一點,Javascript中的字串是基於UTF-16編碼的,大端序位元組。

UTF-32是定長的編碼,每個碼位使用四個位元組進行編碼。優點是和unicode一一對應,缺點是太浪費空間。

比較

下面將選取字母、漢字、表情字元,進行編碼對比檢視:

// UTF-8
'a': 97 - 0x61
'好': 22909 - (0xE5 0xA5 0xBD)
'?': 128516 - (0xF0 0x9F 0x98 0x84)

// UTF-16
'a': 97 - 0x0061
'好': 22909 - 0x597d
'?': 128516 - (0xD83D, 0xDE04)

可以看到,UTF-8是變長1-4個位元組,碼元為8位;UTF-16是2或4位元組,碼元是16位。
這裡記住UTF-16的碼元,對於我們理解下面的問題,比較有幫助。

前端開發中的編碼

前面已提到過,javascript中的字串是基於UTF-16編碼的,所以在計算字串長度時,我們需要先理解UTF-16編碼。
下面看下處理字串時可能會遇到的問題。

字串長度計算

字串的length屬性,實際上是使用UTF-16的碼元個數來進行計算的:

  • ASCII碼和大部分中文,都是一個碼元
  • 而表情字元和其他特殊字元都是兩個碼元

所以當某個字元中存在2個碼元時,就算顯示的是一個字元,length卻等於2。

'a'.length // 1
'好'.length // 1,多數漢字都是基本字元平面,只有一個碼元,長度就為1。
'?'.length // 2

組合字元的長度

還有一種特殊的,組合字元,一般指一些帶標點符號的字元:é。

'é'.length // 2
'e\u0301'.length // 2

// 獲取碼點時,忽略了標點符號,顯示的是字母的碼點
'é'.codePointAt() // 101
'e'.codePointAt() // 101

如要正常操作組合字元,使用normalize()。

'é'.normalize().length = 1。

多碼元字元操作

對於多碼元字元使用下標取值時,得到的將是它的碼元:

'?'[0] // '\uD83D'
'?'[1] // '\uDE04'
'123'[0] // '1'

迴圈時,使用 for 會亂碼,而 for-of 則正常:

let smile = '?'
for(let i = 0; i < smile.length; i++) { 
  console.log(smile[i]) 
}
// �
// �

for (let tt of smile) {
  console.log(tt)
}
// ?

但,可以使用轉換成擴充套件陣列的方式訪問:

[...'?'][0] // '?'
Array.from('?') // ['?']

還可以使用碼點的方式:

String.fromCodePoint('?'.codePointAt()) // '?'

對於這種特殊字元,使用下面的字串方法都會分割碼元:
split(),slice(),charAt(),charCodeAt(),substr(),substring()。

'?'.slice(0, 2) // '?'
'?'.slice(0, 1) // '\uD83D'
'?'.slice(1, 2) // '\uDE04'
'?'.substr(0,1) // '\uD83D'
'?'.substr(0,2) // '?'

'?'.split('') // ['\uD83D', '\uDE04']

正則中的 u 修飾符

ES6在正則中新增了u修飾符,用來正確處理大於\uFFFF的 Unicode 字元。
也就是能夠正確處理四個位元組的 UTF-16 編碼。

/^\S$/.test('?') // false
/^\S$/u.test('?') // true

但對組合字元,u修飾符不起作用:

/^\S$/u.test('é') // false
/^\S$/u.test('e\u0301') // false

轉義字元

我們還需要注意的,是轉義字元的計算,結果會以實際字元為準:

'\x3f'.length // 1
'?'.length // 1

讀取操作時,也能正常處理:

'\x3f'[0] // '?'
'\x3f'.split('') // ['?']

常用API

前端在對Unicode編碼處理時,提供了一些可以使用的API,在實際工作中,會方便我們處理這方面的問題。

處理碼點和字元

  • charAt(index)
    從一個字串中返回指定的字元,對於多碼元字元,仍會返回碼元字元:
'a'.charAt() // 'a'
'?'.charAt() // '\uD83D'
'?'.charAt(1) // '\uDE04'
  • charCodeAt(index)
    返回0到65535之間的整數碼點值。對於多碼元如果字元的碼點大於U+FFFF,則返回第一個碼元值,還可以加索引引數取後面碼元的值。
  • codePointAt(pos)
    返回Unicode碼點,多碼元也能返回完整的碼點值。codePointAt可以傳入索引引數,對多碼元字元取第二個碼元值。
// 小於 U+FFFF
'好'.codePointAt() // 22909
'好'.charCodeAt() // 22909

// 大於 U+FFFF
'?'.charCodeAt() // 55357
'?'.charCodeAt(1) // 56836
'?'.codePointAt() // 128516
'?'.codePointAt(1) // 56836
  • String.fromCharCode(num1[, ...[, numN]])
    返回由指定的UTF-16碼點序列建立的字串。引數範圍0到65535,大於65535的資料將被截斷,結果不準確。
    對於多碼元字元,則會將兩個碼元組合得到該字元。
  • String.fromCodePoint(num1[, ...[, numN]])
    返回使用指定的程式碼點序列建立的字串。可以處理多碼元字元的完整碼點值。
String.fromCharCode(55357, 56836, 123) // '?{'
String.fromCodePoint(128516, 123, 8776) // '?{≈'

TextEncoder

TextEncoder,使用 UTF-8 編碼將程式碼點流轉換成位元組流。
TextDecoder:解碼。
預設編碼方式就是UTF-8,可以解決字元轉UTF-8編碼的問題。

const txtEn = new TextEncoder()
const enVal = txtEn.encode('好')
// Uint8Array(3) [229, 165, 189]
const txtDe = new TextDecoder()
txtDe.decode(enVal) // '好'

IE不支援。

String.prototype.normalize()

對於語調符號和重音符號,Unicode提供了兩種方法,一種是直接提供帶符號的字元,如 é (碼點233);另一種是組合字元,如上文提到的 (碼點101)。
針對這種碼點不同,但實質一樣的字元,Javascript識別不了:

'é' === 'é' // false

而 normalize() 方法的引入,正是為了解決這一問題,它會按照一定的方式將字元的不同表示方法統一為標準形式:

'é' === 'é'.normalize() // true

URL的UTF8編解碼

另外,在前端常接觸的網頁中,URL連結編碼也是非常常見的。諸如:'http%3A%2F%2Fbaidu.com%2F%E4%B8%AD%E5%9B%BD'。這裡面涉及到的就是關於UTF-8的編碼。
而JavaScript提供了四個URL的編碼/解碼方法,可以用於將非ASCII碼的字元,如中文字元、特殊字元、表情字元等,進行UTF-8的編解碼操作:

  • encodeURI() 和 encodeURIComponent()
  • decodeURI() 和 decodeURIComponent()

他們的短處也很明顯,對ASCII字元如英文數字等字元無法處理。
這裡的轉換方式:先轉為UTF-8的位元組碼,然後前面加個 % 進行拼接得到編碼結果。

encodeURI('好') // '%E5%A5%BD'
decodeURI('%E5%A5%BD') // '好'
encodeURIComponent('好') // '%E5%A5%BD'
decodeURIComponent('%E5%A5%BD') // '好'
encodeURI('hello') // 'hello'
encodeURIComponent('hello') // 'hello'
encodeURIComponent('?') // '%F0%9F%98%84'
encodeURI和encodeURIComponent的區別

這兩者的不同之處,在於對部分URL元字元符號的處理上。

URL元字元:分號(;),逗號(’,’),斜槓(/),問號(?),冒號(:),at(@),&,等號(=),加號(+),美元符號($),井號(#)。

encodeURIComponent會對這些URL元字元進行編碼,但是encodeURI則不會:

encodeURIComponent(';,/@&=') // '%3B%2C%2F%40%26%3D'
encodeURI(';,/@&=') // ';,/@&='

相關文章