ガイド

郵便番号を保存する前に検証する

長さと文字の形式だけをチェックする郵便番号の入力欄は、形式は完璧でも内容はまったく間違っている番号を平気で受け入れてしまいます。本当の検証とは、その番号が実在する場所に解決されるかを確認することです。

検証の呼び出し

番号と国のISO 3166-1 alpha-2コードを/v1/postcodeに渡します。有効な組み合わせであれば、座標と位置の構成要素を含む結果が少なくとも1件返されます。

GET /v1/postcode?code=SW1A 1AA&country=GB
{
  "status": "ok",
  "postcode": "SW1A 1AA",
  "country_code": "GB",
  "results": [
    {"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London", "country": "GB"}}
  ]
}

空の結果を無効として扱う

resultsが空で返ってきた場合、その郵便番号と国の組み合わせは既知の場所に対応していません。それを合図に、でたらめな番号が後で配送ラベルまで紛れ込むのを許すのではなく、わかりやすいメッセージとともにフォームの入力を拒否してください。

検証は住所の完全一致と同じではない

郵便番号がカバーするのはひとつの地域であり、国によって狭い場合も広い場合もあります。そのため、検証に合格しても確認できるのは番号が存在することであって、フォームに同時に入力された特定の番地と一致することではありません。番号と番地の両方が一致している必要がある場合は、郵便番号の検証に加えて、完全な住所に対するジオコーディングのチェックを組み合わせてください。

避けるべき間違い

APIに送る前から、自分の想定する形式と合わないという理由だけで番号を拒否すると、見た目の違いのために有効な入力を捨てることになります。スペースが抜けていたり、余分なスペースがあったり、大文字と小文字が不統一だったりする番号も、正規化すれば有効な郵便番号であることがよくあります。検索自体なら許容したはずの書式の癖を理由に入力をいきなり拒否するのではなく、/v1/postcodeを呼び出す前に、入力欄の空白と大文字小文字をトリムして正規化してください。

エッジケース:番号は正しいが国が違う

構文上は正しい郵便番号でも、一緒に選択された国が間違っているだけで検証に失敗することがあります。同じ数字や英数字のパターンが、複数の国の郵便番号体系で有効なコードになり得るためです。顧客が正しいと言い張るコードで検索結果が空になった場合は、郵便番号そのものを問題として扱う前に、国のフィールドが顧客の本来意図した国と一致しているかを再確認してください。

このチェックを実行する場所

チェックはキー入力のたびではなく、フィールドからフォーカスが外れたときかフォーム送信時に実行してください。郵便番号は通常、最後まで入力されて初めて検証する意味が出てくるためです。こうすれば、チェックは入力した1文字ごとに1回ではなく、送信の試行ごとに1回のリクエストで済みます。

あらゆる場所でこれを行うコスト

フォーム送信1回あたりの検証呼び出しは1リクエストです。トラフィックの多いフォームであっても、郵便番号の検証だけなら、すべてのキーに含まれる1日あたりの無料リクエスト2,500件(キーなしでも1つのアドレスから利用可能)のごく一部しか使いません。

誤った郵便番号を配送ラベルに届く前に見つけられるなら、追加のリクエスト1件分の価値は十分にあります。パラメータの詳細は郵便番号検索のドキュメントにあります。