淺談Unicode與JavaScript的發(fā)展史
一、Unicode是什么?
Unicode源于一個很簡單的想法:將全世界所有的字符包含在一個集合里,計算機只要支持這一個字符集,就能顯示所有的字符,再也不會有亂碼了。
它從0開始,為每個符號指定一個編號,這叫做"碼點"(codepoint)。比如,碼點0的符號就是null(表示所有二進制位都是0)。
上式中,U+表示緊跟在后面的十六進制數(shù)是Unicode的碼點。
目前,Unicode的最新版本是7.0版,一共收入了109449個符號,其中的中日韓文字為74500個??梢越普J為,全世界現(xiàn)有的符號當(dāng)中,三分之二以上來自東亞文字。比如,中文"好"的碼點是十六進制的597D。
這么多符號,Unicode不是一次性定義的,而是分區(qū)定義。每個區(qū)可以存放65536個(216)字符,稱為一個平面(plane)。目前,一共有17個(25)平面,也就是說,整個Unicode字符集的大小現(xiàn)在是221。
最前面的65536個字符位,稱為基本平面(縮寫B(tài)MP),它的碼點范圍是從0一直到216-1,寫成16進制就是從U+0000到U+FFFF。所有最常見的字符都放在這個平面,這是Unicode最先定義和公布的一個平面。
剩下的字符都放在輔助平面(縮寫SMP),碼點范圍從U+010000一直到U+10FFFF。
二、UTF-32與UTF-8
Unicode只規(guī)定了每個字符的碼點,到底用什么樣的字節(jié)序表示這個碼點,就涉及到編碼方法。
最直觀的編碼方法是,每個碼點使用四個字節(jié)表示,字節(jié)內(nèi)容一一對應(yīng)碼點。這種編碼方法就叫做UTF-32。比如,碼點0就用四個字節(jié)的0表示,碼點597D就在前面加兩個字節(jié)的0。
UTF-32的優(yōu)點在于,轉(zhuǎn)換規(guī)則簡單直觀,查找效率高。缺點在于浪費空間,同樣內(nèi)容的英語文本,它會比ASCII編碼大四倍。這個缺點很致命,導(dǎo)致實際上沒有人使用這種編碼方法,HTML5標準就明文規(guī)定,網(wǎng)頁不得編碼成UTF-32。
人們真正需要的是一種節(jié)省空間的編碼方法,這導(dǎo)致了UTF-8的誕生。UTF-8是一種變長的編碼方法,字符長度從1個字節(jié)到4個字節(jié)不等。越是常用的字符,字節(jié)越短,最前面的128個字符,只使用1個字節(jié)表示,與ASCII碼完全相同。
編號范圍字節(jié)0x0000 - 0x007F10x0080 - 0x07FF20x0800 - 0xFFFF30x010000 - 0x10FFFF4
由于UTF-8這種節(jié)省空間的特性,導(dǎo)致它成為互聯(lián)網(wǎng)上最常見的網(wǎng)頁編碼。不過,它跟今天的主題關(guān)系不大,我就不深入了,具體的轉(zhuǎn)碼方法,可以參考我多年前寫的《字符編碼筆記》。
三、UTF-16簡介
UTF-16編碼介于UTF-32與UTF-8之間,同時結(jié)合了定長和變長兩種編碼方法的特點。
它的編碼規(guī)則很簡單:基本平面的字符占用2個字節(jié),輔助平面的字符占用4個字節(jié)。也就是說,UTF-16的編碼長度要么是2個字節(jié)(U+0000到U+FFFF),要么是4個字節(jié)(U+010000到U+10FFFF)。
于是就有一個問題,當(dāng)我們遇到兩個字節(jié),怎么看出它本身是一個字符,還是需要跟其他兩個字節(jié)放在一起解讀?
說來很巧妙,我也不知道是不是故意的設(shè)計,在基本平面內(nèi),從U+D800到U+DFFF是一個空段,即這些碼點不對應(yīng)任何字符。因此,這個空段可以用來映射輔助平面的字符。
具體來說,輔助平面的字符位共有220個,也就是說,對應(yīng)這些字符至少需要20個二進制位。UTF-16將這20位拆成兩半,前10位映射在U+D800到U+DBFF(空間大小210),稱為高位(H),后10位映射在U+DC00到U+DFFF(空間大小210),稱為低位(L)。這意味著,一個輔助平面的字符,被拆成兩個基本平面的字符表示。
所以,當(dāng)我們遇到兩個字節(jié),發(fā)現(xiàn)它的碼點在U+D800到U+DBFF之間,就可以斷定,緊跟在后面的兩個字節(jié)的碼點,應(yīng)該在U+DC00到U+DFFF之間,這四個字節(jié)必須放在一起解讀。
四、UTF-16的轉(zhuǎn)碼公式
Unicode碼點轉(zhuǎn)成UTF-16的時候,首先區(qū)分這是基本平面字符,還是輔助平面字符。如果是前者,直接將碼點轉(zhuǎn)為對應(yīng)的十六進制形式,長度為兩字節(jié)。
如果是輔助平面字符,Unicode 3.0版給出了轉(zhuǎn)碼公式。
以字符為例,它是一個輔助平面字符,碼點為U+1D306,將其轉(zhuǎn)為UTF-16的計算過程如下。
所以,字符的UTF-16編碼就是0xD834 DF06,長度為四個字節(jié)。
五、JavaScript使用哪一種編碼?
JavaScript語言采用Unicode字符集,但是只支持一種編碼方法。
這種編碼既不是UTF-16,也不是UTF-8,更不是UTF-32。上面那些編碼方法,JavaScript都不用。
JavaScript用的是UCS-2!
六、UCS-2編碼
怎么突然殺出一個UCS-2?這就需要講一點歷史。
互聯(lián)網(wǎng)還沒出現(xiàn)的年代,曾經(jīng)有兩個團隊,不約而同想搞統(tǒng)一字符集。一個是1988年成立的Unicode團隊,另一個是1989年成立的UCS團隊。等到他們發(fā)現(xiàn)了對方的存在,很快就達成一致:世界上不需要兩套統(tǒng)一字符集。
1991年10月,兩個團隊決定合并字符集。也就是說,從今以后只發(fā)布一套字符集,就是Unicode,并且修訂此前發(fā)布的字符集,UCS的碼點將與Unicode完全一致。
UCS的開發(fā)進度快于Unicode,1990年就公布了第一套編碼方法UCS-2,使用2個字節(jié)表示已經(jīng)有碼點的字符。(那個時候只有一個平面,就是基本平面,所以2個字節(jié)就夠用了。)UTF-16編碼遲至1996年7月才公布,明確宣布是UCS-2的超集,即基本平面字符沿用UCS-2編碼,輔助平面字符定義了4個字節(jié)的表示方法。
兩者的關(guān)系簡單說,就是UTF-16取代了UCS-2,或者說UCS-2整合進了UTF-16。所以,現(xiàn)在只有UTF-16,沒有UCS-2。
七、JavaScript的誕生背景
那么,為什么JavaScript不選擇更高級的UTF-16,而用了已經(jīng)被淘汰的UCS-2呢?
答案很簡單:非不想也,是不能也。因為在JavaScript語言出現(xiàn)的時候,還沒有UTF-16編碼。
1995年5月,BrendanEich用了10天設(shè)計了JavaScript語言;10月,第一個解釋引擎問世;次年11月,Netscape正式向ECMA提交語言標準(整個過程詳見《JavaScript誕生記》)。對比UTF-16的發(fā)布時間(1996年7月),就會明白Netscape公司那時沒有其他選擇,只有UCS-2一種編碼方法可用!
八、JavaScript字符函數(shù)的局限
由于JavaScript只能處理UCS-2編碼,造成所有字符在這門語言中都是2個字節(jié),如果是4個字節(jié)的字符,會當(dāng)作兩個雙字節(jié)的字符處理。JavaScript的字符函數(shù)都受到這一點的影響,無法返回正確結(jié)果。
還是以字符為例,它的UTF-16編碼是4個字節(jié)的0xD834DF06。問題就來了,4個字節(jié)的編碼不屬于UCS-2,JavaScript不認識,只會把它看作單獨的兩個字符U+D834和U+DF06。前面說過,這兩個碼點是空的,所以JavaScript會認為
是兩個空字符組成的字符串!
上面代碼表示,JavaScript認為字符的長度是2,取到的第一個字符是空字符,取到的第一個字符的碼點是0xDB34。這些結(jié)果都不正確!
解決這個問題,必須對碼點做一個判斷,然后手動調(diào)整。下面是正確的遍歷字符串的寫法。
上面代碼表示,遍歷字符串的時候,必須對碼點做一個判斷,只要落在0xD800到0xDBFF的區(qū)間,就要連同后面2個字節(jié)一起讀取
類似的問題存在于所有的JavaScript字符操作函數(shù)。
String.prototype.replace()
String.prototype.substring()
String.prototype.slice()
...
上面的函數(shù)都只對2字節(jié)的碼點有效。要正確處理4字節(jié)的碼點,就必須逐一部署自己的版本,判斷一下當(dāng)前字符的碼點范圍。
九、ECMAScript 6
JavaScript的下一個版本ECMAScript 6(簡稱ES6),大幅增強了Unicode支持,基本上解決了這個問題。
(1)正確識別字符
ES6可以自動識別4字節(jié)的碼點。因此,遍歷字符串就簡單多了。
但是,為了保持兼容,length屬性還是原來的行為方式。為了得到字符串的正確長度,可以用下面的方式。
(2)碼點表示法
JavaScript允許直接用碼點表示Unicode字符,寫法是"反斜杠+u+碼點"。
但是,這種表示法對4字節(jié)的碼點無效。ES6修正了這個問題,只要將碼點放在大括號內(nèi),就能正確識別。
(3)字符串處理函數(shù)
ES6新增了幾個專門處理4字節(jié)碼點的函數(shù)。
String.fromCodePoint():從Unicode碼點返回對應(yīng)字符
String.prototype.codePointAt():從字符返回對應(yīng)的碼點
String.prototype.at():返回字符串給定位置的字符
(4)正則表達式
ES6提供了u修飾符,對正則表達式添加4字節(jié)碼點的支持。
(5)Unicode正規(guī)化
有些字符除了字母以外,還有附加符號。比如,漢語拼音的Ǒ,字母上面的聲調(diào)就是附加符號。對于許多歐洲語言來說,聲調(diào)符號是非常重要的。
Unicode提供了兩種表示方法。一種是帶附加符號的單個字符,即一個碼點表示一個字符,比如Ǒ的碼點是U+01D1;另一種是將附加符號單獨作為一個碼點,與主體字符復(fù)合顯示,即兩個碼點表示一個字符,比如Ǒ可以寫成O(U+004F)+ ˇ(U+030C)。
這兩種表示方法,視覺和語義都完全一樣,理應(yīng)作為等同情況處理。但是,JavaScript無法辨別。
ES6提供了normalize方法,允許"Unicode正規(guī)化",即將兩種方法轉(zhuǎn)為同樣的序列。
關(guān)于ES6的更多介紹,請看《ECMAScript 6入門》。
- JavaScript字符串對象fromCharCode方法入門實例(用于把Unicode值轉(zhuǎn)換為字符串)
- JS 文字符串轉(zhuǎn)換unicode編碼函數(shù)
- javascript實現(xiàn)unicode與ASCII相互轉(zhuǎn)換的方法
- js中unicode轉(zhuǎn)碼方法詳解
- JavaScript語言對Unicode字符集的支持詳解
- js unicode 編碼解析關(guān)于數(shù)據(jù)轉(zhuǎn)換為中文的兩種方法
- javascript實現(xiàn)unicode和字符的互相轉(zhuǎn)換
- JavaScript中字符串與Unicode編碼互相轉(zhuǎn)換的實現(xiàn)方法
相關(guān)文章
JavaScript 創(chuàng)建運動框架的實現(xiàn)代碼
本篇文章是對,在JavaScript中創(chuàng)建運動框架的實現(xiàn)方法進行了介紹。需要的朋友參考下2013-05-05推薦一些非常不錯的javascript學(xué)習(xí)資源站點
推薦一些非常不錯的javascript學(xué)習(xí)資源站點...2007-08-08caller和callee的區(qū)別介紹及演示結(jié)果
caller返回一個函數(shù)的引用,這個函數(shù)調(diào)用了當(dāng)前的函數(shù);callee放回正在執(zhí)行的函數(shù)本身的引用,它是arguments的一個屬性,感興趣的你可以參考下或許可以幫助到你2013-03-03document.all的一個比較完整的總結(jié)及案例
document.all想必學(xué)習(xí)javascript的同學(xué)們都很了解吧,本文主要是針對一些剛?cè)腴T的童鞋們做一下有關(guān)document.all的相關(guān)總結(jié),感興趣的朋友可以了解下,或許本文對你有所幫助2013-01-01