解析臭名昭著的日本邮政 CSV

去年年底，我发布了 posuto ，这是一个以易于使用的格式呈现日本邮政编码数据的包。它基于日本邮政发布的数据，该数据因广泛使用但难以解析而臭名昭著。 Irasutoya 创作的这个可爱角色很可爱，但原始邮政 CSV 数据却不可爱。当我在在线表格中输入邮政编码时，我第一次意识到邮政数据，它自动将我的地址填写为“XXX-行政区（以下建筑物除外）”。我不知道该括号指的是什么，因此我寻找了邮政数据的常见来源，找到了 CSV，并发现了问题。事实证明，CSV 文件包含供任何阅读该 CSV 文件的人使用的附加注释，并引用了行的顺序。这会导致问题。数据主要一次一行有用，其中括号毫无意义。由于 CSV 是一种字段分隔格式，因此也不需要括号 - 您只需添加注释字段即可。这只是 ken_all.csv 的众多问题之一。你可以发现人们经常在 Twitter 上抱怨它，甚至有一个博客只是简单地收集网络上有关它的帖子。一条特别有趣的推文描述了人们希望计算机屈服于人类的意志，通过永远解析 ken_all.csv 在地狱中受到惩罚。该文件的自述文件解释了字段过长的行将被分成多行。具体来说，如果邻居名称超过38个字符，或者半角片假名（半角片假名）发音字段超过76个字符，则该行将被分成两行。过长的邻域字段将继续，所有其他字段将被复制。这是一个缩写示例，如下所示： 12345,Tokyo,Minato,这个地名实际上是 12345,Tokyo,Minato,很长，它不适合 12345,Tokyo,Minato,一行，所以我们不得不将 12345,Tokyo,Minato,split 它 这样做的动机没有解释。也许三十年前的某个地方有一个固定宽度的缓冲区用于存储一行。我曾经在一份旧工作中处理过来自数百个不同提供商的 CSV 和其他文件，我看到了很多可怕的事情，但我从未在其他地方见过这种特殊的格式选择。还应该注意的是，虽然长度限制如上所述，但在长行中插入换行符的位置似乎是随机的，既不会出现在字符限制处，也不会出现在正常的单词边界处。值得注意的是，并非 CSV 的所有问题本质上都是技术问题；邮政编码总是很复杂。 CSV 中行数最多的邮政编码（令人惊叹的 66）是〒452-0961，它指的是爱知县清须市的 Haruhi 地区。这里有那么多线路，因为每个社区都有一条单独的线路。 （这种特殊情况可能与春日从 2006 年到 2009 年并入清须市期间一直是日本面积最小的城镇有关。）相比之下，使用上述换行规则，最长的连续行是〒602-8368 或〒602-8374 的条目，两者都有八行。这些都是京都少数几个使用独特、奇怪的交叉路口寻址系统的地区之一。该条目看起来有点像这样： 12345,Kyoto,Kyoto,"North Town (Up Lower Godsroad from" 12345,Kyoto,Kyoto,"the West, Down Turtle Street from the" 12345,Kyoto,Kyoto,"East, Up Old Temple Road from the"12345,Kyoto,Kyoto,"West)" 我在这里使用了引用的字段，但实际的 CSV不引用字段，而是使用不同类型的逗号。还有其他问题。许多地区都有包罗万象的邮政编码，其中邻居被指定为“除以下范围外”，唯一要做的就是查找确切的字符串并将其排除。类似的字符串有很多种，很难确定我已经全部抓住了。另一个评论的例子是一円。通常这意味着“一日元”，但它也意味着“周围的区域”，并且是 CSV 中的注释，应从社区名称中删除，除了滋贺县的一个社区，该社区实际上是该名称 (〒522-0317)。 JP Post 还提供了一个单独的罗马字文件。它的更新频率低于主文件，经常不同步，并且提供的罗马字质量极低。目前，我仍然以一致性的名义提供 posuto 中的数据，但老实说，您应该只使用 cutlet 。举一个错误罗马字的例子： 大手町 JAビル OTEMACHI JIEIEIBIRU 这里发生的情况是“JA”被转换为日语的语音读法“ジェイエイ”。然后，写为“大ji小e”但发音为“je”的ジェ通过将小字符视为大字符而被转换为“jie”，而其他字符则按原样翻译，将拉丁字母中已有的内容变成字母汤。相比之下，炸肉排可以毫无问题地将“JAビル”转换为“JA 大楼”（案件处理确实还需要一些工作）。类似的问题变成了“罗普