Re: 用 xhr 抓 text/html 時的預設編碼

于 2011/10/27 19:16, Kang-Hao (Kenny) Lu 写道:
> 由於一般瀏覽時候判斷 HTML 編碼的規則非常的...瘋狂（比如說還有重讀的情況
> [1]），上個月 Web Applications 工作組 Mozilla 的約聘工程師 Henri
> Sivonen（Mozilla HTML5 解析器的實作者）提出 XHR2[2] 在碰到 text/html 文
> 件時，xhr.responseXML （XHR1 的 responseXML 不支援 text/html）應該了一套
> 簡單版的決定編碼規則。具體來說大部分都還好，問題在於這個簡單版的決定編碼
> 規則最後的預設編碼，在沒有
>
> * HTTP Content-Type
> * BOM
> *<meta>
>
> [1]
> http://www.w3.org/html/ig/zh/wiki/HTML5#.E8.A7.A3.E6.9E.90.E6.99.82.E7.9A.84.E7.B7.A8.E7.A2.BC.E8.AE.8A.E6.9B.B4
> 第四步
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread#msg1562
>
> 的情況下會變成 UTF-8，而不是一般正常瀏覽的時候因不同語言環境有不同預設值
> （zh-TW 為 Big5，zh-CN 為 GB18030）。基本上大家有 responseText 跟
> responseXML 應該用同樣判斷編碼規則的共識，但是同樣是 Mozilla 工程師的
> Jonas Sicking 擔心這樣做會破壞向後兼容性，特別是 CJK 的環境，不過沒得到
> 什麼共鳴。HTML 規範也已經有一個 bug 在那裡了[3]，HTML 規範改了之後 XHR2
> 的規範也會因此改變[4]。
>
> XHR 預設編碼為 UTF-8 的好處：
> * 不會再有因不同語言環境，有的瀏覽器出現亂碼有的不出現亂碼的恐怖情形。
> * Gecko 的 responseText 的預設早已是 UTF-8（其他瀏覽器尚為了解，有請高人
> 指點），以後改用 responseXML（或 response）不會有兼容問題。
>
> 壞處：
> * 在不能更改舊有內容的 HTTP Content-Type 或是<meta>  的情況下，假如說你
> 想弄一個新的 AJAX 的東西，如果不知道 xhr.overrideMimeType() 的話會得到亂
> 碼。而且在有些內容用 UTF-8 有些不是的情況下，overrideMimeType 也不一定好
> 寫（可能會不小心把 UTF-8 蓋掉成 Big5 之類的）
>
> 大家覺得呢，有人反對預設編碼改成 UTF-8 的嗎？
>
> [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284
> [4]
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#text-response-entity-body
>
> 補充一下，Henri Sivonen 的提案是不用[5]的第 6, 7, 8 步，另外就是永遠不會
> 進入「變更編碼」的步驟（所以不會有 XHR 還讀兩次的可怕情形）。
>
> [5]
> http://www.w3.org/html/ig/zh/wiki/HTML5#.E6.B1.BA.E5.AE.9A.E5.AD.97.E7.AC.A6.E7.B7.A8.E7.A2.BC
> [6] http://www.w3.org/html/ig/zh/wiki/HTML5#change-the-encoding
>
>
> 此致
>
> 呂 康豪（Kenny）, 中文興趣小組W3C連絡人
> Google+: https://plus.google.com/112088462407783855918/posts
> 新浪微博: http://t.sina.com.cn/1950042164
>
>
實際上，預設編碼為UTF-8幾乎成為國際共識了。在目前OS層面已經原生支持 
Unicode了，已經掃清了一切障礙了，且現在的開發工具，不管 是Eclipse、 
NetBeans、VS什麼的，默認保存的編碼格式也都是UTF-8了。
稍微寫個遍歷目錄文件轉碼Save as的工具也並不複雜，Java或者.net實現起來都 
沒難度。應該沒有完全不能轉碼的遺留系統吧。

-- 
Regards

Hawkeyes Wind

Received on Tuesday, 1 November 2011 04:45:34 UTC