當然，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 が使われてる 日本語板
只是我覺得還是之前的部分更經典XD
(最後修正 2011/10/26)
1
最好騙的總是自己。
2
抄來的程式碼是bug之母。
3
輕易刪掉的程式碼，往往在之後都需要用到。
4
電不會騙你，測試資料有錯時，都是人錯了。
5
交貨日是為了打破而存在的。
(譯註) 漫畫、作家業名句「截稿日是為了打破而存在的」，出處已不可考。
6
程式碼如其人。
7
發問是一時之恥，不問是一生之蟲。
8
「/* 刪掉下面這行不知道為什麼就會當掉 */」是永遠不滅的。
9
覺得「這是什麼沒可讀性的爛程式！」時，常常是自己以前寫出來的程式碼。
10
「誰說程式設計師就一定熟電腦的」
11
使用手冊是需要的人不會讀它，而不需要的人會去讀的神祕讀物。
12
無論有多奇怪，只要符合規格就是滿分。
無論如何完美，只要不符合規格就是零分。
13
我前方沒有規格，bug在我身後形成。
(譯註) 高村光太郎《道程》的名句 ─ 我前方沒有道路，路在我身後形成。
14
所謂的專業，並不是努力於辦不到的工作，
而是在事前能夠判斷出工作辦不到。
15
把勞基法當作是別國的法律就對了。
16
當你有「啊，加上這功能吧」的念頭時，還是不要想太多，早點去睡結果會比較好。
17
狀況總在週末來臨。
18
「責任」不是該負的人要負的，而是要負的人被逼著負的。
19
看到別家公司寫的程式碼，就知道客戶有多麼被看不起，然後自己得到了勇氣。
20
老闆是bug。
21
程式設計師的價值決定在寫了多少程式碼，
程式設計師的技能決定在讀了多少程式碼。
22
熟悉程式語言不表示就會寫軟體。
23
熟悉程式語言後，軟體會寫得更慢。
24
機器感受到你的著急，所以他壞了。
25
程式設計師就算有愛，也不能愛上程式設計，
因為程式有讓人墮入地獄的力量。
26
程式設計師重視過程，客戶重視結果，所以永遠是兩條平行線。
27
為了解決問題而最初想出來的點子，通常都有一些問題。
28
發現問題如何解決不是最重要的，發現哪裡是問題比較重要。
29
除錯，是喚醒沉睡錯誤的儀式。
30
測試後如果沒找到任何bug，一定是測試有出錯。
31
就像SE所說的「辦得到」往往不可信，PG說的「辦不到」也不可信。
32
如果bug十年都沒人發現，就不要理他。
去解掉它的話，不出半年就會被人當作bug了。
33
想個好的變數名稱比想演算法還花時間。
34
要在水面上行走、要照規格開發軟體都很簡單。如果能固定不動的話。
35
別相信手冊！相信我！
36
還沒付錢的，不是客戶。 已經付清的，也不是客戶。
37
不知道自己在修什麼的維修員。
38
try-catch 然後 return null。～推卸責任～
39
客戶的抱怨去認真聽（約兩小時左右）就對了。
這樣一來客戶的問題就可以說是解決一半了。
也就是程式就不用改了。
40
bug 是不會看臉色的。
41
昨天的自己是今天的敵人。
42
SE的沉默代表著進度順暢的安心，
PG的沉默代表著進度空白的悲鳴。
43
業務的幸福是技術者的不幸。
44
接受「口頭規格」的開發案，就好像開一張空白支票給別人一樣。
45
這不叫更改規格。
因為打從一開始就沒有規格存在。
46
程式這檔事，總是會有「難以置信」的事情發生。
47
程式設計師這種人，總是會寫出「難以置信」的程式碼。
48
而「難以置信」的程式碼，不知道為什麼常常跑得很好。
49
要證明 bug 不是自己的責任，往往比修好這個 bug 更花時間。
50
bug 是會怕生的。
兩個人在一起明明很大方的，更多人來看時就躲起來了。
51
程式的養分來自於程式設計師的鮮血。
52
不知道為什麼不會動的東西，OS程式設計師會在下一版讓他動。
不知道為什麼不會動的東西，開源程式設計師會在下一版捨棄它。
不知道為什麼不會動的東西，週日程式設計師會嘗試在下一版讓它動，結果膩了而放置。
53
當程式的原始碼規模超過臨界點，就會離開程式設計師的手，擁有自己的意志。
54
直接看程式碼，比看英文的註解好懂多了。
55
要求「功能要有彈性」的客戶，往往思考都沒有彈性。
56
程式的字典裡沒有「不可能」，但程式設計師有。
57
沒被發現的 bug，就不是 bug！
fin.
悲哀啊！
只能一直寫著這些悲觀格言，是台灣程式設計師的現實。
就鐵道興趣來說，我對軌道、工程、車輛、線型、實地探勘…方面其實都興趣缺缺，比較有興趣的就是路線圖、時刻表、站名牌、驛舍的部份。
之前畫了一大堆路線圖外，其實幾年前自己也在嘗試做一些時刻表的東西，只是資料正確性之類的問題很難搞，一直無疾而終。不過反而被日本同好搞出來了XD（我手上還有幾本，
有人有興趣嗎XD）
對於站名牌我也一直很有興趣，尤其是 JR 跟東京地下鐵，近年站名牌越做越精緻後，看到設計美觀的站名牌，心情也會愉悅起來。反過頭來看到台鐵的站名牌，嗯…….。
不過最近促使我有強烈動力想要做這個產生器的，其實不是台灣或日本的鐵路，而是韓國。韓國 KORAIL 甚至自己設計了一套專用的字型來標識所有站內外站名與站內標示，凡是 KORAIL 站內，包括「出口」「售票處」「詢問處」等所有標示都整齊劃一使用這套專用字型（而且我個人覺得這套韓文很漂亮），而且不只 KTX 大站，沿途經過的小站也都做好了，使人深感佩服。 先別說台鐵，就連JR 東日本的駅名標字型也是個混亂，在都內以為漸漸都轉換成新ゴ了，結果一離開東京都，乍看都是黑體的駅名標，隨便就找到「見出ゴ MB31」「見出ゴ」「平成角ゴ」「平成角ゴW7」「JTC ウィンS」「新ゴB」幾種不同字型的產物。
好啦，前言講到這裡，產生器網站在這邊。
目前還在測試公開階段，已經支援 10 種風格的站名牌風格：
- 台灣：台北捷運、高雄捷運、台鐵 (舊)、台灣高鐵
- 日本：JR 東日本、JR 東海、東京地下鐵
- 韓國：KORAIL
- 大陸：上海地鐵、北京地鐵
本來還想要支援港鐵的，不過香港地鐵站名似乎貼在牆上為主，還找不到頭緒怎麼製作。
為了測試與運用上的方便，除了產生站名牌功能之外，已經內建 500 多站包括北捷、高捷、高鐵、台鐵西部幹線、JR山手線、JR中央線快速、香港地鐵荃灣線、上海地鐵2號線等多個城市的不同車站資訊。方便快速地實驗製作出來的站名牌結果。
但要聲明的是，這只是「風格」，不是「正確」的站名牌。
畢竟車站百百款，像有些站同一邊有兩個以上不同的鄰站，有的車站是 switch-back 前後站都在同一個方向。甚至 JR 東日本會因為直通運轉，綠線另外一邊畫成其他顏色的情況。像這些問題，都不在本產生器想處理的範圍內。
JR 東日本會針對特別區間加上 山、區 之類的標識，為了避免車站資料庫要收集的資訊太多，也決定不收這個部份。所以產生器做出來的站名牌基本上就是風格上的模擬，而沒有打算以產生符合車站現實實情的站名牌為目標，請務必理解這一點。
還有些過長的英文站名，實務上鐵路公司通常採取換行的方式處理避免太長，也是因為程式難以判斷哪裏斷行比較好看的問題，基本上產生器都不會換行，只能一直橫向擴張，所以會產生出滿寬的站名牌（無解）。今後打算支援的西日本一些風格，會有平假名站名標在漢字上的情形，大概也是無解，就現行資料規格而言，要把假名分別正確標在每個漢字上方，是有困難的。
也就是說，我很希望能獲得版面風格相關的意見（對齊位置、顏色、字型等）。但對於特定車站的站名牌與實情不一致的問題（同邊有兩個以上的鄰站、英文站名要換行、….），抱歉這些問題實在不打算解決，不在產生器的預設系統範圍之內。
另外，內建的車站資訊，尤其是日韓文的翻譯部分，也是純屬參考。畢竟台灣多數鐵路單位都沒有官方的日、韓文譯名（北捷有日文版導覽圖，站名有翻譯日文但也沒有標日文讀音），所以幾乎都是我擅自憑個人獨斷去翻出來的。日文翻譯充滿了個人惡趣味（很直覺地想念就怎麼翻，例如いたばし）；韓文則是除了車站、國小、國中等幾個名詞意譯外，其他全部音譯，但查證了幾個韓文網友做的北捷、高捷路線圖的讀音標識，音譯的習慣也眾多紛紜，所以到頭來還是有自己的武斷在裡面。由於這些翻譯問題永遠辯證不出個結論，除非能舉出官方版本的車站翻譯，不然我也不打算改。還請見諒。
不過說了這麼多，由於這個系統最主要的部分還是站名牌的繪圖部份而不是車站資訊，我希望我能將自己時間花在支援更多風格的站名牌上，而不是在整理車站資料這邊，還是希望有熱血提供車站資訊（站名、翻譯、里程….）的朋友可以跟我聯絡（rail[at]but.tw）。
只是可能會由我提供車站資料格式要怎麼建檔後，希望是由您來整理好給我，大家都把各種路線格式不同的資料一股腦丟給我，我實在沒時間整理，這會排擠掉支援其他新風格的工作時間，還請見諒。
目前打算支援的其他風格：
- 台灣：台鐵 (新)
- 日本：國鐵傳統樣式、阪急電鐵、阪神電鐵、近鐵、名古屋地下鐵、JR 其他四社、路面電車!?
- 韓國：首爾地下鐵
- 亞洲以外的其他城市 (!?)
目前評估過而放棄支援的風格：
- 福岡地下鐵：福岡地下鐵站名牌風格很有趣，每個車站都有一個代表圖騰，但也是因為每站需要設計圖騰的問題，根本無解
- 台鐵木板站名牌：純毛筆手寫的站名牌，實在不是電腦可以產生的
- 阿里山鐵道：重點在海拔資訊…. 缺這個值做出來也沒有 fu
果然記帳軟體真的是手持裝置的殺手應用，說真的很多消費回到家根本就忘光了。
一問之下，發生身邊 Android 玩家的好友們幾乎都是用 financisto 來記帳，這套軟體似乎真的評價不錯 — 除了他是英文的以外…
話說上個禮拜還在寫一些報表程式統計自己的記帳，一邊心裡想著好想把自己寫的進階報表加進 financisto 裡，結果當天晚上， financisot 作者忽然在 blog 上宣布開放原始碼化了!
既然如此，當來二話不說來把自己的報表寫進去啊， 想是這樣想啦，最近個人極度的沒時間，而且還沒完全看懂程式架構中，目前不敢輕舉妄動，但至少決定把念願的中文化先弄出來了。
financisto 的簡單介紹
其實我不是原作者，好像不用特別在這裡叫賣，不過既然都釋出了，就隨手介紹一下這套記帳軟體吧。
financisto 支援多類型帳戶（現金、信用卡、…等）、多幣別，並隨時統計各帳戶與所有帳戶資產總額。
幣別是跟著帳戶的，一個帳戶不能混兩種幣別。平常記帳時只要選對帳戶，不用太在意幣別問題。
您可以使用交易、移轉按鈕輸入新明細 (按鈕在明細頁面下方)，也可以直接在之前輸入的明細上長按，直接複製一份到現在，或是將該像明細存進模板，之後可快速直接加入明細。
還可以設定定期明細(menu鍵)，程式會自動在時間到時加入交易或移轉，並以鈴聲、震動、LED等方式通知使用者。
還能將新增交易、新增移轉的按鈕捷徑直接放到手機桌面上(功能在設定選項頁面)。 作者真的很用心地提供各種週全的加入明細方式。
軟體操作界面非常乾淨舒服，沒有雜亂的按鈕，功能清清楚楚。時刻可以自由調整過去與未來，支援樹狀分類（可惜目前無法調動順序）。
還可以記錄消費地點 (我個人是沒用這個功能，在設定選項裡可以關掉地點功能)，
並有專案功能，可將消費記錄加入專案(project)裡。 例如可為每次旅行建立一個新專案，除了統計分類裡原有的食衣住行各項開支外，還可以統計專案本身總開支。
另外軟體還有預算功能，可規劃各分類(或專案)在期間內的限額。
並且還有一些簡易的報告功能，可追蹤期間(如當日、當週、當月、上月)消費，以及各分類、各專案消費等。
所有記帳資料可使用 csv 檔形式匯出，可在電腦以 excel 開啟自行另外做更多分析。
中文化版本
除了這裡釋出的版本外，我會將這中文化版本回饋給原作者。但不知道原作者會不會把中文化版本納入官方版本。
您可以選擇安裝這個版本，若不放心，也可以等等看原作者XD
安裝這個版本請先看過下面安裝注意事項：
中文化版本注意事項
- 由於軟體簽章不同，若您本來就是 financisto 使用者，您必須解安裝掉原程式，才能安裝這個版本。
- 解安裝程式之前，請先從 (menu) -> more -> Backup Database 備份資料庫。
- 備份完後解安裝程式，重新安裝這版本後，再選擇匯入資料庫。
- 若您是這個程式的新使用者，這個中文化的版本會自動先在貨幣裡加入新台幣。若您是匯入舊資料庫，可能不會產生這筆資料。
- 實測發現匯入舊資料庫的使用者也許會看到「無分類」等少數字串還是原來的「No category」，但安裝幾次後又變回中文了，我也不知道為什麼，還懶得仔細研究….
- 總之請在您自己的責任下安裝本版本，我不對此版本安裝後對您的資料、手機造成的任何問題負責。
雖然還想去自己加很多功能，不過短期(我想是半年內)大概是沒可能有時間了…. 先這樣吧。
update 2010.6.10
由於官方版本 1.3.7 已將正體中文版加入，所以我這裡的版本就停止發表了:)
請直接從 Market 下載!
今天終於把一些bug清掉了。
沒想到之前一堆不可解的bug竟然是counter造成的… 真是阿彌陀佛。
今天調整的內容：
- 修掉開關羅馬拼音就會掛的問題
- 修掉回上一步更改拼音後就會掛的問題
- 修掉Firefox等瀏覽器ruby支援顯示不夠好看的問題
- 新增友善列印功能
並感謝CHCOOBOO網友的回饋。
請大家多多推介:)
]]>