當然，BBS 系統幾乎都不是 Unicode 環境，只支援 Big5。（要轉換成 UTF-8 的話，2 bytes 的雙色字要怎麼處理會變成棘手的問題。）
身為次文化集中地的BBS，自古以來就大量討論著同是次文化的動漫畫、JPOP等話題，於是BBS用戶也一直想盡辦法使用各種造字檔方式（例如櫻花輸入法）來解決假名顯示的問題。（而假名是使用Big5-Eten規格）
其中我所搞出的「Unicode補完計画」，在2001年推出了。
當年，Unicode 架構的 Windows XP 開始普及，也同時衍生了很多問題。
首先，不知道為什麼 Arial Unicode MS 在 Unicode PUA（造字區）裡塞了一堆很像泰文的字，偏偏優先性又比使用者造字來得高，所以有些造字檔的假名被忽略，顯示成莫名其妙的符號（像是「お」），使得Big5下的日文變得有點難閱讀。
其次，Unicode 裡本來就包括假名。例如日文網站上使用的假名，姑且稱它為「真假名」。而要看到 BBS 上的日文，則需要使用造字檔的假名，通常稱作「Big5假名」。但這其實非常難懂，「明明都是假名怎麼複製貼上會變亂碼！」「明明都是假名怎麼需要使用不同輸入法！」，對於非專業的電腦使用者來，這太複雜了。
而在 Unicode 架構的 Windows XP 下，系統字型的新細明體就包含漂亮的真假名文字，而那些造字檔的假名其實滿醜的。
於是我不知道哪根筋不對，忽然想到那為什麼不乾脆直接把 Big5 假名對應到 Unicode 的真假名碼位上呢？ 於是就開始改造 Windows XP 的系統轉碼表，這就是「Unicode補完計画 1.0」。就是在納莉颱風那一天，外面雨太大，待在宿舍一天搞出來的。
公開以後，意外地馬上大紅。
總之在 BBS 上實在太方便了。本來造字檔模式的假名，雖然可以閱讀，但輸入時要用不同輸入法，從日文網站複製貼上時也會亂碼。每次都要慢慢用轉換軟體轉過才能貼，或是只好自己重新每個字打出來。但把「真假名」與「Big5假名」統一起來以後，假名可以直接複製貼上了，輸入可以直接用 MS-IME 了，好處太多了。
在 BBS 之外，當年所流行的 MP3 播放軟體 Winamp、CD 燒入軟體 NERO 等等，都還沒支援 Unicode，碰到真日文的檔名，不能播放、不能燒錄，安裝Unicode補完計画後能解決很多問題。
一個月後，我又公開了「Unicode補完計画1.5」。這是「漢字單向對應」的版本，例如本來 Big5 的對應上，Unicode 的「来」字並不存在於 Big5，所以對應到「?」，而我把它改成對應到「來」。也就是說把 Unicode 的「来」跟「來」都對應到 Big5 的「來」（Unicode相容漢字顛倒的作法？）。我想字碼專家大概都會幹翻這種對應方式，但為什麼我要做出這種東西，到頭來還是為了方便剪下貼上。
1.0 雖然解決了假名剪貼的問題，但日本的漢字想當然耳還是會亂碼。為了支援「来」這些漢字，理論上只能創造新的 Big5 外字集。當時，我猶豫半天的結論是，還是不要再定義新的文字碼位比較好。這樣做才不會產生新的 Big5 變種，對於資訊的交換比較不會造成影響（畢竟假名的部分至少還是根據 Big5-Eten 標準）。結果只好把日文漢字硬是對應到繁体字上，做出了這個詭異的轉換表。
大約一年後，軟體中文化聯盟的 witch 與我聯絡，說是用了跟我一樣的方法，把整個「中國海字集」所有文字的對應表給做出來了。
「中國海字集」也是個從 DOS 時代（倚天中文系統）開始就廣為使用的外字集，不只包括日文漢字，還包含了中國簡化字、各種圖案文字等等，是非常豊富的外字集，直到 Windows 95 流行後，推出的 TrueType 版本造字檔同樣廣為流傳。（但大約在2000年前後公司解散，著作權關係也模糊不清了。）
而在BBS上，愛用中國海字集的人也不少（對於沒安裝的人來說看到的都是一片空白就是了）。
而 witch 所想的也一樣，隨著 Unicode 環境的普及，同樣一個字有真正文字與造字兩個版本，這樣很糟糕。於是自己卯起來把中國海字集乾脆整個對應出來了。
而中文化聯盟的 KiiAli 與 witch 把這個對應表命名為 Big5-Extension，以中文化聯盟的名義推出。（因為它也包含 Big5-Eten 的假名，所以Unicode補完計画反而變它的子集合了。）
雖然我對於製造新的擴充字碼有點排斥，但也覺得有兩種惡搞 Big5 的對應表到處流通更是一種混亂，更重要的是其實我也是中國海字集的忠實用戶，於是討論後的結果，兩個專案決定就此合併。這就是「Unicode補完計画 2.10」的誕生。而自此它正式成為一支 Big5 的變種，也意外出現了「Big5-UAO」這聽起來有點炫(?)的編碼名稱。
為了維持與中國海字集的相容性，與 Unicode 之間的對應關係反而有點複雜。打個比方，「浅」這個字在日文有三條橫筆，在中國只有兩條，但在 Unicode 裡是統合的對象，定義在同一個字碼。但中國海字集裡這是兩個字（中國海字集歷史比 Unicode 早很多啊）。為了盡可能相容於中國海字集的字碼定義，只好把這兩個字都定義到同一個字上，於是會有一些字重複定義的問題。另一方面，Unicode 所沒有的文字（例如中國海字集裡有大量的圖案文字）就只好含淚割捨。於是多少空下來一些碼位散落在各處可以使用。
當「不製作擴充編碼」這條道德的薄膜(?)破裂後，穿出的是人無窮的野心。反正已經不用考慮沒安裝的人不相容的問題了，那任何一個缺字都顯得非常礙眼。例如中國海字集中並沒有區分的「戶」「户」「戸」，在 Unicode 區分了，這下子日文的「戸」字複製貼上時就亂碼了。於是就決定找個空間把「户」「戸」塞進去好了，這一來就 2.20、2.30、… 這樣不斷地快速一連串地改版。
在最新的 2.50 版，已經支援了 ShiftJIS 所有漢字、GB2312 所有漢字、甚至當年 HKSCS-2001 在 BMP 範圍內的所有漢字。另外，為了方便複製貼上 2ch 的文章，乾脆把半形假名，以及顏文字常用的數學符號跟半濁點 (ﾟ∀ﾟ) 之類全都加進去了，幾乎把 Big5 的 PUA 範圍全都塞滿到極限了。
所以光看 Big5-UAO 定義表的話，會有「順序定義亂七八糟，拉丁文字、符號跟漢字竟然混排在一起」的錯愕感，真正的原因在於「一切始於中國海字集」。想要支援的文字太多，但又要維持與中國海字集的相容性，只好盡可能找出還能用的所有空碼位，把一堆文字硬塞進去，顧不得表格的體系整齊了。
到這裡，Big5-UAO 的版本發展就結束了。
這時，Firefox 開始流行了。
本來，例如 IE 瀏覽器，使用的就是 Windows 的字碼表，如果使用者裝了 Unicode補完計画，那 IE 的對應關係也會是 Big5-UAO。這有好處也有壞處。在 Windows XP 時代，極大多數的網站仍然是 Big5 碼，使用了 Big5 假名。沒有安裝造字檔的話，就看不到這些 Big5 假名。Unicode補完計画使用者能直接看到這些 Big5 假名，這點很方便。但同時在留言、貼文的時候，自己打的文字也會被以 Big5-UAO 字碼貼出去，造成讓這些變種字碼擴散的問題。（沒有安裝Unicode補完計画的人，造字會被轉成 ＆＃xxx； 的 entity ref，所以文字流通性比較好。這也是Unicode補完計画所承受的主要罵名之一）
而 Firefox 不管 Windows 的對應表，自己包裝了獨立的 Big5 字碼表。也就是說不管使用者有沒有安裝Unicode補完計画，Firefox 的 Big5 處理行為是一致的。這也是有好處有壞處。好處是變種編碼不會到處擴散，但壞處是也完全無法閱讀這些變種編碼的網頁了。而最該死的是 Firefox 1.5 所包裝的 Big5 表格竟然是台灣那唯一的官方表：Big5-2003。為什麼說它該死呢，因為根本沒人用。官方直到 2003 年才搞出這標準，Windows 之類的軟體根本沒打算支援它。Big5-2003 包含了假名而不包括日文漢字，所以雖然說是不會造成 Big5-UAO 外字的擴散，但仍然會造成Big5假名的擴散，結果還是半斤八兩。
這時跳出來的是 pietty 的作者 piaip。 piaip 可說是對 Big5-UAO 帶來巨大影響的一個人。在這個階段其實我已經不太直接經手 Big5-UAO 了，所以主要的工作是 witch 在做的。 piaip 與 witch 合作，向 Mozilla 提出了一個相當有趣的對應表。那就是Unicode補完計画 1.5 也曾玩過的「單向對應」。只是這次方向相反，是讓 Big5 的 Big5-UAO 文字對應到真正的 Unicode 文字，而 Unicode→Big5 的方向採用 Big5-CP950（也就是 Windows 標準）。這樣一來，Big5 網頁上的 Big5-UAO 外字會被當作 Big5-UAO 解讀，讓使用者可以閱讀；而使用者自己留言、發文的文字則被當作 Big5-CP950 轉換成 ＆＃xxx；的 entity ref。看得到外字但不製造它。我想這解決方案真是太棒了，無懈可擊，找不到什麼缺點。這張表後來被正式採用，正式編入 Firefox 2.0 的 Big5 標準。
piaip 的功績不只是這個對應表，更重要的則是 pietty。 pietty 是知名 telnet 客戶端程式 putty 的 piaip 版本，這個軟體在軟體層級上支援了 Big5-UAO。也就是說不需要去惡搞 Windows 的 Big5 表格了，只要以 pietty 登入 BBS 的話，自然而然就能看到 Big5-UAO 的文字。在這個時期，Winamp 與 NERO 之類的軟體也都陸陸續續支援 Unicode 架構，除了 BBS 以外，其他軟體還需要使用 Big5-UAO 文字的機會少很多了。藉由 pietty 的出現，使用者可以不用安裝Unicode補完計画，只在 BBS 環境內使用 Big5-UAO 編碼了。完美。
以 pietty 為濫觴，接下來 PCMAN 等各種 BBS 軟體接踵開始支援 Big5-UAO，現在支援 Big5-UAO 可說是 BBS 軟體的共通標準了。事實上，像是 Android 下的 LunaTerm 與 MoPTT，以及 iOS 的 Nally 等等，這些智慧型手機OS下的 BBS 軟體，幾乎也都把支援 Big5-UAO 放在第一要務。
而現在最大（或許該說是唯一）的 BBS「PTT」，它本家的 Web 版網站，也是使用 Big5-UAO 標準把 Big5 轉換成 UTF-8 顯示的。
同時Unicode補完計画身為軟體的使命已經消失，官網也關閉不再開放下載了（雖然在軟體王之類的網站還持續被流通），但 Big5-UAO 這套文字編碼持續一直被使用著。
最近，聽說 Mozilla 也受不了 Big5 有這麼多變種，想要開始整合一些沒在用的編碼了。而其中 piaip 他們提出的這個單向 Big5-UAO 也是被檢討的對象之一，甚至有極端的意見想要把 Big5 整合到只留下 Big5-HKSCS 一支。實際上我調查了一下，相較於十幾年前，現在幾乎所有網站都 UTF-8 化了，其實在 Web 環境下，真的沒剩下多少 Big5-UAO 資料了。但在 BBS 的世界上，反而幾乎無法脫離 Big5-UAO，就好像是個平行世界狀態。也就是說，如果從 Firefox 拿掉 Big5-UAO，事實上影響可能真的是輕微的。但身為台灣人來說，Big5 的預設竟然搞成 Big5-HKSCS 的話，還是太哀傷了。
想到這裡，於是我把我知道的 Big5-UAO 歷史，在這裡全部寫了下來。
其實 Big5-UAO 甚至有被收錄在 Perl、Ruby 等程式語言的標準編碼集裡面，但一直都沒有清楚的中文以外的文獻，所以海外討論編碼的社群，往往不知道 Big5-UAO 的存在，或是知道它但完全搞不清楚這是什麼鬼東西。
所以我以中文、還有我比較熟悉的日文寫下了這些經過，希望讓台灣以外的人士，也能藉此了解一些 Big5-UAO 的來歷與使用情形。（有人願意幫我翻成英文嗎XD）
參考資料：
- 本文日文版
- Big5 變種列表（含對應表）（含Big5-UAO）
- Mozilla 版本字碼表討論經過
- telnet 軟體 Pietty
- 最大的 BBS 站 PTT 與大量使用 Big5-UAO 的 日文板
- 目前 Mozilla 對於 Big 變種整理的討論
もちろん、ＢＢＳシステムのほとんどはUnicodeなど対応できず、Big5しか対応していない。（UTF-8などに変換しようとしても、たとえば２バイト文字をANSIカラーにした２色漢字はどう対処するかわからない。）
サブカルチャーの集まりともあるＢＢＳには、同じサブカルチャーの漫画・アニメ・ＪＰＯＰなどのテーマもよく討論されており、そのため古くからＢＢＳユーザなどは外字集などの方式でとりあえず仮名を拡張していた。（仮名はBig5-Eten準拠）
その中、私が発案した「Unicode補完計画」というプロジェクトは、2001年から提供開始。
当時、UnicodeベースのWindows XPが普及し始め、いくつかの問題が次々と出てきた。
まずは、なぜか Arial Unicode MS の Unicode PUA にタイ語っぽいグリフがあり、外字集より優先なので、いくつかの仮名外字が無視され、意味不明の文字に表示されてしまい（「お」など）、日本語が読めにくくなっていた。
次に、Unicode にはちゃんと仮名文字がある。たとえば日本語ホームページなどの仮名はこういう「本物仮名」。一方、ＢＢＳなどを使うときに必要なのは外字集かなで、いわゆる「Big5仮名」。「同じ仮名なのになぜコピペして化けるんだ！」とか「同じ仮名なのに何で違うＩＭＥが必要だ！」とか、これは相当ややこしく、専門外のパソコンユーザにとっては分かりにくかった。
なお、Unicode ベースの Windows XP では、中国語システムフォントのMingLiuなどでもにはちゃんど綺麗な仮名が作ってある。一方外字集の仮名は醜かった。
そこで私が考えたのが、直接Big5の仮名文字などをUnicodeの正確なかな文字にマッピングさせること（Windows XPのマッピングテーブルをいじる形で）、それは「Unicode補完計画 1.0」だった。実は台風の日に出かけることができなく、一日で作り上げたものだった。
公開して、意外と大ヒット。
とくにＢＢＳでは大変便利だった。本来の外字集は、読むことがそんなに難しくなかったものの、入力は別ＩＭＥになったり、日本語ホームページからのコピペができず（化ける）、いちいち変換ソフトにかけるとか、入力し直しとかしかできなかった。「本物仮名」と「Big5仮名」を統一したところで、仮名のコピペなどが可能となり、入力もMS-IMEが使えるなど、メリットが多かった。
ＢＢＳ以外も、当時まだ流行っていたMP3プレイヤーWinampやCD-R記録ソフトNEROなどがまだUnicodeに対応しておらず、日本語ファイル名の再生や記録に支障が多く、これである程度楽になった。
約１ヵ月後、さらに「Unicode補完計画1.5」を公開した。これは「片方向漢字対応」というもので、たとえば本来Big5のマッピングファイルでは、Unicodeの「来」がBig5にないので「?」にマップしましたが、これを「來」にマップされたものです。つまりUnicodeの「来」も「來」もBig5の「來」にマップさせました（Unicode互換漢字の逆パタン？）。おそらく文字コード専門家はこういうマップが大嫌いだろうと思うが、なぜこんいう変なものを作ったというと、「コピペが便利だから」だった。
1.0 は仮名のコピペができたものの、やっぱり漢字は相変わらず化ける。「来」のような漢字を対応するには、拡張文字セットを作るしかない。当時、私が悩んだ末、Big5の拡張セットを作らないほうがいいという結論をした。こうするほうが新しいBig5の亜種が増えず、情報の流通に支障が少なくて済むという判断だった。あえて繁体字にマッピングさせ、変なテーブルを作り上げた。
１年後、ソフトソフトの中国語パッチを活動している中文化連盟の witch 氏から連絡があり、私の同じやり方で、「中国海字集」のすべての文字をマッピングしたテーブルを作ったという話だった。
「中国海字集」というのは、DOS時代（倚天中文系統）に絶大の人気のある外字集で、日本語漢字のみならず、中国簡体字からいろんな絵文字まで、豊富な外字集で、Windows 95になっても中国海字集の TrueType バージョン外字ファイルもかなり流通されていた。（しかし2000年前後会社が解散し、著作権関係があやふやとなった。）
そしてやはりＢＢＳなどでは、中国海字集を使う人も多かった（インストールしていない人にとっては文字化けだらけだが）。
witch氏が考えたのは、Unicodeの環境が普及と伴い、同じ文字が本物の文字と外字の二通りがあってまずいことだった。勢いで中国海字集をできるだけ実現したマッピングファイルを作り上げた。
中文化連盟の KiiAli 氏と witch 氏がこれを Big5-Extension に名づけ、中文化連盟から提供することになった。（Big5-Etenの仮名も含まれているので、これでUnicode補完計画がそのサブセットになった。）
新しい拡張セットを作ることは抵抗があるものの、２種のBig5テーブルパッチが流通されていることはまずいとの判断と、何より私自身も中国海字集の愛用者だったということで、お互い話した末、２つのプロジェクトを合流することを決意した。これは「Unicode補完計画 2.10」の誕生だった。そして正式にBig5の亜種となり、「Big5-UAO」という偉そうな(?)名前も付けた。
中国海字集との互換性を維持することにあたって、Unicodeとの不整合がいくつかあった。たとえば「浅」、日本語の横線３本の文字と中国の２本の文字はUnicodeでは包摂の対象であり、同じ文字ポイントだ。しかし中国海字集では２文字だった。できるかぎり中国海字集の文字コードをそのままキープするのが大原則なので、２文字とも１文字にマッピングする必要がある。そのため重複登録がいくつかある。一方、Unicodeにない文字（たとえば中国海字集の大量の絵文字）は泣き泣きあきらめるしかない。ゆえに少しながらあっちこっち使われていないコードもあった。
「拡張セットを作らない」という道徳の線(?)が切れたら、人の野心がむきだすもの。もうインストールしてない人との互換性を考えなくてもよくなった以上、ひとつでも欠ける文字があれば目障りになる。たとえば、中国海字集では包摂させていた「戶」「户」「戸」は、やっぱり日本語の「戸」がコピペされたら化ける。そこで「户」「戸」二文字追加決定。これで2.20、2.30、…のようにかなり早いスピードで更新してきた。
最新の 2.50 では、ShiftJISの全漢字・GB2312の全漢字、さらに当時のHKSCS-2001のBMP範囲内の漢字がすべて追加され、さらに2chのコピペに便利という理由で、半角カナや、顔文字などで多用の数学記号や半濁点 (ﾟ∀ﾟ) なども全部追加され、Big5のPUA範囲をギリギリまで使いきるようになった。
そのため「文字セットを読む限り、整列順が分かりにくい、ラテン文字や記号と漢字が混ぜて並べられている」という批判があってもおかしくない。「初に中国海字集ありき」が本当の原因だ。対応したい文字が大量あるものの、中国海字集との互換性を守るため、残りわずかの空白スペースを探し出し、不作為に埋めていくしかできなかった。
これで Big5-UAO の更新が終了した。
一方、Firefox が流行りはじめた。
本来、IE などでは、Windows のマッピングテーブルを参照していたため、Unicode補完計画をインストールしているユーザなら、IEのテーブルも Big5-UAO だった。これはメリットとデメリット両方あった。Windows XP の時代、大量のホームページはまだ Big5 コードで作られて、仮名もBig5仮名のままだった。外字集を入れてない限り、こういうBig5仮名のあるページは読めなかった。Unicode補完計画ユーザはこういうBig5仮名も読めるから便利な一方、書き込みするときに、やはりBig5-UAOコードで投稿され、規格外の文字が増え続ける悪影響もある。（インストールしていない人は、外字が＆＃xxx；の実体参照に変換するため流通しやすい。Unicode補完計画に対する批判はほとんどこの理由）
Firefox は Windows のマッピングテーブルを参照しなく、独自の Big5 テーブルを持っている。つまりUnicode補完計画がインストールしていても、Firefox の挙動が変わらない。これもメリットとメリットがあって、外字が増えないことがいいが、外字がどうしても読めないのがちょっと残念。そして一番厄介なのは、Firefox 1.5 の Big5 テーブルは台湾の唯一の公的テーブル：Big5-2003 だった。なぜ厄介だというと、使われていないから。2003 年にやっと制定され、Windows などは対応するそうにない。Big5-2003 には仮名があるものの、日本の漢字がない。Big5-UAOの外字が増えないのがメリットのようなが、やはり仮名はBig5仮名のままに投稿されるので結局同じだ。
ここで動いたのは Mozilla 開発活動に熱心の piaip 氏だった。 piaip 氏は Big5-UAO に莫大な影響をもたらした人である。この段階ではもう私は Big5-UAO に直接手をかけてなくなったので、主な活動は witch 氏がやっていた。 piaip と witch 氏の提携によって、また面白いプランを Mozilla に提案した。それは、Unicode補完計画 1.5 でおなじみのある「片方向マッピング」だった。こっちは逆方向で、Big5 の Big5-UAO 文字を本物の Unicode コードにマッピングさせ、一方 Unicode→Big5 のマッピングを Big5-CP950（つまり Windows 準拠）にした。これで、 Big5 ホームページなどの Big5-UAO 外字は Big5-UAO として解釈され普通に読める一方、投稿した文字は Big5-CP950 として変換され ＆＃xxx；の実体参照に。外字が読めて作らない。これ以上いいアイデアがないとも言いたいぐらい。このマッピング方式がすぐ認められ正式に Firefox 2.0 からのデフォルトとなった。
piaip 氏の功績は、このテーブルのみならず、もっとも重要なのは pietty だ。 pietty というのは有名 telnet ソフト putty の piaip バージョンで、このソフトは、ソフトレベルで Big5-UAO を対応することになった。つまり Windows の Big5 テーブルをいじることなく、 pietty で BBS にログインしたら、Big5-UAO の文字が読めて使えること。この時期、Winamp や NERO などのソフトも次々と Unicode 準拠となり、BBS 以外に Big5-UAO 文字を使わなくても支障がないという状態となっていた。 pietty の登場によって、Unicode補完計画というＯＳハッカーのようなものをインストールせずに BBS にだけ Big5-UAO を使うことができるようになった。すばらしい。
pietty をはじめ、PCMAN などの BBS 専用リーダーソフトも次々と Big5-UAO に対応するし、いまや Big5-UAO 対応するのが BBS ソフトの最低条件と言っても過言ではない。実際、Android の LunaTerm や MoPTT、そして iOS の Nally など、スマホの BBS ソフトは最初から Big5-UAO に対応してるものが多いようだ。
そして今一番人気のある（というか唯一の）BBS「PTT」も、UTF-8 の Web バージョンでは、Big5-UAO 準拠で Big5 と Unicode のマッピングしている。
同時にUnicode補完計画のソフトウエアとしての役割が終わって、ホームページも閉まり、公開されなくなっている（フリーソフトサイトなどで流通されているが）。 Big5-UAO という文字コードだけが使われ続いている。
最近、さすがに Mozilla 側も Big5 の亜種の多さに憤慨し、使われていないものを減らすことを検討しているようだ。そのなか piaip らが作った片方向 Big5-UAO も検討の対象とされ、Big5 を Big5-HKSCS 一本に統一したらどうだという案が人気だったようだ。実際調べてみたら、１０数年経って、ほとんどのホームページが UTF-8 に直され、Web 界隈では Big5-UAO のデータがかなり少なくなっている。一方、BBS の世界ではもう Big5-UAO なしでは使えないぐらい平行世界のような状態に化けている。ということは、Firefox から Big5-UAO がなくても影響が少ないとは言える。しかし台湾の人にとってはやっぱりデフォルトが Big5-HKSCS に差し替えられたら悲しい。
と思いつつ、私が知っている Big5-UAO の歴史全貌をここで書いてみた。
Big5-UAO は Perl や Ruby などのプログラミング言語の文字セットにも収録されている一方、特に中国語以外に資料が少なく、どういうものであるかなかなか海外に知られていないようだ。
そのためまず自分のできる日本語でなんとか書いてみました。台湾以外の人にも Big5-UAO の成り立ちや使用現状を理解していただけばと思います。
参考：
- Big5 の亜種リスト（マッピングデータなど、Big5-UAO含む）
- telnet ソフト Pietty
- 最大のBBSサイト PTT と Big5-UAO が使われてる 日本語板
我忽然覺得這話題滿有趣的。寫日文時動不動就會寫到「々」這個字，但是要用講的來說明這個字還真不容易，總是要繞個一大圈。沒有更簡單的溝通方式嗎？
々字怎麼念？
我們知道「人々」念成「ひとびと」、「時々」念成「ときどき」，有些比較難記，像「云々」念成「うんぬん」。那「々」字本身該怎麼念呢？
就結論而言，「々」並不是是漢字，而是個符號。符號並沒有讀音，但會有名稱。
那々字的名稱是？
但要討論起來「々」的名稱也不是這麼容易。隨便Google一下，「々」至少有這堆名稱：「繰り返し記号」「踊り字」「同の字点」「字送り」「ノマ（！）」…
從頭話起
「々」字的來源有兩種說法，最常聽到的看法是，這是「仝」字草寫的變形。
不過「仝」又是啥鬼？ 事實上這個字在台灣也很常見，這是「同」的異體字。一般報紙頭版登賀文，常常會看到「全體同仁仝賀」這樣的署名。日本像建築業至今也還習慣在見積書上，使用「仝上」這樣的寫法。
所以「々」有「同の字点」這個名稱。
另外一個說法是，這是「二の字点」的變形。
戰前的日文文章有區分「二の字点」與「々」兩者不同的用法，下圖的左方是「二の字点」，右方是「々」。「二の字点」用在訓讀的漢字，而「々」用在音讀的漢字。今日無論何者都是用「々」。也有人認為「々」字其實也是二の字点演變來的。
重複記號
說到漢字的重複記號，其實打從3000年前的商朝金文，就已經存在。下面這次一個青銅器上金文的照片，寫的是「子子孫孫」。但現今使用漢字的地區，正式文體裡有反覆記號的，只有日文。
各式各樣的用法
學過日文一段時間都知道，「々」的用法多半不外乎是「人々」這樣，用來重複前面一個漢字，頂多要注意一下是不是要念連濁罷了。真的這樣嗎？
・複複複線 → 複々々線（ふくふくふくせん） * 指鐵路的雙向各四線道
甚至還有看過「複々々々々線」這樣的用法（是說這是幾條軌道啊…）
也有人拿「々」用在成語的重複上。
・五分五分 → 五分々々（ごぶごぶ） * 這種用法就不是單純重複前面一個字了
有時候不是一個詞，而是兩個連在一起的詞，剛好碰到一樣的漢字連在一起，也用「々」省略的情形：
這種用法今日比較少用。但其他還有偶爾會看到的「○○会社々長」「民主々義」「公演会々場」等等，都是這種老舊寫法習慣的痕跡。
書寫與排版
今日因為普遍使用電腦變換輸入，通常不用太去在意「々」的問題。但手寫與鉛字排版的時候，要怎麼處理「々」也是個學問。
第一點，「々」是符號，不是漢字，出現在一行最前面並不理想。當用稿紙書寫文章的時候，例如「時々」剛好落在一行的最後面跟下一行的第一個字時，原則上就不使用「々」，兩邊都直接寫出「時」字。鉛字排版時亦同。但今日電腦排版由於比較容易自動調整間距避頭尾（禁則處理），多半不考慮這個問題。可以用Word實驗看看，連續輸入一堆「時々」，Word會調整不讓々出現在一行第一個字（實測結果發現文字語系要調日文才有效，語系是中文時，々是有可能會跑到一行前面）。
第二點是，用電腦輸入時，例如打「すみずみ」就會出現「隅々」，通常不必去管「々」的念法。但活字排版需要撿字，情況就不同了。撿字時為了同事間溝通需要，必須給個念法比較好溝通。所以在印刷業界有個「ノマ点」這個名稱。（因為他長相就是 ノ + マ）
打字怎麼直接打？
講了這麼多回到打字上。雖然平常並不需要在意「々」的念法。要真的只要打「々」字時，除了輸入「ひとびと」之類的，變換成「人々」後，再刪掉前面的「人」之外，有其他打法嗎？
因為是同の字点，MS-IME打「どう」或「おなじ」可以出得來。當然究極手段「きごう」也會有。雖然我個人覺得直接打「人々」再去刪其實還比較快…
有些版本的ATOK支援打「のま」就會出來。而Mac下，聽說「ことえり」這套輸入法則要打「じおくり」才會出來。
人名的命名
如果有看過我以前的認真文，應該會知道，從戰後起，日本對命名有比較嚴格的限制。只有平假名、片假名、常用漢字表與人名用漢字表內的漢字才可以作為命名用（戸籍法施行規則第60条）。但「々」是符號，這樣可以做人名用嗎？
事實上，昭和56年（1981年）9月14日法務省民事局長發出的行政命令，已經表明長音記號「ー」、假名重複記號「ゝ」「ゞ」、漢字重複記號「々」這四個符號，在合理的情況下也可以用在名字裡了。（所謂不合理的情況，是指不能用在姓或名的第一個字等等）。
聽說松嶋菜々子結婚前戶籍上的名字是松嶋奈奈子，可能是因為她出生於昭和56年之前。現在戶籍上的名字可以直接使用「々」了。
]]>
這個問題要從當用漢字表開始談起
戰後日本在國語審議會強勢進行一連串的漢字改革政策
先是公布了當用字體表
既然名稱是「當用」
表示它是個具有「限制」個性的漢字表
也就是帶有著「這個表以外的字都不該用」的意義在
當用漢字表 (昭和21年)
http://www.aozora.gr.jp/kanji_table/touyoukanji_hyou/table3.html
請注意這個表除了少數幾個有括號註明的字
大部分的字都還是原來的康熙字典體（繁體）
昭和24年 又頒布了當用漢字字體表
http://www.aozora.gr.jp/kanji_table/touyoukanji_jitaihyou/table2.html
此表大幅減化了文字筆畫 大致就是現在我們看到的日文漢字寫法
但要注意的問題是
這個表的最大原則是
只規定了這個表內的字要怎麼簡 並沒有去規定這個表以外的字要怎麼寫
（對岸的漢字簡化方案有所謂「可類推的簡化偏旁」）
結果就是，表外的字該怎麼寫，其實沒有統一原則
對國語審議會來說，表外的字根本不該用，管他去死，沒有該怎麼寫的問題
在這個階段，表外字的寫法算是無政府狀態
不過這也是個合理做法
打個比方來說：如果只因為 傳 簡寫成 伝、轉 寫成 転
也許這個規則在表內字全部適用，但要定義 專 簡成 云 可全部類推是有困難的
在表外罕用字裡，嫥、妘兩個自都存在，而且有不同意思，此類衝突問題並不容易發現
所以對未知的範圍不做定義確實比較保險
當用漢字表擴充成為常用漢字表，
常用漢字表新增的漢字，也依照當用漢字字體表推衍出新字體 (簡筆) 寫法。
雖然名稱改成常用後，字表的限制個性已經降低，
但常用漢字表仍然是一般電視以及報紙的用字準則。
另外因為命名的強烈需求，又制定了人名用漢字
人名用漢字部分也有收了一些與康熙字典體不同的字體
例如 亀、庄、遥 這些字，其實都並非常用漢字
但因為在人名用漢字裡規定了現在這個寫法
所以一般我們在說「表外字」的時候，其實也沒有把人名用漢字算進去。
大部分出版商跟報紙都使用康熙字典體去印表外字
但偏偏有人就是會想去簡。
最有名的是朝日新聞，
朝日新聞很積極地將表外字類推簡寫。
例如常用漢字表裡定義了 賣簡寫売、讀簡寫読，
但瀆是表外字，其他報章都是印瀆
就朝日新聞一家印成涜
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/2007-03-23.pdf
(此為07年朝日新聞宣布停用朝日字體的特集 *後述)
不只是報紙 包括朝日新聞社的字典等刊物也都是用朝日字體刊登
只有印刷就算了
隨著工業普及，JIS漢字讓問題更大條了
因為常用漢字表不到兩千字，許多地名用字（阪、栃、茨）都沒收
雖然可以做為一般人閱讀的基本能力標準
但並不符合實際印刷需求
所以JIS(日本工業標準)也制定了漢字表 (就是平常說的JIS第一水準跟JIS第二水準之類的)
JIS收了五六千字（比常用漢字多收了4000多字），
雖然表內字的字形基本上依照常用漢字表的規定，
但表外字部分卻收了很多類似朝日字體的類推字。
以及一些屬於簡體字的地名用字（如芦屋是表外字，本應做蘆屋）
像祈禱，因為「禱」是表外字，
按照表外字以康熙字典體書寫的原則的話
應該是 [ネ斤][示壽] 這樣才符合原則 (見下圖)
但明明都是示部的字，有的是 ネ 有的是 示 很混亂
又表內字的壽採用的是「寿」的字體
結果JIS漢字裡的禱就變成「ネ寿」了
但是要注意的是「祷」這個字形並不是內閣告示的字體表裡公佈的
這下問題就複雜化了
例如最有名的例子，「森鷗外」的鷗是表外字
課本跟出版業界都印 鷗 多，但JIS漢字收的卻是 鴎
結果學校老師用電腦打考卷只能打出鴎而打不出鷗
因為朝日字體跟JIS漢字造成的表外字字體混亂
國語審議會終於在2000年提出表外漢字字體表
正式對表外漢字該怎麼寫提出較官方的意見
http://www.mext.go.jp/b_menu/shingi/12/kokugo/toushin/001218c.htm#2 (表外漢字字體表)
這個表列舉了較常用1022個表外漢字
原則上都採用康熙字典體為印刷方式 (= 不簡化)
不過其中有22個字容許使用較簡的異體
好啦 寫到這裡才能說明為什麼我洋洋灑灑寫這麼多
很多類似的文字議題網站只會寫一句表外字要用康熙字典體
但其實「表外字要用康熙字典體」
在2000年之前 一直算是業界的多數默認而已
也就是 只是因為多數出版業者跟報章都採用康熙字典體而已
並不是哪裡這樣規定了
表外字該怎麼寫 根本沒有一個國家標準說誰才是對的
再說 也還有朝日新聞跟JIS在唱反調
而且JIS基本上是有些官方色彩的
就好像國字常用標準字體表是教育部標準、BIG5是內政部標準一樣
直到這個表外字字體表公佈以後
才能真正說 「根據政府標準」表外字要用康熙字典體
字體表有提到棘手的三部首問題
這三部首是 辶(辵)、礻(示)、飠(食)
這三個部首一直是漢字字形最難搞的部分
辶 傳統在字書上一直是以4筆計算
不過印刷體是兩個點下面直 楷書體則是一個點下面彎
不過當用漢字字體表基本上是以印刷體來討論 沒有著墨書寫體
而當用漢字字體表上印的是一個點
所以表內字的 辶 是一個點
但表外字依照康熙字典體的關係所以是兩個點
造成表內表外有一個點還是兩個點的差異
http://ja.wikipedia.org/wiki/%E3%83%81%E3%83%A3%E3%82%AF%E9%83%A8
示則是 ネ 示 的差異
食是下方為 ム 還是 匕 的差異
(岔題)
關於 當用漢字字體表基本上是以印刷體來討論 這點
事實上 當用漢字字體表有提示說手寫的文字不見得要太死
例如糸的下方是小還是三點都沒關係
但因為所有課本的字體都比照字體表印 老師也這樣教
仔細觀察的話 會發現很多日本人寫字都有印刷體特色
除了糸字無論在哪個位置都寫成小狀以外
還有像令字，手寫也寫成ㄗ狀的人似乎也不少
甚至亮、京這些字上面的點習慣寫成豎的人也很多
手寫體與印刷體越來越趨近
既然這個表都說話了
前面這些搗蛋鬼們也陸續決定面對現實了
JIS在2004年決定更改JIS漢字的例示字體，讓JIS字體跟表外字字體表一致
http://www.jisc.go.jp/newstopics/2005/040220kanjicode.pdf
(JIS X 0213:2004における例示字形の変更について)
朝日新聞也決定在2007年放棄朝日字體 除「辻」字以外一律使用表外字字體表
微軟也決定從Vista開始採用JIS X 0213:2004的新規格
所以メイリオ的漢字字形就會比照表外字字體表
感覺好像問題單純不少 但又帶來不少麻煩
例如雖然表外字字體表說明對三部首採開放態度
「原則上使用康熙字典體 但使用簡易寫法也沒關係」
但既然例示字體刊登的是康熙字典體
朝日新聞與Vista字形都把這表外字的三部首改為傳統寫法了
所以有WinXP的迂一個點，Vista的迂是兩個點的問題
碰上很在意的人就尷尬了
像有些姓裡有辻字的人就會在意是一個點還是兩個點
(插花)
日本在意名稱字寫法細節的人好像還挺多的
像很多姓裡有崎的人會堅持右上角是個立
吉野家會堅持自己的吉上面是個土
http://www.yoshinoya.com/ (吉野家網站 請注意用圖片處理的地方上面都是土)
東京葛飾區網站還用一大頁解釋下面不是匂而是寫成人在裡面
http://www.city.katsushika.lg.jp/aisatu/katsushikakunituite.html#katunoji
(JIS漢字舊版(如XP)是匂 新版JIS漢字(如Vista)已改為人在裡面)
終於原來的正題
微跟薇、寧跟檸寫法不同的原因就是這樣
因為微跟寧是表內字 薇跟檸是表外字
薇跟檸這兩個字倒是舊版JIS漢字就已經符合康熙字典體的case
所以不用vista的字形應該也可以看出差異
這類的例子還可以舉很多
* 因為JIS漢字表外字字體的問題 很多例子XP可能是長得一樣的 Vista之後的字型才正確
呼 不過問題還沒完喔
文化審議會又打算要來修訂常用漢字表啦
（* 本來的國語審議會已併入文化審議會）
預計明年(2010年)要再加個200字上下
http://www.asahi.com/national/update/0116/TKY200901160297.html
雖然詳細要加哪些字還在審議
就目前看到的草案
除了所有縣名用字如埼、阪、岡全部加入以外
計劃中還有幾個很棘手的字在裡面
像是「謎」 (*對 你沒看錯 謎現在其實不是常用漢字…)
因為謎是表外字 所以Vista的謎字已經在修正為兩個點了
但這下加入常用漢字到底該是一個點還是兩個點
委員們還在激烈討論中
這類字還滿多的
像是「填」字右邊要保留康熙字典體的眞還是改為真
「麵」的麥要保留康熙字典體的麥還是改成麦
「喻」的右下要是彎的ㄍ還是直的刂 上面是入還是互不出頭
….
保留表外字字體表寫法會造成常用漢字表內字體不統一
改成表內寫法又會讓這批JIS像Vista好不容易改好的文字
都還沒被民眾習慣 很多字又要大改一次
在這個資訊化的時代 怎麼做都不對 牽一髮動全身
不知道明年文化審議會提出什麼答案