この記事は公開されてから3ヶ月以上経過しています。 情報が古い可能性がありますのでご注意ください。

郵便番号データの KEN_ALL.csv が抱える様々な問題点をあげつらう記事を書いた のが今年の5月1日のこと。およそ3か月前です。 そのおよそ2ヶ月後に、日本郵便株式会社から公式に KEN_ALL.csv の多くの問題を解決した新しいバージョンがリリースされました。 これは素晴らしく革新的な事です！その喜びをここに綴っていこうと思います。

KEN_ALL から utf_all へ

わたしは前回の記事（KEN_ALLについて本気出して考えてみた） で、 未来のKEN_ALLはこうなってほしい という願望を書きました。 同じ願望を抱いた人は決して少なくはないでしょう。こちらがその願望です。

1. Unicodeにしてほしい
2. 1レコード1行にしてほしい
3. それが無理ならレコードにユニークなIDをふってほしい
4. それも無理なら「このレコードは複数行にわたります」フラグをつけてほしい

要するに、 「Shift_JISをやめてくれ」「複数行にレコードを分割するのはやめてくれ」 ということです。 （この他にも要望はあるのですが言ったらきりがありません） そして6月末にリリースされた新しいバージョンの郵便番号データは、これらの望みを全て叶えてくれました。 その名は utf_all.csv 。（ KEN 要素はどこにいった？）

utf_all.csv はその名のとおり、Unicodeで作成された全都道府県分の郵便番号データです。 新しい形式のデータベースでは1レコードは1行にまとめられ、半角カタカナで表記されていた住所のフリガナは全角カタカナに変換されています。 これが登場したことにより、わたしが書いた mach3/kenall-parser はたったの2ヶ月でめでたく OUTDATED となったわけです。

KEN_ALL が使えなくなるわけでは（まだ）ない

古くから利用されている KEN_ALL がメンテナンスされなくなるわけではないので、 KEN_ALL で動いているものをわざわざ utf_all に移行する必要は当面はないでしょう。

しかし、将来的にどうなるかは保証できませんし、 これから新たに郵便番号データを活用した何かを開発する場合は、恐ろしく楽になっているはずなので是非 utf_all を活用しましょう。

比較してみよう

実際に KEN_ALL と utf_all のデータを比較してみましょう。 複数行レコードの中で最も番号が若い 〒066-0005 のレコードをそれぞれのデータから抽出してみます。

KEN_ALL.CSV

$ iconv -f sjis -t utf8 KEN_ALL.CSV | grep "0660005"
01224,"066  ","0660005","ﾎｯｶｲﾄﾞｳ","ﾁﾄｾｼ","ｷｮｳﾜ(88-2､271-10､343-2､404-1､427-","北海道","千歳市","協和（８８−２、２７１−１０、３４３−２、４０４−１、４２７−",1,0,0,0,0,0
01224,"066  ","0660005","ﾎｯｶｲﾄﾞｳ","ﾁﾄｾｼ","3､431-12､443-6､608-2､641-8､814､842-","北海道","千歳市","３、４３１−１２、４４３−６、６０８−２、６４１−８、８１４、８４２−",1,0,0,0,0,0
01224,"066  ","0660005","ﾎｯｶｲﾄﾞｳ","ﾁﾄｾｼ","5､1137-3､1392､1657､1752ﾊﾞﾝﾁ)","北海道","千歳市","５、１１３７−３、１３９２、１６５７、１７５２番地）",1,0,0,0,0,0

KEN_ALL.CSV は Shift_JIS なので iconv でコンバートされた結果に grep で絞り込んでいます。

utf_all.csv

$ grep "0660005" utf_all.csv
01224,"066  ","0660005","ホッカイドウ","チトセシ","キョウワ（８８−２、２７１−１０、３４３−２、４０４−１、４２７−３、４３１−１２、４４３−６、６０８−２、６４１−８、８１４、８４２−５、１１３７−３、１３９２、１６５７、１７５２バンチ）","北海道","千歳市","協和（８８−２、２７１−１０、３４３−２、４０４−１、４２７−３、４３１−１２、４４３−６、６０８−２、６４１−８、８１４、８４２−５、１１３７−３、１３９２、１６５７、１７５２番地）",1,0,0,0,0,0

KEN_ALL では住所文字列に使用できる文字数が制限されているため複数行に分割されていますが、 utf_all では1行にまとめられ、フリガナは全角カタカナに変換されたため、とっても長ーい1行になりました。

行数とサイズも調べてみました。

$ wc -l utf_all.csv KEN_ALL.CSV
  124319 utf_all.csv
  124627 KEN_ALL.CSV
  248946 total
$ du -b utf_all.csv KEN_ALL.CSV
18318065        utf_all.csv
12346485        KEN_ALL.CSV

複数行レコードが全て1行にまとめられたことで全体の行数は減っていますが、フリガナがマルチバイト文字になったことで全体のデータサイズは大きくなっています。

utf_all はいつ生まれたの？

住所の郵便番号（1レコード1行、UTF-8形式）（CSV形式） - 日本郵便
郵便番号のデータ利活用の観点から、2023年6月更新分より、新たな形式でのデータを追加で公表します。

こちらがダウンロードページなのですが、この情報と更新履歴を照らし合わせると、6月30日更新分のデータから公表されたであろう事がわかります。

ただ、わたしの記憶が確かならば、7月1日の時点ではこのページは存在しておらず、 郵便番号データダウンロードページ にCSVファイルへの直接リンクが貼られているのみでした。 現在ではzipファイルでのダウンロードのリンクのみ記載されていますが、 csvファイルへのリンク も一応生きてはいるようです。

生きてはいるのですが、このファイルもメンテナンスされているのかは確認していないので、無難にzipファイルから取得するのが良いでしょう。 （活用する側からすると fetch するだけでいい csv ファイルの方が楽なのですが）

新しいパーサーを書きました

わざわざ移行する必要はない と上で申し上げたばかりですが、せっかくなので mach3/kenall-parser をベースにした新しいパーサーをこしらえました。

mach3/utfall-parser
KEN_ALL.csv の後継版である utf_all.csv をパースする node.js 用ライブラリです。

kenall-parser を使っていた ZIPCODA も、 utfall-parser に移行しています。 だから何が変わったのかというと、基本機能には差異はないので何も変わっていません。 複数行レコードを処理する必要がなくなったので、その分コード量がちょっと減ったかなという程度です。 ZIPCODA では月一回データを更新しているので、その際に文字コードの変換や、複数行レコードをまとめる無駄な処理をする必要がなくなり、リソースの節約にはなったと思います。

まとめ

日本の郵便番号データに、歴史的な変革が訪れました。 Shift_JISを脱却するのはもっと早くに対応されてもおかしくなかったとも思いましたが、 同じタイミングで複数行レコードを退治してくれたので、完全勝利です。 開発者も移行がし易いというもの。

日本郵便の開発の人に、ありがとう。