国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Unicode與JavaScript詳解

econi / 1503人閱讀

摘要:本文大部分內容轉自阮一峰前輩的文章,更新了部分內容并加入了部分自己的理解。字符串處理函數新增了幾個專門處理字節碼點的函數。參考鏈接阮一峰與詳解輔助平面入門

本文大部分內容轉自 阮一峰前輩的文章,更新了部分內容并加入了部分自己的理解。

Unicode是什么?

Unicode源于一個很簡單的想法:將全世界所有的字符包含在一個集合里,計算機只要支持這一個字符集,就能顯示所有的字符,再也不會有亂碼了。

它從0開始,為每個符號指定一個4個字節的編號,這叫做"碼點"(code point)。比如,碼點0的符號就是null(表示所有二進制位都是0),中文"好"的碼點是十六進制的597D

U+0000 = null
U+597D = 好

上式中,U+表示緊跟在后面的十六進制數是`Unicode的碼點。

目前,Unicode的最新版本是10.0版,一共收入了136690個符號,這么多符號,Unicode不是一次性定義的,而是分區定義。每個區可以存放65536個(216)字符,稱為一個平面(plane),定義了17個平面,目前Unicode字符集的大小是1,114,112(17*216)。

最前面的65536個字符位,稱為基本平面(縮寫BMP,它的碼點范圍是從0一直到216-1,寫成16進制就是從U+0000U+FFFF。所有最常見的字符都放在這個平面,這是Unicode最先定義和公布的一個平面。剩下的字符都放在輔助平面(縮寫SMP,碼點范圍從U+010000一直到U+10FFFF。

16個輔助平面目前只用了6個:

第一輔助平面(SMP),擺放拼音文字(主要為現時已不再使用的文字)及符號。范圍在 U+10000 ~ U+1FFFD。

第二輔助平面(SIP),整個范圍在 U+20000 ~ U+2FFFD?,F時擺放“中日韓統一表意文字擴展B區”,共43,253個漢字,以及中日韓兼容表意文字增補 (CJK Compatibility Ideographs Supplement)。

第三 ~ 十三輔助平面,暫未使用。

第十四輔助平面(SSP),擺放 Language tagsVariation Selectors ,它們都是控制字符。范圍在 U+E0000 ~ U+E01FF。

第十五 ~ 十六輔助平面都是私人使用區。它們的范圍是 U+F0000 ~ U+FFFFDU+100000 ~ U+1000FD

Unicode只是一個符號集,它只規定了符號的二進制代碼(碼點),卻沒有規定到底用什么樣的字節序表示這個碼點,所以出現了不同的編碼方式---UTF-32,UTF-16,UTF-8

UTF-32與UTF-8

由于每個碼點為4個字節,所以最直觀的編碼方法是使用4個字節表示,字節內容一一對應碼點。這種編碼方法就叫做UTF-32。比如,碼點0就用四個字節的0表示,碼點597D就在前面加兩個字節的0。

U+0000 = 0x0000 0000
U+597D = 0x0000 597D

UTF-32的優點在于,轉換規則簡單直觀,查找效率高。
缺點在于浪費空間,同樣內容的英語文本,它會比ASCII編碼大四倍。這個缺點很致命,導致實際上沒有人使用這種編碼方法,HTML5標準就明文規定,網頁不能編碼成UTF-32

人們真正需要的是一種節省空間的編碼方法,這導致了UTF-8的誕生。UTF-8是一種變長的編碼方法,字符長度從1個字節到4個字節不等。越是常用的字符,字節越短,最前面的128個字符,只使用1個字節表示,與ASCII完全相同。

碼點范圍 字節數 可容納字符個數
0x0000 ~ 0x007F 1 128
0x0080 ~ 0x07FF 2 1920
0x0800 ~ 0xFFFF 3 63488
0x010000 ~ 0x10FFFF 4 1048575

由于UTF-8這種節省空間的特性,導致它成為互聯網上最常見的網頁編碼。

UTF-16

UTF-16編碼介于UTF-32UTF-8之間,同時結合了定長變長兩種編碼方法的特點。
它的編碼規則很簡單:

基本平面的字符占用2個字節;

輔助平面的字符占用4個字節。

也就是說,UTF-16的編碼長度要么是2個字節(U+0000~U+FFFF),要么是4個字節(U+010000~U+10FFFF)。

于是就有一個問題,當我們遇到兩個字節,怎么看出它本身是一個字符,還是需要跟其他兩個字節放在一起解讀?
說來很巧妙,不知道是不是故意的設計,在基本平面內,從U+D800~U+DFFF是一個空段,即這些碼點不對應任何字符。因此,這個空段可以用來映射輔助平面的字符。
具體如下,先來計算一下輔助平面的碼點共有多少個:

$$17*2^{16} - 2^{16} = 2^{16} * 2^4 = 2^{20}$$

再計算一下需要多少個二進制位,220個碼點,意味著最后一個碼點對應于(從0開始所以要減1):
$$2^{20} - 1 $$

轉換為16進制便是0xFFFFF,對應的二進制位數為20位,也就是說,對應這些字符至少需要20個二進制位。

UTF-16將這20位拆成兩半,前10位映射在U+D800~U+DBFF(空間大小210),稱為高位(H),后10位映射在U+DC00U+DFFF(空間大小210),稱為低位(L)。這意味著,一個輔助平面的字符,被拆成兩個基本平面的字符表示。

所以,當我們遇到兩個字節,發現它的碼點在U+D800~U+DBFF之間,就可以斷定,緊跟在后面的兩個字節的碼點,應該在U+DC00~U+DFFF之間,這四個字節必須放在一起解讀

UTF-16的轉碼公式

Unicode碼點轉成UTF-16的時候,首先區分這是基本平面字符,還是輔助平面字符。如果是前者,直接將碼點轉為對應的十六進制形式,長度為兩字節。

U+597D = 0x597D

如果是輔助平面字符,Unicode 3.0版給出了轉碼公式,對于碼點c

H = Math.floor((c - 0x10000) / 0x400) + 0xD800
L = (c - 0x10000) % 0x400 + 0xDC00

以字符?為例,它是一個輔助平面字符,碼點為U+20BB7,將其轉為UTF-16的計算過程如下。

H = Math.floor((0x20BB7 - 0x10000) / 0x400) + 0xD800 = 0xD842
L = (0x20BB7 - 0x10000) % 0x400 + 0xDC00 = 0xDFB7

所以,?字符的UTF-16編碼就是0xD842DFB7,長度為四個字節。

JavaScript使用哪一種編碼?

JavaScript語言采用Unicode字符集,但是只支持一種編碼方法。

這種編碼既不是UTF-16,也不是UTF-8,更不是UTF-32。上面那些編碼方法,JavaScript都不用。JavaScript用的是UCS-2

UCS-2編碼

怎么突然殺出一個UCS-2?這就需要講一點歷史。

互聯網還沒出現的年代,曾經有兩個團隊,不約而同想搞統一字符集。一個是1988年成立的Unicode團隊,另一個是1989年成立的UCS團隊。等到他們發現了對方的存在,很快就達成一致:世界上不需要兩套統一字符集
199110月,兩個團隊決定合并字符集。也就是說,從今以后只發布一套字符集,就是Unicode,并且修訂此前發布的字符集,UCS的碼點將與Unicode完全一致。

UCS的開發進度快于Unicode1990年就公布了第一套編碼方法UCS-2,使用2個字節表示已經有碼點的字符。(那個時候只有一個平面,就是基本平面,所以2個字節就夠用了。)。

UTF-16編碼遲至19967月才公布,明確宣布是UCS-2超集,即基本平面字符沿用UCS-2編碼,輔助平面字符定義了4個字節的表示方法。

兩者的關系簡單說,就是UTF-16取代了UCS-2,或者說UCS-2整合進了UTF-16。所以,現在只有UTF-16,沒有UCS-2

JavaScript的誕生背景

那么,為什么JavaScript不選擇更高級的UTF-16,而用了已經被淘汰的UCS-2呢?

答案很簡單:非不想也,是不能也。因為在JavaScript語言出現的時候,還沒有UTF-16編碼。

19955月,Brendan Eich用了10天設計了JavaScript語言;10月,第一個解釋引擎問世;次年11月,Netscape正式向ECMA提交語言標準(整個過程詳見《JavaScript誕生記》)。對比UTF-16的發布時間(19967月),就會明白Netscape公司那時沒有其他選擇,只有UCS-2一種編碼方法可用!

JavaScript字符函數的局限

由于JavaScript`只能處理UCS-2編碼,造成所有字符在這門語言中都是2個字節,如果是4個字節的字符,會當作兩個雙字節的字符處理。JavaScript的字符函數都受到這一點的影響,無法返回正確結果。

還是以?字符為例,它的UTF-16編碼是4個字節的0xD842DFB7。問題就來了,4個字節的編碼不屬于UCS-2,JavaScript不認識,只會把它看作多帶帶的兩個字符U+D842U+DFB7。前面說過,這兩個碼點是空的,所以JavaScript會認為是兩個空字符組成的字符串!

`?`.length //2
`?` === "u20BB7" //false
`?`.charAt(0) // "?"
`?`.charCodeAt(0) // 55362(0xD842)

上面代碼表示,JavaScript認為字符?的長度是2,取到的第一個字符是"?"字符,取到的第一個字符的碼點是0xD842。這些結果都不正確!

解決這個問題,必須對碼點做一個判斷,然后手動調整。下面是正確的遍歷字符串的寫法。

var index = -1;
var string = "?12";
var length = string.length;
var output = [];
while (++index < length) {
  var charCode = string.charCodeAt(index);
  var character = string.charAt(index);
  if (charCode >= 55296 && charCode <= 56319) {
    output.push(character + string.charAt(++index));
  } else {
    output.push(character);
  }
}
console.log(output) //["?", "1", "2"]

上面代碼表示,遍歷字符串的時候,必須對碼點做一個判斷,只要落在55296~56319(0xD800~0xDBFF)的區間,就要連同后面2個字節一起讀取。

類似的問題存在于所有的JavaScript字符操作函數。

String.prototype.replace()
String.prototype.substring()
String.prototype.slice()
...

上面的函數都只對2字節的碼點有效。要正確處理4字節的碼點,就必須逐一部署自己的版本,判斷一下當前字符的碼點范圍。

ECMAScript 6

JavaScriptECMAScript 6版本(簡稱ES6),大幅增強了Unicode支持,基本上解決了這個問題。

正確識別字符
ES6可以自動識別4字節的碼點。因此,遍歷字符串就簡單多了。

let s = "?12";
let output = [];
for(let s of string ){ 
    output.push(s)
}
console.log(output) //["?", "1", "2"]

但是,為了保持兼容,length屬性還是原來的行為方式。為了得到字符串的正確長度,可以用下面的方式。

Array.from(string).length

碼點表示法
JavaScript一直允許直接用碼點表示Unicode字符,寫法是uxxxx形式,其中xxxx表示字符的Unicode 碼點。

"好"==="u597D" // true

但是,這種表示法對4字節的碼點無效。ES6修正了這個問題,只要將碼點放在大括號內,就能正確識別。

"?" === "u20BB7" //false
"?" === "u{20BB7}" //true

字符串處理函數
ES6新增了幾個專門處理4字節碼點的函數。

String.fromCodePoint():對應于String.fromCharCode(),從Unicode碼點返回對應字符

String.prototype.codePointAt():對應于String.prototype.charCodeAt(),從字符返回對應的Unicode碼點

String.prototype.at():對應于String.prototype.charAt(),返回字符串給定位置的字符

正則表達式
ES6提供了u修飾符,含義為Unicode模式,對正則表達式添加4字節碼點的支持。

Unicode正規化
有些字符除了字母以外,還有附加符號。比如,漢語拼音的ǒ,字母上面的聲調就是附加符號。對于許多歐洲語言來說,聲調符號是非常重要的。

Unicode提供了兩種表示方法,一種是帶附加符號的單個字符,即一個碼點表示一個字符,比如ǒ的碼點是U+01D1;另一種是將附加符號多帶帶作為一個碼點,與主體字符復合顯示,即兩個碼點表示一個字符,比如ǒ可以寫成O(U+004F)+ˇ(U+030C)。

這兩種表示方法,視覺和語義都完全一樣,理應作為等同情況處理。但是,JavaScript無法辨別。

"u01D1"==="u004Fu030C" //false

ES6提供了normalize方法,允許"Unicode正規化",即將兩種方法轉為同樣的序列。

"u01D1".normalize()==="u004Fu030C".normalize() // true

參考鏈接

阮一峰--Unicode與JavaScript詳解
輔助平面
ECMAScript 6 入門

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/94569.html

相關文章

  • Unicode中UTF-8UTF-16編碼詳解

    摘要:概念是一種針對的可變長度字符編碼,又稱萬國碼。通過上面的介紹我們可以知道,是一種非常通用的可變長字符編碼方式。概念是字符編碼五層次模型的第三層字符編碼表,也稱為的一種實現方式。 概述 本文通過介紹Unicode編碼以及對應的兩種編碼方式UTF-8和UTF-16,讓讀者能夠了解關于字符串編碼的相關知識,同時能夠弄清楚Unicode和UTF-8和UTF-16之間的關系。 本文的主要內容為:...

    cod7ce 評論0 收藏0
  • JavaScript如何實現UTF-16編碼轉換為UTF-8編碼——utfx.js源碼解析

    摘要:編碼轉換為編碼下面讓我們來看下如何將編碼的數據轉換為編碼的數據。該方法是將碼進行編碼轉換,從而得到編碼的數據。 概述 當你在前端需要通過二進制數據與服務端進行通信時,你可能會遇到二進制數據的編碼問題。大部分服務端的字符串編碼類型都為UTF-8,而JavaScript中字符串編碼類型是UTF-16,因此,你需要一個能夠將字符串在兩種編碼方式間進行轉換的方法。 本文通過對utfx.js這個...

    maybe_009 評論0 收藏0
  • 詳解一下 javascript 中=====的比較

    摘要:當和為引用同一對象時返回。若為且為,返回比較的結果。等價于,除了與的執行順序。所以標準中認為相等的值可能被檢測為不等。實際上這一算法認為兩個字符串已經是經過規范化的形式。 ** 11.9.3 抽象相等比較算法 **比較運算 x==y, 其中 x 和 y 是值,產生 true 或者 false。這樣的比較按如下方式進行: 若 Type(x) 與 Type(y) 相同, 則若 Type(x...

    wwq0327 評論0 收藏0
  • 詳解一下 javascript 中的比較

    摘要:今天在筆試題被公子給了,遂想起之前要寫的一篇文章,中蛋疼的比較運算。當和為引用同一對象時返回。若為且為,返回的結果。所以標準中認為相等的值可能被檢測為不等。實際上這一算法認為兩個字符串已經是經過規范化的形式。 今天在 JS筆試題 被 @公子 給AT了,遂想起之前要寫的一篇文章,javascript 中蛋疼的比較運算。 翻譯自:http://www.ecma-international....

    Pluser 評論0 收藏0
  • JavaScript 闖關記》之語法

    摘要:的語法大量借鑒了及其他類語言如和的語法。也就是說,關鍵字變量函數名和所有的標識符都必須采取一致的大小寫形式。中的字面量有字符串數字布爾值對象數組函數正則表達式,以及特殊的值。這是為了不破壞語法而特意選定的語法。 JavaScript 的語法大量借鑒了 C 及其他類 C 語言(如 Java 和 Perl)的語法。因此,熟悉這些語言的開發人員在接受 JavaScript 更加寬松的語法時,...

    xiangzhihong 評論0 收藏0

發表評論

0條評論

econi

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<