跳转到内容

Unicode補完計畫

添加链接
本页使用了标题或全文手工转换
维基百科，自由的百科全书

这是本页的一个历史版本，由Kolyma​（留言 | 贡献）在2010年12月27日 (一) 04:53 （→外部連結）编辑。这可能和当前版本存在着巨大的差异。

Unicode補完計畫（Unicode-at-on，簡稱 UAO，官方網站使用的識別系統用字是Unicode補完計画）是台灣電腦使用者針對大五碼（Big-5）延伸的紊亂，以及微軟Code Page 950（Microsoft Windows內建的Big-5轉碼表）未收錄某些常用字（又稱缺字問題）以及缺乏對於倚天、中國海字集延伸中的簡體字、日文假名與漢字支援等問題，所採取的其中一種解決方案（參看大五碼#影響）。透過對Code Page 950的修改，使得原始採用簡體中文或日語的內容，在複製至ANSI架構的程式時能轉換為Unicode補完計畫字集下的對應字元，而不會造成缺字的問題（具體字元請參看字元的來源）。它是一個自由軟體。

要留意的是「Unicode補完計畫」不等於 Unicode。當你看見有人說「我安裝了Unicode」，通常是他把「Unicode補完計畫」和 Unicode 搞混了。

「Unicode補完計畫」也不是用來解決軟體顯示亂碼的問題。電腦內要有相關的字形（例如支援整個 Unicode 漢字的字形），才能在電腦顯示器看到。因為「Unicode補完計畫」只包含了編碼轉換表，並不包括字形在內。而一些日語遊戲裝在Windows XP所出現的亂碼問題，應使用Microsoft AppLocale內碼轉換器等程式去作內部轉換。

背景與原理

「Unicode補完計畫」的原理是把大五碼造字區的區位，和 Unicode 的相關字元作雙向對應，以達到無須借着外字集，也能使大五碼文件或檔名使用原先欠缺的漢字。

由於大五碼僅收錄13,060個漢字[1]，對不少使用者而言確實不足夠，例如日語假名、人名、香港粵語字、科學用的特殊字等等都欠奉。長久以來解決這種問題的方式都是加裝各種外字集，例如櫻花輸入法（支援日語假名）、中國海字集、香港增補字符集（HKSCS）等。但目前世界的潮流是以使用包含最多字數的 Unicode 為目標。以外字集收錄字符根本難以作為資料交換之用，除非對方也安裝了該外字集。

在預設狀態下，作業系統字碼表中，大五碼造字區是和「Unicode 造字區」作雙向對應的，也就是說當電腦讀取到某個原先是落在造字區的內碼時，電腦會去讀取與其相對應的Unicode造字區字元。結果是，由於不是每人電腦內的Unicode造字區都使用同一造字檔案，所以把外字集的用字傳送給其他人時，對方若無安裝相同的外字集，就不能看到裡面的內容。

「Unicode補完計畫」試圖以修改作業系統字碼表的方式以解決問題。它把大五碼造字區的字元對應到相關的Unicode編碼。與造字不同的是，「Unicode補完計畫」讓這些字元保持了雙向流通性。在補完後的電腦上，當這些字元從大五碼轉變到 Unicode 儲存後，它們全都會被對應到正確的Unicode位置上，之後即使是對於沒有安裝補完計畫的電腦使用者，只要他的系統和程式支援 Unicode ，在讀取這些文字時，就完全沒有問題。

作業平台

「Unicode補完計畫」修改作業系統中的字碼表，處理Unicode和非Unicode字碼的對應。「Unicode補完計畫」首先是在以 Unicode 架構為核心的微軟 Windows NT（包括 Windows 2000 和 Windows XP）作業系統上開發，之後又支援了以 ANSI 架構為核心的 Windows 98 和 Windows Me。

Linux也有另外的使用者，開發Linux版的補完計畫。

Palm上也有另外的使用者，開發對應的補完計畫：

Unicode架構的Windows

包括Windows 2000、Windows XP、Windows Server 2003，與未來的Windows系列。

修改的檔案：

  • $SYSDIR\C_950.nls Unicode←→Big-5對照表
  • 如果使用者有安裝Microsoft Applocale，安裝程式會將$WINDIR\AppPatch\AppLoc.tmp以一個同名的空白唯讀檔案取代。
  • 如果使用者沒有安裝Microsoft Applocale，安裝程式會直接產生一個空白的唯讀檔案：$WINDIR\AppPatch\AppLoc.tmp。

ANSI架構的Windows

包括Windows 98、Windows ME。

修改的檔案：

  • $SYSDIR\CP_950.nls IE（檔案總管）顯示時使用的轉碼表
  • $SYSDIR\unicode.bin 負責跟檔案系統操作相關的轉碼表（如果您有興趣可以這樣玩：把 $sysdir\unicode.bin 砍了，在重開機後，系統會使用最原始的預設 CodePage:437 顯示，在這情況下所有存在於檔名中的中文字都會以『__』顯示，這包括大部份的桌面捷徑和幾乎整個『開始』功能表）
  • $SYSDIR\GDI.exe 在顯示字型時，取得字型的檔案（將 CodePage 內碼依此檔內含之轉碼表轉換成 unicode 碼，再以此 unicode 碼到 TrueType 字型檔中提取字型）

註：$SYSDIR 是代表某路徑的一個變數，在 Windows XP 預設是 C:\WINDOWS\system32，在 Windows 2000 預設是 C:\WINNT\system32，在 Windows 98 和 Windows ME 預設是C:\WINDOWS\system。

$WINDIR 也是一個路徑變數，在 Windows 98、 Windows ME 和 Windows XP 預設是C:\WINDOWS，Windows 2000 預設是 C:\WINNT。

字元的來源

在「Unicode補完計畫」的第2版中，字元的基本來源是參照「中國海字集」，再加上中國海字集所遺漏的簡體中文、日語和部分香港用字而成。

「Unicode補完計畫」的 2.40 Alpha 3 版，除了大五碼原有的符號和漢字外，共收錄了 4,916 個漢字及漢字偏旁、日語的半形及全形假名、俄語西里爾字母等，涵蓋了在GB 2312（不是 GBK 或 GB 18030）、Shift JIS之中出現的所有漢字，和香港增補字符集之中，Unicode碼落在 U+4E00～U+9FA5 （即 Unicode 1.1版定義）的漢字。（因編碼空間不足的關係，並不收錄在香港增補字符集的 Unicode 擴充漢字）

使用上的問題

「Unicode補完計畫」原先的立意是避免利用造字，以達成擴充Big-5的目的：但由於Unicode環境尚未成熟，以及使用者的誤用，「Unicode補完計畫」有時反而為使用者本身──甚至其他使用者──帶來了其他的麻煩。

網頁交換

這是「Unicode補完計畫」使用者可能會影響到其他使用者的最大問題。

一般的網頁瀏覽器或電子郵件客戶端，在使用者打出了非該軟體顯示畫面預設編碼（例如寫一封用 Big-5 編碼的信件）的字元時，軟體會自動把這些字元轉換成Unicode 參照碼，例如「堃」會被自動轉換成「&#22531；」；然而在補完後的電腦，由於即使打出的是原非大五碼預設的字元，也會被認為是大五碼的字元（裝了「Unicode補完計畫」的系統，在對照字碼表後，發現當中有這個字），因此就不會被轉換了。這也就是說，其他使用者不一定能看見該使用者所打的字──除非他們也有裝「Unicode補完計畫」。於是這反而與「Unicode補完計畫」的創立宗旨背道而馳：原先避免以外字集解決缺字的「Unicode補完計畫」，反而變成了另一套外字集。

解決方案：當使用者安裝「Unicode補完計畫」時，會獲得一份「HTML外字相容轉換器」（另外也有網路版），可以直接把原本不屬於大五碼的字元轉換為參照碼；接下來只要使用這份夾雜着參照碼的文件，就能讓其他使用者也見到這些字元。另一種做法是，像推廣櫻花輸入法一樣推廣「Unicode補完計畫」，使其也變成一種人人使用的非官方標準。然而最終的解決方案是放棄Big-5，將網頁或信件直接改用Unicode編碼。[2]

新舊檔名

這是原櫻花輸入法使用者會面臨的問題。

在未安裝「Unicode補完計畫」的電腦，當使用者使用櫻花輸入法為檔案命名時，儲存在電腦內的檔名雖然是 Unicode 編碼，卻是在「Unicode造字區」內的字碼；而補完後的電腦，由於字碼表已被修改，這些檔案名稱在 Unicode 架構的程式的檢視下，就會變成空白；而對於 ANSI 架構的程式（例如 ACDSee、Winamp 等），甚至會變成無法存取的亂碼。這就表示甚至連 ANSI 架構的作業系統（例如整個 Windows 98）都無法存取該檔案。另外還有一個問題：若電腦是未安裝「Unicode補完計畫」的 ANSI 架構作業系統，以上的狀況就會剛好相反（以 Unicode 架構的作業系統則無此問題）。

解決方案：Unicode補完計畫內附一個檔名轉換程式，可以把造字區檔名和 Unicode 檔名互換，但僅能在 Unicode 架構的作業系統下使用；ANSI 架構作業系統的使用者必須要手動改檔名。另一個比較有效率的作法：如果是雙系統的使用者，可以直接在 Unicode 架構的作業系統下使用改檔名程式，讓 ANSI 架構的作業系統使用。

其他問題

  • Unicode補完計畫的編碼不相容於香港增補字符集的編碼，兩者只能擇其一。簡單來說，即使Unicode補完計畫與香港增補字符集均有某一個字，但因這個字在大五碼中的位置不相同，故那個字只能在 Unicode 的環境下交換，不能直接透過大五碼交換。
  • Unicode補完計畫會使用到使用者造字區；也就是說如果使用者有自造字，這些字可能會不見。
PS：如果使用者的自有造字放在 Unicode 補完計畫提供的「造字保留區：0xFA40～0xFA63」內的話，則不在此限。
  • 有人表示補完計畫會讓 Internet Explorer 的自動選擇網頁編碼準確度下降，但是無法證實。
  • 在安裝補完計畫後，Microsoft FrontPage 在處理 Big5 編碼網頁時會運作不正常（包括：存檔會當掉導致檔案大小歸零內容遺失），但是如果 FrontPage 是處理 Unicode 網頁，就能正常運作。
PS：這個問題只有在使用者的 Windows 其「非 Unicode 程式語系」是「正體中文」的情況下才會發生。
  • 對於不是使用系統字碼表的軟體──例如 Mozilla Firefox 等跨平台瀏覽器或 Java 軟體──補完計畫會無效，這些軟體需要「個別補完」（例如有些社群版的 Firefox，就有將補完後的字碼表編譯進去）。
  • Windows 98 的細明體字形 (mingliu.ttc) 比起 Windows Me / 2000 / XP 的版本來得舊。舊版字形有不少缺字情況；使用者必須在新版 Windows 中，複製細明體去更新 Windows 98 的字形檔案。
  • Windows 98 / Me 的使用者需要再安裝「中國海字集」，才能正常顯示純文字檔案。
  • 由於 Windows XP Service Pack 2 改進了系統檔案保護的能力，而補完計畫需要變更一個系統檔案，故當出現一個視窗，詢問是否要還原此系統檔案時，使用者必須選擇「不還原」此檔案，才能安裝成功。

不屬於Unicode補完計畫但內建其字碼表的軟體

  • PieTTY：SSH與Telnet客戶端程式。
  • OpenPCMan：Telnet客戶端程式。
  • Firefox 2.0版：網頁瀏覽器。（Big5→Unicode單向使用Unicode補完計畫字碼表。）[3][4]

參看

  1. ^ 大五碼普遍被認為包含13,053字，但在計算0xA259-0xA261的度量衡單位用字 (兙兛兞兝兡兣嗧瓩糎) ，再減去重收了兩次的「兀」(0xC94A)和「嗀」(0xDDFC)後，應為13,060字。
  2. ^ 註：但是在原本就只有ANSI的網路環境下──例如Telnet BBS──Unicode補完計畫還是只能當外字集用。此時使用者可以選擇有內建特殊字碼表的Telnet程式，如PieTTY，即無須安裝「Unicode補完計畫」。
  3. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=310299
  4. ^ http://moztw.org/docs/big5/

其他條目

參考文件

外部連結

检索自“https://zh.wikipedia.org/w/index.php?title=Unicode補完計畫&oldid=15278938”