国別郵便番号フォーマット：2026年正規表現リファレンス

米国は5桁またはZIP+4を使用するため、開発者は郵便番号を整数としてモデル化したくなります。しかしこのモデルは、文字がコードの一部であるカナダ、イギリス、オランダ、アイルランド、マルタ、アルゼンチンでは即座に破綻します。また、先頭ゼロが意味を持つドイツ、フランス、スペイン、イタリア、ポーランドでも、整数カラムがゼロを落としてしまうため、静かに破綻します。

2つ目のバグの種類は位置に起因します。ほとんどの西欧諸国は都市名の後に郵便番号を置きますが、ドイツ、フランス、オランダ、日本は都市名の前に置き、日本はコード全体を住所の先頭に置きます。フォームが固定テンプレートをレンダリングする場合、すべてのフィールドが埋まっていても、現地の読み手には明らかに間違っている住所が生成されてしまいます。

ヨーロッパの大半は固定長の数値コードを使用します。ドイツ、フランス、スペイン、イタリア、ギリシャ、トルコ、サウジアラビアは5桁、オーストリア、ベルギー、スイス、デンマーク、ノルウェー、ハンガリー、南アフリカは4桁、ポーランドとポルトガルはハイフンを追加し、スウェーデンは3桁、スペース、2桁です。チェコは5桁で、通常は3桁目の後にスペースを入れて書きます。

アジアとラテンアメリカは主に数値式ですが長さが異なります。インド、中国、ロシア、シンガポール、ナイジェリアは6桁、日本は7桁で慣例的に3桁目の後にハイフンを入れ、韓国は5桁、ブラジルは8桁で5桁目の後にハイフンを入れ、チリは7桁、コロンビアは6桁、ペルーとメキシコは5桁です。長さだけでは国を特定できないため、バリデータは何かを検証する前に国フィールドを必要とします。

カナダはA1A 1A1パターンを使用し、文字が制限されています。最初の文字はD、F、I、O、Q、U、W、Zにできず、残りの文字はD、F、I、O、Q、Uにできません。2つの3文字グループ間のスペースは慣例です。任意の文字を許可するバリデータは、Canada Postが決して発行しないコードを受け入れてしまいます。

イギリスは2〜4文字のアウトワードコード、1つのスペース、3文字のインワードコードを使用し、SW1A 1AAのようになります。オランダは4桁、スペース、2つの大文字です。アイルランドは7文字のEircodeで、3文字のルーティングキーと4文字の一意識別子に分かれます。マルタは3文字、スペース、4桁です。アルゼンチンは8文字のCPAで、文字の後に4桁、3文字が続き、例えばC1425ABCです。

香港とアラブ首長国連邦には郵便番号システムがありません。どちらもこのサイトの38か国フィクスチャセットに含まれており、ジェネレーターは数字をでっち上げるのではなく、空の郵便番号値を返します。これは正しい動作であり、有用なテストケースでもあります。郵便番号を必須とするフォームは、両市場で壊れているからです。

UAEの慣例はP.O. Box番号であり、これは郵便番号ではないため、そのフィールドに押し込めるべきではありません。香港の住所は地区と通りを使用し、郵便物はコードなしで配達されます。データモデルが非nullの郵便番号値を要求する場合は、偽のコードではなく、国レベルのフラグのような明示的なセンチネルを使用してください。偽のコードは検証を通過してしまい、その後、実在のコードを前提とするすべての下流チェックで失敗するからです。

構造チェックは、文字列が国のパターンに一致するかを答えます。存在チェックは、コードが参照データセットに現れるかを答えます。コードが一度も割り当てられていないことを教えられるのは2つ目だけです。このサイトは全38か国に対して構造チェックを、US ZIPに対して40,979行のデータセットに対する存在チェックを実行し、一方を他方と混同しないよう異なるラベルを付けています。

どちらのチェックも配達可能性を証明しません。5桁のUS ZIPが存在しても、その下の番地が存在しないことはあり得ますし、構造的に有効なドイツのコードが、指定された都市とは別の都市に属することもあります。そのレベルの保証が必要なら、郵便参照データセットと番地レベルのデータベースが必要であり、それはフォーマットチェッカーとは別の製品です。

すべてのパターンをアンカーしてください。アンカーなしの/\d{5}/は9桁の文字列内の5桁に一致し、成功を報告します。^と$、または同等の完全一致APIを使用してください。JavaScriptでは\dはASCII数字のみに一致しますが、Pythonでは\dがデフォルトでUnicode数字に一致するため、re.ASCIIでコンパイルするか[0-9]と書かない限り、パターンが東アラビア数字を受け入れてしまいます。

区切り文字が必須かどうかを明示的に決めてください。表示時は標準の区切り文字を自分で挿入します。入力時は0個または1個のスペースやハイフンを受け入れ、正規化します。文字クラス内のハイフンには注意してください。エスケープするか最後に置かない限り範囲を定義してしまいます。また、正規化のバグを大文字小文字を区別しないフラグで覆い隠さないでください。書き込み時に値を大文字にし、表示形式は標準のままにします。

1つの標準形式を保存し、表示形式を導出します。標準形式は通常、標準の区切り文字付きの大文字、または区切り文字が純粋に慣例的な場合は数字のみです。正規化は不可逆であるため、監査証跡が必要な場合は生のユーザー入力を別のカラムに保持してください。サポート担当者が入力された内容を正確に確認する必要があるかもしれません。

国別の正規化は小さいながらも実在します。カナダは大文字の文字-数字-文字、スペース、数字-文字-数字です。オランダは数字の後の文字を大文字にします。イギリスは1つのスペースと大文字です。ブラジルと日本はユーザーがしばしば省略するハイフンを使用するため、ハイフン付き形式に正規化します。ドイツは区切り文字をまったく使わず、先頭ゼロを保持する必要があります。

すべてのバリデータには、国ごとに少なくとも1つの有効ケースと1つの無効ケース、さらに正規化とストレージを特にテストするケースを含むコーパスが必要です。以下の表は出発点となるセットです。無効ケースのいくつかは一般的な理由ではなく国固有の理由で無効であることに注目してください。手書きのテストが早すぎる段階で止まるのはまさにこの点です。

郵便番号のない国、先頭ゼロ、ユーザーが実際に入力する区切り文字のバリアントのケースを追加してください。バリデータがクライアントとサーバーで共有されている場合は、同じコーパスを両方の実装に対して実行してください。寛容なクライアントと厳格なサーバーの間の不一致は、「フォームは受け入れたのにAPIが拒否した」という報告の最も一般的な原因です。