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

1. 我一定要特別指出來以表達我對 Twitter 竟然有考慮這個東西的震驚

2. str.codePointCount() 可以用 String.prototype 實做吧？Kenny 寫個 library
丟出來吧，哪天真的大家覺得不夠快就會被瀏覽器實做了？
（JSON，arr.forEach ... 等等好像都是這樣被實做的？）

> HTML5 規範的 4.1.1 [4] 提到，腳本的編碼判斷的優先序是：
> 腳本的 "Content-Type" 標頭 > charset > HTML 的編碼（若完全沒有任何資料的話繁體中文的瀏覽器 用 Big5，簡體中文用 GB18030）

3. 最後的（）有誤，「HTML 的編碼」就是 .html 檔案的編碼，跟瀏覽器的語言無關。
即便瀏覽器的語言是繁中也不一定會把最後的預設值設在 Big5，像我在 Fx3.6 的時候就把它改成 UTF-8 了（為了和英文版行為相同）

4. 贊成標準實作內嵌編碼，優先順序可以改成
    腳本的 "Content-Type" 標頭 > 內嵌編碼 > charset > HTML 的編碼
不然每次都要把中文字改成 \x12ab 真的很煩....

RFC2616 那種問題是因為當初寫標準的時候沒想清楚，實做了反而會有問題。實做 Unicode 應該不會有問題吧（沒處理好可能會導致相容問題就是）。


2011/6/8 Kang-Hao (Kenny) Lu <kennyluck@w3.org>:
> 做了一點實驗 行內回文
>
> 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
>
>

Received on Wednesday, 8 June 2011 02:14:35 UTC