『～』和『∼』...

[Tetralet]

實在太辛苦您囉∼∼

[Tetralet]

在將 LC_ALL 設定為 zh_TW.UTF-8 的情況下，
gcin 能正確輸出 UTF-8 的『～』並不為奇；
因為它的輸入法對應表本來就是以 UTF-8 編碼的。

我只是很好奇的是，
在未將 LC_ALL 設定為 zh_TW.UTF-8 的情況下，
gcin 似乎會呼叫 g_locale_from_utf8 進行 utf8 -> big5 的轉換，
然後系統又似乎會依據 LC_CTYPE 來將 gcin 所輸出的 Big5 文字又轉換回 UTF-8 編碼。


首先，系統是從何得知，gcin 所輸出的是 Big5 碼呢？

而系統又是依據什麼規則，
將『～』(U+FF5E) 轉成錯誤的『∼』(U+223C) 呢？

[Tetralet]

對了，忘了說，
我大略得看了一下 zh-autoconvert 的原始碼，
zh-autoconvert 用的是自行建立的字碼轉換表，
所以基本上和 glibc 無關。

[Edward G.J. Lee]

在將 LC_ALL 設定為 zh_TW.UTF-8 的情況下，
gcin 能正確輸出 UTF-8 的『～』並不為奇；
因為它的輸入法對應表本來就是以 UTF-8 編碼的。

我只是很好奇的是，
在未將 LC_ALL 設定為 zh_TW.UTF-8 的情況下，
gcin 似乎會呼叫 g_locale_from_utf8 進行 utf8 -> big5 的轉換，
然後系統又似乎會依據 LC_CTYPE 來將 gcin 所輸出的 Big5 文字又轉換回 UTF-8 編碼。


首先，系統是從何得知，gcin 所輸出的是 Big5 碼呢？

而系統又是依據什麼規則，
將『～』(U+FF5E) 轉成錯誤的『∼』(U+223C) 呢？

這個可能要請教一下作者。我記得原來的規劃，全形字有一些是沒有包括的（因為少用），後來才加進去。

gcin 在沒能正確進入 utf8 的情形下，我猜可能一些後來加入的全形字就無法配對，就會交給 gtk2/pango 去處理這個字符。這方面我就不熟悉了。

[zero0w]

轉錄果正大哥在 BBS 上說的：

代碼: 選擇全部

 作者  Edward (L.G.J.)                                      站內  Edward     
 標題  Re: BIG5(CP950) vs. BIG5-HKSCS                                         
 時間  Thu Nov  4 00:47:52 2004                                               
───────────────────────────────────────

※ 引述《Edward (L.G.J.)》之銘言：
> ps.請參考：
> http://moto.debian.org.tw/viewtopic.php?t=4744
> 的討論，據我所知 mozilla 就有可能把其中一些 BIG5 的字弄成是 BIG5-HKSCS
> 的對應。大概要看原 post 看是在什麼清況下造成的。基本上 glibc 的表格
> 應該是正確的（但應該是說正確的 CP950）。

  答案揭曉。原來是使用于廣輝的 autoconvert 轉的。

  Big5 的部份是 foka 在修正的，so...

  請大家愛用 iconv 來轉檔，因為他是根據 glibc 的表格，而 glibc
  的表格就是小虫和居士合作生產的啦！:)

--
※ Origin: SayYA 資訊站 <bbs.sayya.org>
◆ From: 218-169-141-240.dynamic.hinet.net

 文章選讀  (y)回應 (=\[]<>-+;'`jk)相關主題 (/?)搜尋標題 (aA)搜尋作者 (T)解碼


Mozilla 自從 1.6 版起，已把 Big5 和 Big5-HKSCS 的編碼方式區分開來，這個問題仍存在嗎？