作者: Tomex Ou
創作動機
有一天晚上寫了很多信件，上網查詢郵遞區號時，發現郵局網站有線上程式可查:
http://www.post.gov.tw/post/internet/f_searchzone/index.jsp?ID=190102網頁程式雖然方便，但界面上又要下拉，又要打字，效率不是很高，若能像譯點通查詢單字時，有流水式關鍵字列出，既能幫助記憶，又不用打精確字，方便許多。上網查了很多郵遞區號查詢程式，似乎沒有簡單又好用的離線程式，在發現台灣郵政官網有提供ZIP(3+2)的資料XML檔後，我決定自己來開發這樣的程式。用網頁AJAX技術來實作似乎不錯，但一想到流水式查詢的效能耗損，開發一個離線windows應用程式才是比較適當的方向。
程式說明
- 下載官方3+2郵遞區號XML資料庫(每季更新)，解開*.xml放在同目錄。
3+2郵遞區號資料XML檔(自解壓縮檔) 97/04 (約12MB) - 執行主程式，輸入查詢關鍵字即可，可以空白字元分開作交集查詢。
畫面擷圖:
流水式關鍵字查詢?
要使用流水式關鍵字查詢資料，查詢速度的效能問題是首要需去克服的。以台灣郵政的郵遞區號項目而言，有60,093筆資料，假如每打一個字就重新再從這六萬多筆資料中作模糊查詢，效能肯定不好，UI界面出現遲頓現象是必然的。首先，我們採用「非同步呼叫(AsyncCall)」來改善UI Delay的現象，接著針對資料筆數的效能去作調校。
我們發現，打N個關鍵字的資料待查詢筆數，是N-1個關鍵字的子集合，它是減少查詢筆數的關鍵，但這子集合記錄卻不能濫用，因為每當我們記錄子查詢集合的資料時，我們的程式記憶體使用量就會增加(回應時間vs.記憶體用量)。子集合資料的整體效益，會隨著查詢字數增加而遞減。
那麼，臨界點是幾個字呢? 這必須從使用者「查詢輸入習慣」及「資料特性」去作分析。以輸入習慣而言，居前面位置的關鍵字能有效減少筆數，宜作子集合，而後面輸入的字通常只是過濾筆數，回應速度比較優先。以資料特性而言，「台北」或「中山」等關鍵詞彙是台灣區域路名常使用的名詞，當出現這些關鍵字時，減少筆數是首要考量，所以我們可以建立一個優先詞庫，凡能大量減少筆數的名詞，就作子集合記錄動作。
以上是個人思路，若有更棒的想法，歡迎使用
本頁討論留言。
程式歷史
- 2008.05.05 v1.2 優化程式編譯方式，使Size縮減至1/10 (17KB)。
- 2008.04.30 v1.1 使用異步執行緒來執行UI更新動作，增加UI操作上的效能。
- 2008.04.22 v1.0 經過效能調校後，釋出第一版本。