作者 but (????！) 看板 SOS
標題 關於對 Unicode 補完計畫的指教與批評
時間 Sat Oct 08 20:02:15 2005
───────────────────────────────────────
首先先自我介紹
我是 Unicode 補完計畫的始作俑者
這東西是在 2001 年末弄出來的
最近的版本我參與比較少
不過大致的技術內容還是理解的
首先要道歉的是
Unicode 補完計畫這個名稱似乎取得不太好
或許叫做 Big5 補完計畫比較切合事實
事實上這東西曾經叫做 Big5 Extension
不過這名字實在太容易跟偉大中推會提的 Big5e 混淆
回到正題 首先這篇文章要對一些常見的誤解作釐清
(1) Unicode 補完計畫沒有動到 Unicode 字表
我無法理解 Unicode 補完計畫是哪裡破壞了 Unicode
Unicode 補完計畫修改的是 Big-5
(2) 日文假名是 Big5 標準
目前行政院列為標準的 Big5-2003 裡
平假名跟片假名是列為標準的
使用到假名的 Big5 文件是標準的
不標準的是微軟的 Big5-CP950
(3) Windows NT 下檔案系統「通常」是 Unicode
Windows NT 下，檔名「理論上」是 Unicode 的
所以沒有所謂的 ANSI 檔名或 Unicode 檔名
本軟體所附的「日文檔名修改程式」
用途是將日文假名與簡體字從造字轉換成真正的 Unicode 碼
（轉換前會是 Unicode 的造字區域）
也就是說轉換會是更正確的 Unicode
但本來沒有使用櫻花、font.24或中國海命名過檔案的人不需要轉換
但是，上面說的是通則
事實上這問題有點複雜
NTFS 是完全 Unicode 的，這點沒有問題
但 FAT32 其實每個檔案都會以 Unicode 與 ANSI 各存一份檔名！
這是因為長檔名支援造成的問題 本來 FAT 並不支援長檔名
所以檔名區域只有 8.3 的長度 這部分是存 ANSI
後來 Windows 為了支援長檔名才加了另一個 Unicode 部分
但是 Windows 處理 FAT32 的方式很複雜
當檔名長度短於 8.3 的時候 也就是沒有用到長檔名的時候
會直接以 ANSI 版的為準！
所以， FAT32 下檔名符合 8.3 時，檔名會是 ANSI
（這是會???問題的原因 很不幸的他剛好 8 bytes
而 1.5 版的 Unicode 補完計畫是把簡體字單向對應到繁體字）
總之，Unicode 補完計畫在 WinNT 下對檔案系統通常沒有影響
即使解安裝檔名仍會繼續存在
只是 ANSI 軟體可能會無法開啟檔名有非 Big5 字元的檔案
少數比較可能會有問題的情況就是 FAT32 下的 8.3 檔名
(4) Unicode 計畫到底收了哪些字？
前面有人提到 Unicode 補完計畫使用的造字區還是不夠存 sjis 的漢字
這是錯誤指控
事實上， Unicode 補完計畫已經收錄了 GB2312 與 SJIS 裡所有漢字
還收錄了 Big5-2003 裡定義的部首與偏旁等文字
誰需要用 Unicode 補完計畫？
Unicode 補完計畫是個用來解決現存 ANSI 軟體無法處理常用外字的工具。
就如前面有人講過的，在有些不同的領域下，可能有更好的方案。
例如，如果你根本不用 ANSI 環境的軟體，就不需要用他。
如果你願意放棄 Winamp 而改用 Foobar，
如果你願意放棄 Nero 改用 Windows XP 那個常燒壞片的功能，
如果你願意放棄打 BBS …
那很幸運的，您不需要安裝 Unicode 補完計畫。
如果你發現你用 Unicode 補完計畫真的只因為 BBS 而已，
那您也可以考慮改用 Pietty 。
我自己其實很樂見 Pietty 願意這樣設計:)
把 Unicode 補完計畫的架構縮小到應用程式的規模，
或是設計成 AppLocale 式的轉接架構這種計畫，
在 Unicode 補完計畫論壇裡去年我有提起過，
只是一直不了了之，這次 Pietty 的改版我挺驚豔的^^;
如果你同時只處理一種字碼，
例如想要用 Nero 燒日文檔名時，
那 AppLocale 或是切換系統語系就可以幫上你的忙。
如果你偏偏想要在同一張光碟裡燒 Big5 與 SJIS 特有的字，
那很不幸的，切到中文或切到日文大概 Nero 都沒辦法同時燒這兩個檔案。
這時候你還是需要 Unicode 補完計畫。
如果你跟我一樣，就是常常會用到很多 ANSI 軟體，
例如愛用 Media Player Classic、
愛用 VirtualDub …
那很不幸的，安裝 Unicode 補完計畫後使用起來可能會比較方便一點。
事實上， Unicode 補完計畫現在遭受最大的批評在於 WWW 環境。
像 MSN 之類的 Unicode 環境，
Unicode 補完計畫並不會造成任何影響，
所以沒有什麼問題。
以 BBS 這類 ANSI 環境來說，
確實要安裝 Unicode 補完計畫才能看到 Unicode 補完計畫使用者打的外字，
但似乎也沒有更好的解法，基本上我挺滿意這種狀況。
但問題在於 WWW，這是一個比較複雜的環境。
繁體中文的網頁大概仍然有九成以上是 Big5 的，
這似乎是一個 ANSI 環境。
然而，WWW 卻又支援了 &#xxxx; 這種稱為實體參照的 Unicode 表示法。
我個人覺得這種解法其實跟 Unicode 補完計畫一樣，並不怎麼高明，
他也只是一個在 ANSI 環境的頁面裡插入 Unicode 字元的 hack 而已，
而且還挺佔空間！ (一個漢字就要吃 8 個 bytes!)
不幸的是，安裝 Unicode 補完計畫以後，確實會有送出的外字字元，
不會自動被轉成實體參照的問題。
關於這個問題，我們建議使用這些方式解決…
1) 使用本軟體附的「HTML文件相容轉換器」
btw, 實際上每次都要轉換實在太麻煩了…
2) 使用本身內建標準 Big5 或 Cp950 的瀏覽器
是的，這是在宣傳 FireFox 😛
當你用了 Firefox 之後，雖然整個系統是 Unicode 補完計畫字碼，
但瀏覽器環境下會是 Big5-2003 環境！
這是多麼的美好！
(ps. 不過 Firefox 採用正確的 Big5-2003，所以日文假名有列入 Big5 裡。)
雜談
(1) Unicode 時代什麼時候才會來臨？
前面有些版友指摘 Unicode 補完計畫反而阻礙 Unicode 的發展。
關於這點我在這裡不予置評，我想討論的是 ANSI 包袱為什麼丟不掉。
事實上，以 Windows 這個平台而言，
雖然 Windows NT 改以 Unicode 為核心了，
但是支援 Unicode 的開發環境實在不成熟！
以微軟自己的開發工具而言，VB 的控制項、VC++ 的 MFC 精靈等等，
大部分內部的程式碼還是使用 ANSI 的 Windows API。
一個程式要完全使用 Unicode 處理，必須全程呼叫 Unicode 的 API。
然而目前這些開發工具根本沒有對 Unicode 開發提供足夠的支援。
而 Borland 的 BCB 與 Delphi 對 Unicode 的支援更差，
連資源都是以 ANSI 的格式儲存的…
君不見大部分的共享軟體還是以 ANSI 開發的。
以 Unicode 開發的門檻真的很高，
而且對軟體的最大產地歐美地區而言，ANSI 還是有極高的人氣。
事實是，除了微軟與Adobe的部分軟體以外，
大部分軟體仍然是 ANSI 的。
再說，目前還是有很多標準是 ANSI 的。
例如 zip 檔案的規格就是 ANSI。
或許很多人討厭 Winamp 使用 Big5 儲存 id3v2 tag 而改用 Foobar，
但事實上市面上所販賣的 MP3 隨身聽，
大部分都是將 id3v2 tag 視為 Big5 讀取的。
Foobar 的 UTF-8 tag 反而在 MP3 隨身聽內常常無法顯示。
目前整個大環境，都還不足夠讓 Unicode 能夠普及。
(2) Nero 的情況
Nero 所燒出來的檔名預設是 Unicode 的（UDF 或 ISO9660 with joliet）
這是檔案系統規格， Nero 也遵守規格燒出 Unicode 的檔名。
所以，安裝有 Unicode 補完計畫所燒出來的 CD，
無論給日文語系的使用者或是沒有安裝 Unicode 補完計畫的使用者，
都能夠正常讀取。
然而， Nero 在讀取硬碟裡的檔案時，使用的是 ANSI 的 API。
所以，檔名存在有非 Big5 字元的時候， Nero 會無法讀取這個檔案。
(3) Unicode 補完計畫的文件不足
是 我們深知這個問題
但人手實在是不夠
歡迎對技術足夠理解 願意寫作的朋友加入
—
From 忘記思考的Number 5
—
[1;32m※ Origin: [33m土匪．山寨 [37m<bbs.techarea.org / poorman.twbbs.org> [m
[1;31m◆ From: [36m220-135-30-136.HINET-IP.hinet.net [m
