郵便番号データについて思ったこと


郵政事業株式会社(日本郵政)郵便番号データについて、思ったこととか分かったこととか

この投稿は

 郵政事業株式会社(日本郵政)の公開している郵便番号データ(http://www.post.japanpost.jp/zipcode/download.html)について、すながわがJamPack Public DB(https://jamfunk.jp/wp/?page_id=353)を立ち上げるときに分かったこととか、思ったことを勝手に書き連ねています。

 あくまでも勝手なので、本当は違っていたり、検証をしていないような無責任なことを書いているかもしれません。

郵便番号データはそのままお召し上がりにはなれません

 郵政事業株式会社の郵便番号データは、CSVをそのままインポートするだけでは正確なデータベースにはなりません。
理由は以下の通り。

  1. 住所の郵便番号と大口事業所個別番号が別データとなっており、カラム設計が異なっている。
  2. 全国地方公共団体コードは規格上はチェックデジット1ケタを含めた6ケタでないといけないが、郵便番号データ(住所・事業所それぞれ1カラム目)は5ケタになっており、チェックデジットが省略されているため。
    また、事業所データのうち、廃止されたコードのままになっているデータがある。
  3. 1レコードが複数レコードに分割されているため。

住所の郵便番号と大口事業所個別番号が別データとなっている件

 せっかく検索できるようにするなら、1テーブルですべて検索をできるようにすべきである。

 よって、結論は簡単だが、住所と事業所のカラムを統一し、マージすればよい。
結果はこれ(データ構造の項のzipcode_f_01)

 ちなみにJPDBは差分データ(追加・廃止)もすべて含めました。利用者に住所や郵便番号の変更を知らせることにも利用できます。
住所事業所一元化と差分データ包括という点でzipcloudさんよりも2歩先行きました(^ー^)

全国地方公共団体コードが規格に沿っていない件

 個人的に使っている他のデータベースと連携するため、必要だったので調べてみました。
 全国地方公共団体コードは、1~2ケタ目が都道府県コード(JIS X0401)、3~5ケタ目が市区町村コード(JIS X0402)、6ケタ目がチェックデジットと定められています(http://www.soumu.go.jp/main_content/000137948.pdf)。
 しかし、郵便番号データでは5ケタしかなく、チェックデジットが省略されています。

 よって、チェックデジットを含めた6ケタで運用すべきであり、全国地方公共団体コードのチェックデジットを算出して付加すればよい。
結果はこれ。

コードABCDEの場合
(A×6+B×5+C×4+D×3+E×2)÷11 = F あまり G、11-G=E、Eの1の位がCD

 SQLで表すと、これ。

UPDATE `zipcode_f`
  SET `pref_jis` = CONCAT(
    `pref_jis`,
    substr(
      11 – (
        substr(`pref_jis`, 1, 1) * 6 +
        substr(`pref_jis`, 2, 1) * 5 +
        substr(`pref_jis`, 3, 1) * 4 +
        substr(`pref_jis`, 4, 1) * 3 +
        substr(`pref_jis`, 5, 1) * 2
      )
      % 11, -1, 1
    )
  )
  ;

1レコードが複数レコードに分割されている件

 これが一番やっかい。
「郵便番号から住所を検索するサービスにまともなものがない – ぐるぐる~」(http://d.hatena.ne.jp/bleis-tift/20080531/1212217681)や、「郵便番号データの落とし穴 – YU-TANG's MS-Access Discovery」(http://www.f3.dion.ne.jp/~element/msaccess/AcTipsKenAllCsv.html)で報告されている。

 郵便番号データのうち、住所データは町域かな(6カラム目)または町域(9カラム目)が「 全角となっている町域名の文字数が38文字を超える場合、また、半角カタカナとなっている町域名のフリガナが76文字を越える場合には、複数レコードに分割」と記載してあります。

 この現代にそぐわないデータ形式は郵便事業株式会社で大昔に利用していた汎用機の名残だと勝手に察します。郵便事業株式会社にはもっと効率的なデータを提供いただけることを要望しますが、仕様変更を行うには多くの既存ユーザを巻き込まないといけないため、行えない現状も勝手に察します。

 しかも分割の定義をしているにもかかわらず、規定の文字数を超過するところ、規定の文字数内でも分割されている場合もあるようです。

 ちまたの郵便番号データを活用したがっているサイトではこの事実を知って理解している人は意外と少なく、インポートのみで「ほら簡単でしょ」とのたまうサイトが多いのが現状です。

 この問題を解決するには、前述のサイトでいろいろ考察されていますが、郵政事業株式会社は公式な手法を公開していません。
そこで、前述サイトの方法を拝借し、以下のアルゴリズムで対応させました。

  1. 郵便事業株式会社郵便番号データのうち、住所番号を順序通り1行ずつ読み込む。
  2. 「町域」で、"("が含まれ、")"が含まれないデータを検索する。
  3. 当該のデータを見つけた場合、そのデータより先にあり、「郵便番号」が等しく、"("が含まれず、")"が含まれるデータを検索する。
  4. それらのデータの「町域かな」と「町域」をそれぞれ順序通り結合する。
  5. 結合したデータに置き換える。

 このアルゴリズムは前述の2サイトと「郵便番号データの廃止データを解析してみた – my-hobby」(http://www.my-hobby.jp/index.php/category/postal-code-lookup/)を参考にさせていただきました。

2012.08.12追記
「町域」に括弧が含まれても「町域かな」には括弧が含まれないレコードが確認されたので、判定は「町域」で行うことにしました。

 なお、生成結果を流し読みはしましたが、未検証です(^^; YU-TANGさんの「0285102」と「8260043」の2件のチェックは行っております。

参考