各國郵遞區號格式：位數、字母與前導零的陷阱

郵遞區號格式是地址欄位裡最多變的一項：有的國家全是數字，有的把字母與數字混排，有的地方根本沒有這套制度，而最常見的意外是開頭的零在資料流中悄悄消失。這篇整理幾種主要寫法、說明前導零為什麼會不見，並給出讓欄位撐得住跨國情境的建議。

郵遞區號不是每個國家都有

郵遞區號是為了讓郵件分揀更快而發明的工具，因此有沒有這套制度、精細到什麼程度，取決於各國郵政體系的發展歷程。有的地方用一串號碼指向相當小的投遞範圍，有的只在部分城市使用，也有的從來沒有引入過。

對軟體團隊來說，直接的影響是兩個預設都不能用：不能預設郵遞區號一定有值，也不能預設它一定由數字組成。一個要服務多個國家的註冊表單，只要套上這兩個預設，就一定會有使用者被擋在門外。

把欄位設計成「跟著國家改變規則」比事後補救便宜得多，這也是國際化表單最基本的自我保護。

純數字與英數混合的兩種寫法

常見的寫法大致分成兩類。第一類是純數字，多位於四到六位之間，通常由大到小逐段縮小範圍。第二類是英數混合，字母與數字交錯，往往代表區域碼加上投遞點的分段結構，因此同一區域的號碼會共享前綴。

表格只是歸類，不是判準。真正要記住的是同一個國家內部也可能調整格式，所以驗證規則必須能被更新，而不是寫死在某一個版本裡。想把這件事做對，規則本身最好帶上生效日期與來源，日後回頭查才知道某條限制是根據什麼訂的。想看某個國家實際的寫法，可以從英國國家頁或日本國家頁這類頁面切入，對照當地地址的完整排列。

為什麼前導零會不見?

這是郵遞區號最經典的意外。當一串號碼被當成整數處理時，開頭的零會被視為沒有意義而消失，於是五位數變成四位數、四位數變成三位數，最後存進資料庫的值與使用者輸入的不一致。

問題通常不是出現在單一地方，而是散在整條資料流上：匯入試算表時的自動判型、程式語言裡的字串轉數字、報表工具的數值格式、甚至匯出檔案時的欄位設定。同一個錯誤可以在不同環節重複發生好幾次，而且因為結果看起來還是「像郵遞區號」，很容易通過人工目視檢查。

避免方式很單純：從輸入、儲存到顯示，全程當成文字處理，並且在介面上不要自動去除開頭的零。若必須支援比對，就另外保存一份正規化後的值，而不是覆蓋原始輸入。

沒有郵遞區號的國家要怎麼填?

實務上有兩種做法。第一種是把欄位設為選填，讓使用者在沒有這套制度時直接留空。第二種是當對方系統堅持要有值時，填入一個明顯的佔位符號，例如四個零，並在備註中說明原因。

第二種做法雖然常見，卻有副作用：它讓「有值」不再代表「真的有這套制度」，之後拿這份資料做統計或驗證就會得到錯誤結論。在本站的隨機地址產生器裡，遇到不使用郵遞區號的國家會直接標示該欄位不適用，而不是硬填一個看起來像真的號碼，這樣測試時才不會誤判。

郵遞區號可以拿來查地址嗎?

只能查到一個範圍，查不到一個門牌。郵遞區號的設計目的是分揀，它指向的是一批投遞點或一段街道，而不是某一戶人家。同一個號碼底下可能住著很多戶，反過來說，一個行政區也可能橫跨好幾個號碼。

因此把郵遞區號當成「地址是否存在」的判準並不成立。它能做的是交叉檢查：號碼是否落在該行政區的合理範圍內、是否符合該國允許的字元與長度。超出範圍值得懷疑，落在範圍內也只代表「看起來合理」，不代表真的可以投遞。這個差別的完整討論見地址驗證與正規化。

還有一點要分清楚：本站產生的號碼是為了測試而造的，只供測試，不能投遞。它符合該國允許的字元與長度，卻不對應任何真實的投遞點，因此不該出現在要寄出的郵件上，也不該被拿去證明某個人住在哪裡。比較合理的用法是把它餵進表單與資料庫，確認系統在各種格式下都不會出錯。若你真的需要知道某個號碼指向哪一段範圍，那已經超出測試資料能回答的範圍，得回頭查郵政單位發布的正式來源。

給開發者：郵遞區號欄位該怎麼設計

• 型別用文字，不要用整數，這是前導零遺失的根源。
• 長度上限放寬，並允許字母、數字與空白，因為英數混合的寫法確實存在。
• 必填與否依國家決定，不要讓整個表單共用同一條規則。
• 驗證規則集中在一處並且可更新，而不是散落在每個表單各寫一份。
• 顯示時保留使用者輸入的原始寫法，正規化只用於比對。
• 測試用的值只存在測試環境，不要讓它流進正式資料或寄件流程。

還有一個容易忽略的點：同一份資料要分清楚「使用者輸入的原始值」與「正規化後的比對值」。只留其中一種，之後就很難解釋為什麼兩筆看起來相同的號碼被系統判成不同。把欄位語意與顯示順序分開處理的做法，在國際地址格式裡有更詳細的說明。

下一步

要驗證自己寫的規則撐不撐得住各國格式，開本站的隨機地址產生器逐國產生地址，把值餵進表單跑一遍就能看出破口；若你的系統會保存郵遞區號，先確認型別是文字、前導零不會被吃掉。想理解地址欄位整體的跨國差異，接著讀同主題的國際地址格式說明，把欄位語意與顯示順序徹底分開。