JavaScript 的非基本多文種平面（non-BMP）字符支援 （原: 字符编码）

做了一點實驗 行內回文

>>> 2011/5/9 Timothy Chien <timdream@gmail.com>:
>>>> 那是記憶體內部處理文字的標準吧？與檔案的編碼無關。
>>>> 意思是說，
>>>>
>>>> ('字').charCodeAt(0)
>>>>
>>>> 會傳回 UCS-2 code point。

我用這個字試了幾的瀏覽器：

「𠂇」 U+20087 &#131207;
代理對（surrogate pair）： D870 DC87
十進位： 55360 56455

（不要問我這個字是什麼，隨便找的。我只知道這字讓我想到娜美（ナミ）xd）

基本上 Firefox, Chrome, Safari 都說 "𠂇".length = 2

不信的在瀏覽器 URL 條打 「javascript:alert("𠂇".length)」 試試看


比較有趣的是，Twitter 在那個限制輸入 140 字的做法竟然把 "𠂇"  的長度算對
成 1 了。他們的源碼是這樣寫的：

displayLength:function(string){
  if(typeof string!=="string"){throw new Error("displayLength() requires
a single input of type string")}
  var i=0,length=0;
  var getWholeChar=function(str,i){
    var code=str.charCodeAt(i);
    var next="",prev="";
    if(55296<=code&&code<=56319){
      if(str.length<=(i+1)){throw"High surrogate without following low
surrogate"}
      next=str.charCodeAt(i+1);
      if(56320>next||next>57343){throw"High surrogate without following
low surrogate"}
      return str.charAt(i)+str.charAt(i+1)}
    else{
      if(56320<=code&&code<=57343){
        if(i===0){throw"Low surrogate without preceding high surrogate"}
        prev=str.charCodeAt(i-1);
      if(55296>prev||prev>56319){throw"Low surrogate without preceding
high surrogate"}
      return false}}
    return str.charAt(i)
  };
  for(i=0,length=0;i<string.length;i++){
    if(getWholeChar(string,i)===false){continue}
    length++
  }
return length} （版權所有 Twitter，做這種事有犯法的話麻煩私下指點一
下、、、）

也就是說他有特地去處理代理對的情形。（雖然其實我不太理解為什麼 Twitter
對不同語言同樣是限制 140 字 xdd）

新浪微博打 "𠂇" 這個字的話就會佔兩個剩下字數，那跟
"𠂇".match(/[^\x00-\x80]/g).length = 2 而不是 1 有關，不過新浪微博還有一
些很奇怪的現象（空白不占字數、英字占半個）之類的，所以這種小地方似乎也不
需要在意了。


剩下的問題就是，有沒有必要為這種比較罕見的情形弄出新的 JavaScript API
（ECMAScript6？）
比如說在 Java 裡，除了 length 以外還有 codePointCount、codePoint 這些方
法[1]：

String s = "𠂇";
System.out.println(s.length()); //顯示為 2
System.out.println(s.codePointCount(0, s.length())); //顯示為 1
System.out.println(s.codePointAt(0)); // 顯示為 131207 也就是 "𠂇" 的值
System.out.println(s.codePointAt(1)); // 顯示為 56455 也就是 "𠂇" 的後半部

也就是說 codePointAt(N) 不是第 N 個字符，而是「若第 N 個 16-bit 是某個代
理對的前半部，輸出整個字」，是一個不需要掃描整個字串的方式。

[1] http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html


這個問題好像在 3 年前在 Python 社群也論戰過[2]，有些人希望：

s = "𠂇"
len(s) // 輸出為 1

核心社群的回答是「想都別想」（現在是 2），但是核心社群可以接受跟 Java 一
樣多一個 API（不過似乎還沒有人有貢獻 :( ）

[2] http://mail.python.org/pipermail/python-dev/2008-July/thread.html#80886


回到 JavaScript，一般來說，為了向後支援 "𠂇".length 或是
"𠂇".charCodeAt(0) 之類的要改也是「想都別想」。不過我們有
"𠂇".codePointCount 跟 String.prototype.codePointAt(N) 的需求嗎？這個需
求有夠大嗎？

codePointCout 的好處當然就是用瀏覽器的 C++ code 比 Twitter 那個快，而
codePointAt 就是 timdream 找到的 JavaScript code

>>>> 不過後果就是 UCS-2 塞不進去的 Unicode code point，像是 Ext-B 的漢字，
>>>> 在 Javascript 裡面會被拆成兩個字元，這時要找到真正的 Unicode code point 就要把兩個字元的字碼都讀出來處理：
>>>>
>>>> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/charCodeAt#Example_2.3a_Fixing_charCodeAt_to_handle_non-Basic-Multilingual-Plane_characters_if_their_presence_earlier_in_the_string_is_unknown

的 C++ 版本

(11/05/09 11:05), Ben Luo wrote:
> 那也就是说 browser 在载入js文件的时候会自动转换成 UCS-2？它是怎么自动判断文件本身的编码呢？
>
> 2011/5/9 Timothy Chien <timdream@gmail.com>:
>> <script type="text/javascript" src="script.js" charset="utf-8" ></script>
>>
>> 根據 HTML4 標準設定 charset 屬性
>> http://www.w3.org/TR/html401/interact/scripts.html#edef-SCRIPT

HTML5 裡面也有 這個屬性
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-charset
到這裡為止，可以判斷這個屬性至少在未來可以用。

> 不過我不知道哪家瀏覽器吃就是了。

測試了一下 Firefox4 跟 Chrome11 都可以用。如果我有多一點勇氣相信
W3school 的內容[3]我就不需要要做測試了，這似乎是存在很久的東西了。

[3] http://www.w3schools.com/tags/att_script_charset.asp

> 最保險的做法是保持和引用的 HTML 同樣的 encoding，

HTML5 規範的 4.1.1 [4] 提到，腳本的編碼判斷的優先序是：

腳本的 "Content-Type" 標頭 > charset > HTML 的編碼（若完全沒有任何資料的
話繁體中文的瀏覽器 用 Big5，簡體中文用 GB18030）

所以這個方法要確保伺服器不會亂傳 "Content-Type"。

[4]
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#execute-the-script-block

> 或是只要用到 ASCII 以外的字元通通用 \x12ab 來表示。
> （寫 script 也不該出現那些介面用文字，介面字串資源和程式應該要分開）

這個方法似乎比較保險，不過不想做英文界面的時候有時候要分開字串跟程式很麻
煩的。

(11/05/09 12:12), Ben Luo wrote:
> 当然这和 html5 无关，只是好奇，为什么JS只规定内部编码，不规定文件编码，毕竟JS不是凭空生产的。

我想主要是不實際的關係，大家都知道 JS 最主要的用戶代理（user agent）就是
瀏覽器，而瀏覽器一定會決定一個 HTML 的編碼而 JS 的預設文件編碼就會是那
個，就算在 JS 的規範定義了一個預設的編碼也可能會被 HTML 的編碼蓋掉，就沒
有那個預設編碼的意義了。另一方面，要把上面提的優先順序寫進 JS 的規範的話
就會變成 JS 依存於 HTTP 及 HTML 而破壞這個結構。一個類似的例子是 HTTP 規
範（RFC2616[5]）定義了 ISO-8859-1 作為預設的編碼，但是這在 HTML 下完全不
被使用（仍然是用瀏覽器的使用者語言為最終的編碼），變成了不是很有意義的規
範敘述。

[5] http://tools.ietf.org/html/rfc2616

另一方面可以討論的問題是 JS 該不該有類似 Python 的內嵌編碼宣告[6]：

# -*- coding: utf-8 -*-

畢竟伺服器端用的 JS 可能會越來越多（因為有Node.js）。這個問題就留給大家
討論了（有人知道Node.js的情形嗎？），不過對於瀏 覽器來說，會需要定義優先
序為：

腳本的 "Content-Type" 標頭 > charset > 內嵌編碼 > HTML 的編碼  

或是

腳本的 "Content-Type" 標頭 > 內嵌編碼 > charset > HTML 的編碼

甚至是直接忽略內嵌編碼。恐怕蠻難下一個決定的。

(11/05/09 10:13), Ben Luo wrote:
> 昨天看 ECMAScript v5 的标准，字符编码要求是UCS-2 或 UTF-16,
> 在html5中是什么要求？在现实中好像大家都是用utf-8作为字符编码。对此大家有什么心得？

補個 ECMAScript v5 連結 → http://people.mozilla.org/~jorendorff/es5.html
推薦給對 JS 種種奇怪行為感到憤怒的朋友們

也歡迎大家帶其他標準的心得與討論進來這個討論組（包括IETF），若是有更好的
討論地方也歡迎提供連結！


此致

呂 康豪（Kenny）, 中文興趣小組W3C連絡人
推特: http://twitter.com/kanghaolu
噗浪: http://www.plurk.com/kennyluck
新浪微博: http://t.sina.com.cn/1950042164