W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > April 2012

Re: 求助:關於Big5和Big5-HKSCS的問題

From: Kang-Hao (Kenny) Lu <kennyluck@w3.org>
Date: Fri, 13 Apr 2012 20:59:41 +0800
Message-ID: <4F88233D.1030008@w3.org>
To: John Hax <johnhax@gmail.com>
CC: Hawkeyes Wind <hawkeyes0.cn@gmail.com>, W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>
(12/04/13 19:55), John Hax wrote:
> 2012/4/13 Kang-Hao (Kenny) Lu <kennyluck@w3.org>
> 
>>> 如果就初始问题来说,当标为<meta
>>>
>> charset="big5">的网页究竟应该使用何种编码,则我觉得可以结合该网页的lang属性来判断。如果lang=zh-HK则使用big5-hkscs,而如果lang=zh-TW则使用big5-uao。
>>
>> 你這個想法似乎刻意省略了沒有 @lang 的狀況,從[1] big5 網頁抽了一些來看,
>> 十個裡面有加 @lang 的只有一兩個。
>>
>> 另外,靠 @lang 決定編碼肯定不是一個瀏覽器開發者很喜歡的選擇。
>>
>>
> 并非刻意忽略,只是假如有lang属性(或者类似的http
> content-language头),可以帮助判断。在没有lang的情况,也可以检查用户在浏览器所设置的prefer
> lang。当然这个隐含前提是服务器有更大几率返回prefer lang的文件,或用户更大几率是在阅读和prefer
> lang一致的网页。而对于一个香港人阅读台湾网页或台湾人阅读香港网页就没什么帮助。(或者有反作用?)

如果最後真的無法統一 <meta charset=big5> 的解碼的話,後面這個部份我想是
相當合理。(當然還是要思考 prefer lang 裡沒有 zh-TW 也沒有 zh-HK 的狀況)

至於 @lang 的部份,我想這個策略能解決的問題沒多到值得做這種比較大幅度的
更動。

> 根据解码异常或者字频统计来改变编码(估计已经超出了当前在parse阶段编码嗅探算法的要求)。

目前規範的描述:

  # 7. 使用者代理可嘗試透過頻率分析或其他演算法自動偵測資料串流的編碼。
  # 這些演算法可使用檔案內容以外的資訊,包括檔案的網址。若自動偵測成功並
  # 可得到字符編碼,則回傳該編碼,可信度為「暫時」,並退出這些步
  # 驟。[UNIVCHARDET]

除了對這個順位有要求以外,對實質算法基本沒有要求。

>>> 并且提供额外的设置编码手段给用户(比如在网页顶部显示几种big5
>>> variants的选择按钮)。
>>
>> 你是說「編碼嗅探演算法」[2]第一步?
>>
> 
> 其实这里我指的并非是在parse阶段或页面解码之前,而是指当页面以某种编码显示之后,假如浏览器发现也可能是另外一种编码,则给用户修改的可能。

我要提一下在現在瀏覽器中,用介面改編碼之後,整個頁面是重讀、重解析一遍
的,所以當然是解析階段之前的事。你講得我聽起來好像就是「編碼嗅探演算法」
第一步。我誤會了什麼嗎?

>> 這裡的確是沒有一個類似「使用者代理必須提供使用者覆蓋文件字符編碼的方法」
>> 之類的規範符合敘述。你有興趣提這個意見嗎?(我倒是有點好奇這個規範符合敘
>> 述的可行性,特別是在行動裝置上的狀況。)
>>
>>
> 不一定是“必须提供(MUST/SHOULD)”,我觉得讲“可以(MAY)提供”应该就成了。其实即使在mobile设备上也是可以的,因为不过就是显示两个额外的按钮就可以了(类似记住密码之类的)。

不反對。



此致

Kenny
Received on Friday, 13 April 2012 13:00:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:50 UTC