HKSCS 或許將取代 Big5

[WitchFive]

各位好：

相關前後事件我列在這邊：http://forum.moztw.org/viewtopic.php?f=10&t=40427

目前 bug 912470 要求 moztw 相關人員上去提供意見這樣。
https://bugzilla.mozilla.org/show_bug.cgi?id=912470

HKSCS 或許將被直接扶正為 Big5。

[Peter Chen]

在車上，還沒有很完整讀完始末，剛剛才經過 opera....

沒記錯的話，hkscs 是不是用的人不多了?
如果是，我覺得拿 hkscs 蓋掉是個不大好的做法。另外如果拿 -hkscs 蓋掉 -uao，會有影響的部分除了像網頁版 Ptt 的 big5 日文假名，還會有其他內容?

Sammy 你覺得呢?

--
您已訂閱「Google 網上論壇」的「moztw-general: 摩茲將軍」群組，因此我們特別傳送這封郵件通知您。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 moztw-genera...@googlegroups.com。
如要在此群組張貼留言，請傳送電子郵件至 moztw-...@googlegroups.com。
如要在網路上查看這項討論，請造訪 https://groups.google.com/d/msgid/moztw-general/32f1b320-3ae7-4ddb-adcf-9ae4b95337ad%40googlegroups.com。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[WitchFive]

Peter Chen於 2013年10月11日星期五UTC+8上午12時45分34秒寫道：

在車上，還沒有很完整讀完始末，剛剛才經過 opera....

沒記錯的話，hkscs 是不是用的人不多了?
如果是，我覺得拿 hkscs 蓋掉是個不大好的做法。另外如果拿 -hkscs 蓋掉 -uao，會有影響的部分除了像網頁版 Ptt 的 big5 日文假名，還會有其他內容?

日文假名不會有影響，有影響的是漢字。

另外如果我沒記錯的話，mozilla 的 hkscs 到目前為止一直是雙向對應的。

[Timothy Chien]

PTT 網頁版已經是 UTF-8 網頁了，有影響的應該是一些舊 BBS 的 big5 網頁？

這件事情我覺得很難搞，因為我們沒有足夠的數據去說影響的範圍有多大（到底還有多少 big5-eten 或 big5-uao 網頁），然後兩者和
hkscs 不相容的部份又不是什麼有名字的既存標準（「big5-uao」只是寫信講話用的 label，沒人會在網頁上這樣標 <meta>）。

老實說研究完如果結論是影響不大就讓他去吧我也覺得沒關係。

(CC'ing but，據說頭銜是「UAO 的始作俑者」）



2013/10/11 WitchFive <s79...@gmail.com>:

> --
> 您已訂閱「Google 網上論壇」的「moztw-general: 摩茲將軍」群組，因此我們特別傳送這封郵件通知您。
> 如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到
> moztw-genera...@googlegroups.com。
> 如要在此群組張貼留言，請傳送電子郵件至 moztw-...@googlegroups.com。
> 如要在網路上查看這項討論，請造訪

> https://groups.google.com/d/msgid/moztw-general/199de727-bab9-4282-ae64-0b3e1ae29a73%40googlegroups.com。
> 如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[But Ko]

就 UAO 始作俑者的角度來說，

現在 PTT 已經轉 utf-8 處理 Web 版了，

所以 Mozilla 是否要支援 big5-uao，我覺得不是大問題，用 big5-cp950 也無妨。

但直接拿 big5-hkscs 去取代 big5 有點誇張。

反而是日文假名的部分影響比較大。

現在 Mozilla 用的 big5 是多年前 piaip 提報的，號稱是 UAO，

其實只有 Big5 => Unicode 的部分是 big5-uao，

而 Unicode => Big5 的部分是 big5-cp950 的不對稱版本。

這是為了讓表單提交文字到 big5 頁面時，

碰到日文假名、UAO 等 cp950 沒有的字，

還是故意讓他轉成 entity reference，盡量別產生外字編碼。

事實上當年 Firefox 1.x 原本採用的 Big5 是 Big5-2003，

也就是包含雙向日文假名對應的版本。

但一推出馬上造成 Firefox 送出的日文假名，在其他瀏覽器都看不到的問題。

如果真的採用 Big5-hkscs 作為 Big5，

因為 Big5-hkscs 是雙向對應，會有一樣的問題。

日文假名提交到 Big5 頁面時，就真的會以 Big5 形式傳出去，而不是 entity reference（&#xxx;）。

結果其他瀏覽器看不到 Mozilla 送出的日文假名。

其實台灣網頁的有趣性，

就在於其實 big5-uao 、 big5-eten 的網頁都不多，最多的是 big5-cp950。

而 big5-cp950 與 big5-hkscs 乍看很相容，

所以老外才會想說乾脆合併起來，反正 big5-hkscs 包含所有 big5-cp950 有定義的字。

但盲點在，偏偏台灣網站又很常使用 big5-cp950 range 以外的字，

像是日文假名、着、酶、堃之類的字。

這些字長久以來用 entity reference 去支援，大家都相安無事，

但拿 big5-hkscs 去支援他，反而在其他瀏覽器預設看不到的矛盾。

不如就讓它不再 big5 裡，已 entity reference 處理，反而比較能確保每個環境都能看到。

尤其是 big5-hkscs 使用者其實沒想像中的多，

似乎香港PC也不是全都在用 hkscs (待確認)。

若要拿掉現在雙向非對應的 big5-uao 版本，

留下 big5 (= big5-cp950) 與 big5-hkscs 是我覺得比較好的做法。

直接統一 hkscs 實在有點殘暴。

不過多數網站都是 UTF-8 的今日，其實影響可能也不大就是了。

2013/10/11 Timothy Chien <timd...@gmail.com>

[Timothy Chien]

感謝，我會試著把這個 comment 用英文解釋在 bug 上面。

2013/10/11 But Ko <butt...@gmail.com>:

[WitchFive]

同意 but 的論點。

說真格的，現時我看的站台內容跟以前已經不大相同，目前已經沒有以往那麼大的外字需求，
而且如果有需要我還可以自己編私用版 sm / fx ...

But Ko於 2013年10月11日星期五UTC+8下午3時37分50秒寫道：

[Sammy Fung]

剛剛回到香港不久.....

首先，香港的 Big5 網站都是 Big5-HKSCS，如果沒有 Big5-HKSCS 當然不能，因為有一些香港字是常用的，例如商業區鰂魚涌的 "鰂" 字。

我不認同刪除 HKSCS 的做法，也不認同 HKSCS 取代 Big5。

最後，不是只考慮 "香港PC也不是全都在用 hkscs"﹐而是有些網站仍在用 HKSCS，沒理由讓使用者看見爛字或錯字。

我同意如以往留下 big5 (= big5-cp950) 與 big5-hkscs 是我覺得比較好的做法。

2013/10/11 WitchFive <s79...@gmail.com>

[WitchFive]

這兩天發現的，看來 tw 消失會發生的比想像的快

[Timothy Chien]

報告報告，Bug 912470 目前的進度是要確定 Unicode to big5 (encoder) 的部份，spec 無誤且適合實作。

http://encoding.spec.whatwg.org/#big5-encoder
我看了說明，沒有看實際的 index 跟數學，不過 Note 有提到避免產生 HKSCS 的 byte，所以應該沒有問題了？

我回的留言在這邊如果有錯的話還煩請去糾正一下
https://bugzilla.mozilla.org/show_bug.cgi?id=912470#c23

Big5 to Unicode (decoder) 的部份因為 Gecko 目前的實作無法把 HKSCS 字對應到正確的 Plane 2 (Ext-A Ext-B 區)，所以有一些技術細節要討論。這邊我也不懂 Gecko 的實作所以就幫不上忙了。

重新讀了一遍，我覺得我們的進展不錯
1. 沒人認為應該要作雙向對稱的 decoder / encoder

2. encoder 的部份大家也同意不要產生別人無法處理的 byte

所以對於 decoder 這邊大家的共識是？我重讀了一遍發現沒有不能採用 big5-hkscs mapping 作為唯一 decoder index 的具體理由。

在 bug 上的 Anne van Kesteren 是 WHATWG Encoding spec 的 owner，只要他的 spec 能夠完整 cover 當代的需求而且有實作的話，這有機會是我們最後一次在 Web 上煩惱 BUG5 問題 :) 可以試著這次好好說清楚。

2013/10/19 WitchFive <s79...@gmail.com>

這兩天發現的，看來 tw 消失會發生的比想像的快

--
您已訂閱「Google 網上論壇」的「moztw-general: 摩茲將軍」群組，因此我們特別傳送這封郵件通知您。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 moztw-genera...@googlegroups.com。
如要在此群組張貼留言，請傳送電子郵件至 moztw-...@googlegroups.com。

如要在網路上查看這項討論，請造訪 https://groups.google.com/d/msgid/moztw-general/d7a991ef-70df-4b03-8fce-5f04637d97b1%40googlegroups.com。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[Witch Five]

您好：

這邊有一個問題是 Henri Sivonen 寫的英文我看不懂，這超過我能理解的英文程度 @@a

誰來翻譯一下 XD

--
請多多指教 ^_^ Ψ Witch - Five Ψ

[koa...@gmail.com]

有關 encoder 的處理，有些看不明白的地方，希望請教一下。

如果 encoder 完全避免輸出 HKSCS 的 byte，是否意味當我在 big5-hkscs 網站表單使用 hkscs 的香港字時，送出到伺服器的文字會變成 ucs2 代碼（像「&#123456;」）？

timdream於 2014年1月3日星期五UTC+8下午12時52分17秒寫道：

[Thinker Li]

會影嚮到我的 blog XD

[buga...@gmail.com]

Le vendredi 3 janvier 2014 12:52:17 UTC+8, timdream a écrit :

報告報告，Bug 912470 目前的進度是要確定 Unicode to big5 (encoder) 的部份，spec 無誤且適合實作。

http://encoding.spec.whatwg.org/#big5-encoder
我看了說明，沒有看實際的 index 跟數學，不過 Note 有提到避免產生 HKSCS 的 byte，所以應該沒有問題了？

我回的留言在這邊如果有錯的話還煩請去糾正一下
https://bugzilla.mozilla.org/show_bug.cgi?id=912470#c23

Big5 to Unicode (decoder) 的部份因為 Gecko 目前的實作無法把 HKSCS 字對應到正確的 Plane 2 (Ext-A Ext-B 區)，所以有一些技術細節要討論。這邊我也不懂 Gecko 的實作所以就幫不上忙了。

重新讀了一遍，我覺得我們的進展不錯
1. 沒人認為應該要作雙向對稱的 decoder / encoder

2. encoder 的部份大家也同意不要產生別人無法處理的 byte

所以對於 decoder 這邊大家的共識是？我重讀了一遍發現沒有不能採用 big5-hkscs mapping 作為唯一 decoder index 的具體理由。

就是UAO的問題吧，UAO和HKSCS各自是不同於彼此的cp950的superset，
UAO不是政府機構定義的，外國人可能不知道他的存在，但在台灣從某方面來說卻是事實標準。

個人覺得維持分開才對。

encoder的部份，最大只能取到UAO和HKSCS的交集吧，最小當然就cp950，超出兩者交集的話，那decoder就變另一個issue了。

都分開這麼多年了怎麼會忽然想要把他合起來咧? 大概還是因為低估了UAO的存在性吧，雖然這件事發生在web上的影響感覺起來並不大，不過我認真不希望Big5再有更多令人困惑的mapping了…

[Timothy Chien]

Buganini,

請問您有客觀事實（統計、範例網站 ...）去證明在 Web 上 UAO 的使用被低估了嗎？

直覺上我也怕這樣的問題，但是如果一直拿不出資料討論那就會再度落入你覺得我覺得的那種沒有交集的溝通。這種技術討論是不會有結果的。


2014/1/5 <buga...@gmail.com>:

> --
> 您已訂閱「Google 網上論壇」的「moztw-general: 摩茲將軍」群組，因此我們特別傳送這封郵件通知您。
> 如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到
> moztw-genera...@googlegroups.com。
> 如要在此群組張貼留言，請傳送電子郵件至 moztw-...@googlegroups.com。
> 如要在網路上查看這項討論，請造訪

> https://groups.google.com/d/msgid/moztw-general/94b14075-d69b-4850-899a-51a3f3fd03c8%40googlegroups.com。
> 如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[Timothy Chien]

Koalay,

你描述的行為應該會發生沒錯。
但是現在 Gecko 的 HKSCS 實作如果你輸入到 Ext-A 區的字的話，本來就會變成 ncr (&xxx;)。

這會是一個嚴重的問題嗎？如果有問題現在的 Gecko 實作就已經會造成問題了。

可以玩一下我當年做的測試網頁：
http://timc.idv.tw/encodetest/

2014/1/4 <koa...@gmail.com>

如要在網路上查看這項討論，請造訪 https://groups.google.com/d/msgid/moztw-general/df776c1b-357c-4673-9647-1bdbc9970e56%40googlegroups.com。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[Koala Yeung]

Tim︰

謝謝！剛剛試過，用 BIG5-HKSCS 編碼送出香港字，能夠正確變成相應的 bytecode
http://timc.idv.tw/encodetest/?text=%9F%5E%90%B2%95%E9%91a&encoding=Big5

如果我沒有理解錯，將來伺服器不再會收到 bytecode ，而是 UCS2 碼。

會出問題的地方，是一些要比對新舊表單輸入的狀況。最簡單的例子是站內搜尋。舊的輸入已經用 HKSCS 相容的 bytecode 存好，而當你在搜尋表單輸入某個 BIG5-HKSCS 定義的 bytecode 時，Firefox（新行為）將會用 UCS2 碼送出，當然不可能找到對應的 bytecode 中文詞語。

是我過慮嗎？


timdream於 2014年1月5日星期日UTC+8上午2時12分53秒寫道：

[Timothy Chien]

是，但是我在前一封信有問到，如果有問題的話目前的 Ext-A 字就會有問題了（測試的第七項）。因為 Gecko 的 HKSCS 2004 支援從來就沒有完成，輸入測試第七項的文字本來就會被轉成 ncr。

2014/1/5 Koala Yeung <koa...@gmail.com>

如要在網路上查看這項討論，請造訪 https://groups.google.com/d/msgid/moztw-general/c1577215-5c45-4775-9a36-371e29f4198d%40googlegroups.com。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[But Ko]

他的意思應該是BMP內的字轉換行為改變，不相容了？

例如表單搜尋BMP範圍內的hkscs文字（or 日文假名等等），將找不到資料庫裡以雙向 big5-hkscs 儲存的舊有資料。

btw, 這還真是永恆難解的問題

2014/1/5 Timothy Chien <timd...@gmail.com>

[Buganini]

或許我用錯詞了，不是低估，是無視。(不是氣話喔)

我手邊是沒有針對UAO的統計資料，短期內也沒心力去爬，不過如果有人願意寫好並host crawler的話，我可以出detector。

換個說法好了
http://w3techs.com/technologies/overview/character_encoding/all
http://w3techs.com/technologies/details/en-iso885914/all/all
ISO-8859-14跟ISO-8859-1只有31處不同，而且網頁使用率低於0.1%，那是否也可以令ISO-8859-14為ISO-8859-1的別名呢?

套句將太壽司的台詞「也許對你來說，這只是你捏出千萬壽司中的一個，但對客人來說，這壽司就代表你的一切」
對非使用者來說，客觀事實或許就是全域統計資料，但對真的用到的人來說，完全不是那麼一回事啊

我還想多問一句，清理legacy charset/encoding的目的是什麼?
如果是為了清理code，那我無解，
如果是為了簡化UI或Spec，那我覺得畫面上可以只看到一個Big5，但底下會去判斷實際上該用big5
family裡的哪一個，這才是最能顯示正確資料的作法，畢竟大多數Big5 user也不知道自己用的是哪一種。

2014/1/5 Timothy Chien <timd...@gmail.com>:

[Ming Tsay]

同意只顯示 big5 背後才判斷的這種感覺

Xperia™から

如要在網路上查看這項討論，請造訪 https://groups.google.com/d/msgid/moztw-general/CAC_-zwds-SYtCe5%2BQG8OtaT6Sc7a6dMvDs7YV3KuQNgb6PqOAw%40mail.gmail.com。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。

[abelc...@gmail.com]

題外話，這個截圖和編碼無關，那是 Google 誤判 IP 地址和實際地區的關係。以前曾試過在數據中心內開啟 Google 網頁，卻出了阿拉伯文版本給我哩。

Abel

[abelc...@gmail.com]

On Monday, January 6, 2014 12:19:11 AM UTC+8, Buganini wrote:

ISO-8859-14跟ISO-8859-1只有31處不同，而且網頁使用率低於0.1%，那是否也可以令ISO-8859-14為ISO-8859-1的別名呢?

這情況恐怕和 big5 類似，就是很少人將網頁 charset 定義為 ISO-8859-14，大家都是直接寫 8859-1 就算 (還未計 windows-1252)。於是爛字爛碼就一堆的跑出來了。

我還想多問一句，清理legacy charset/encoding的目的是什麼? 
如果是為了清理code，那我無解，
如果是為了簡化UI或Spec，那我覺得畫面上可以只看到一個Big5，但底下會去判斷實際上該用big5
family裡的哪一個，這才是最能顯示正確資料的作法，畢竟大多數Big5 user也不知道自己用的是哪一種。 

剛才比較了一下 UAO 和 HKSCS 2004，其中 4586 個使用相同的 big5 造字碼位，但對應到不同的 Unicode 字元。接下來的問題是：要如何判斷？

Abel

 

[Koala Yeung]

應該是無解的，聽說最簡潔的做法是用 big5-cp950，可以說是 defacto standard

找到 W3C 一個比較 big5-hkscs 與及 big5-uao 的頁面︰
http://www.w3.org/html/ig/zh/wiki/Big5-hkscs-vs-uao-in-hk
一些衝突的字，在香港還是蠻常用的（畢竟就是有需要才造字）

比如 96F5 的「埗」字，是其中一個全香港人口最密集的區域「深水埗」的一個字
換成 UAO 就變成「」，換成「深水&#22487;」就對應不到資料庫的舊資料
找個地方都找不到

又比如 8FC0 的「衞」字，「衛生署」變成 UAO 就是「缳生署」
換成「衞生署」同樣有問題……

4586 個重覆字中，恐怕有很多類似問題


abelc...@gmail.com於 2014年1月6日星期一UTC+8上午11時07分55秒寫道：

[Buganini]

我之前在 https://github.com/buganini/chiconv 的作法是
(score-ierr*10)/count 高者勝

ierr是解碼錯誤的次數
count是指解出來的字數
score是累計分數
score table目前很簡單:
https://github.com/buganini/bsdconv/blob/master/codecs/inter/SCORE.c#L83
依照Unicode區塊就可以簡單區分出罕用字，依據不同的使用頻率給予不同的分數。

這樣目前用起來，雖然沒有很長的時間，是沒有出錯過。

針對UAO/HKSCS的話，可以讓詞條有額外的bonus，像「錫堃」「陶喆」「水埗」「衞生」
應該不需要太大的詞庫就可以區分出包含Big5e等各種Big5 variants。

2014/1/6 <abelc...@gmail.com>:

[buga...@gmail.com]

這是說encoder的問題吧?
encoder不應該送出cp950以外的東西了，畢竟送出去之後有可能還會經過其他的decoder，像MySQL本身有在做轉碼的動作，不是直接存進去而已。

送NCR是能保存最多資訊的方式，至於搜尋就無解了。