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

去年年底，我发布了posuto，这是一个以易于使用的格式显示日本邮政编码数据的包。它是基于日本邮政发布的数据，日本邮政因被广泛使用而臭名昭著，但很难解析。

当我在网上表格中输入我的邮政编码时，我第一次知道了邮政编码，它自动将我的地址填成了XXX-borough(以下建筑物除外)"；。我不知道那个插入语指的是什么，所以我寻找了一个通用的邮政数据来源，找到了CSV，发现了问题所在。原来，CSV文件包含供任何阅读CSV文件的人使用的附加注释，并引用了行的顺序。

这会带来问题。这些数据主要是一次一行有用的，其中的圆括号是没有意义的。由于CSV是一种以字段分隔的格式，因此也不需要带括号-您只需添加一个备注字段即可。

这只是ken_all.csv的众多问题之一。你可以发现人们经常在推特上抱怨这件事，甚至有一个短暂的博客，只是从网络上收集关于这件事的帖子。一条特别有趣的推文描述了一些人希望计算机屈从于人类在地狱中受到惩罚的意愿，永远拥有最大的ken_all.csv。

该文件的自述文件解释说，具有过长字段的行将被拆分成多行。具体地说，如果邻居名称超过38个字符，或者半角片假名(半角片假名)发音字段超过76个字符，则该行将被分成两行。过长的邻域字段将继续，所有其他字段将被复制。这是一个简短的例子，展示了它的样子：

12345，东京，水里，这个地名真的是12345，东京，水里，很长，它不适合12345，东京，水里，一行都不合适，所以我们不得不去12345，东京，水里，平分它。

这一行为的动机并未得到解释。也许在30年前的某个地方，有一种固定宽度的缓冲器来存储一行。在以前的工作中，我经常处理来自数百个不同提供商的CSV和其他文件，我看到了很多可怕的情况，但我在其他地方从未见过这种特殊的格式选择。还应该注意的是，虽然长度限制如上所述，但在长行中插入换行符的位置似乎是随机的，既不在字符限制上，也不在正常的单词边界上。

值得注意的是，CSV并不是所有的问题都是固有的技术问题；邮政编码总是很复杂。CSV中行数最多的邮政编码是〒452-0961，这个邮政编码指的是爱知县清苏市的原日地区，这一邮政编码高达惊人的66行。这里有那么多线，因为每个社区都有一条单独的线。(这个特殊的案例可能与Haruhi2006至2009年并入清苏市后一直是日本面积最小的城镇有关。)

相比之下，使用上面的换行规则，最长的连续行是〒602-8368或〒602-8374的条目，这两个条目都有8行。这两个区域都位于京都少数几个使用独特的、怪异的交叉口寻址系统的区域之一。条目看起来有点像这样：

京都，京都，12345；北镇(从京都，京都12345号往上，往下走；从京都，京都，12345号往下，往下乌龟街往东，从京都，京都，12345号往上沿着老庙路往上走)，从西向西，从老庙路往上走，从京都，京都，往西，往下走，沿着龟头街往下走，从京都，12345号街往东，从老庙路往上，从京都，京都，西往上)。

我在这里使用了带引号的字段，但实际的CSV没有引用字段，而是使用了不同类型的逗号。

还有其他问题。很多地区都有通用的邮政编码，除了下面的区号外，其他地区的邮政编码都是通用的，唯一要做的就是查找这个完全相同的字符串并将其排除在外。类似的字符串有很多种，很难确定我已经把它们都抓住了。

另一个评论的例子是一円。通常情况下，这意味着1日元，但它也意味着周围的区域，这是CSV中的一个注释，应该从社区名称中删除，但志贺有一个社区的名字实际上就是这个社区的名字(〒)。

此外，摩根大通邮报还提供了一份单独的罗马吉档案。它比主文件更新频繁，经常不同步，而且提供的文件质量极低。目前，我仍然以一致性的名义提供数据，但老实说，你应该只使用牛排。举一个糟糕的罗马吉酒的例子：

这里发生的事情是，日本正在被转换为日语的音标读法，ジェイエイ&34；(日语是日语，日语)。然后，ジェ(大号字母小字母，但发音为je；34；je；)将被转换为字母汤，方法是将小字符视为大字符，而其他字符则按原样翻译，将拉丁字母中已有的东西转换为字母汤。相比之下，Cutlet可以毫不费力地将JAビル改建成JA大楼(无可否认，案件处理还需要一些工作)。类似的问题使六本木山变成了Roppopgihiruzu；瑞典山变成了Suedenhiruzu。

不管怎么说，处理这些文件是一个令人羞愧的教训，因为它可能会被打包到一个地方。我已经润色了很多细节，但你可以在POSUTO的自述文件中找到它们。

你可以把posuto当做一个库来使用，或者如果你没有使用Python，只需下载经过预处理的JSON并使用它即可。如果你觉得它有很好的用处，我很乐意听你说。

哦，如果你需要Win3.1或DOS程序来将数据复制到IBM软盘上，只需查看JP Post页面的底部-他们会为你提供担保。Ψ