日本邮政 CSV 为什么这么难解析：地址不是字符串，而是一套例外制度

作者：林岚｜OC 开发者生态编辑

开发者为日本邮政编码数据制作 Python 库 posuto 时，发现官方 CSV 远不是“邮编、县、市、町名”四列这么简单。长字段会跨行拆分，括号里混有范围说明，部分地区使用“以下除外”式兜底记录，甚至同一个词在绝大多数行是注释，在某一个真实地址里却必须保留。

一句话结论：地址数据不是一张可以靠 split(',') 解决的表，而是行政历史、投递规则、旧软件限制和自然语言例外共同形成的制度接口。

原始文件为了兼容字段长度限制，会把超过阈值的地名或读音拆成多条记录。解析器不能把每一行当独立地址，而要识别哪些行是前一条的延续，再恢复完整町域。京都的部分地址还会使用路口和方向描述，天然比常见层级式地址长，更容易触发拆分。

括号不是统一的可删除备注。有的括号列举适用番地，有的表示“除此之外”，有的内容需要转成排除规则。CSV 中的“一円”通常表示“周边全部区域”，适合作为说明移除；但滋贺县恰好存在一个町名本身就是“一円”，邮编 522-0317。写一条全局替换规则，就会把真实地名删掉。

罗马字文件又是另一套问题。日本邮政提供的版本更新较慢，可能与主文件不同步，而且转换质量不稳定。原文举例，已经是拉丁字母的“JA”被先按日语读音处理，再错误拆解小假名，最后变成难以辨认的字母串；“Roppongi Hills”也会被机械转写。作者因此建议，在需要罗马字时考虑独立工具 cutlet，而不是把官方字段当绝对真值。

posuto 的做法是把复杂清洗封装成库，同时提供预处理 JSON，方便非 Python 项目使用。它的价值不只是“修好一个 CSV”，而是把隐含规则变成代码和测试。不过，任何第三方清洗层都要跟随官方更新，记录原始版本，并允许用户追溯某条地址怎样被合并或改写。

这类问题对国际化产品很常见。姓名、电话、地址和行政区划看似是字符串，实际都包含地域规则。工程上最危险的做法，是先按自己熟悉的国家设计 schema，再把其他地区当异常值塞进去。例外不是脏数据；很多时候，它就是业务本身。

关键事实

• 来源：posuto 作者对日本邮政 CSV 的解析复盘
• 数据难点：超长字段跨行、括号范围、兜底区域、历史地址表达
• 特殊案例：“一円”通常是说明，但在一处也是实际町名
• 输出方式：Python 库与预处理 JSON

OC 判断

解析器最难的部分从来不是逗号，而是语义。官方提供文件不等于文件适合直接进入现代应用；第三方库也不能靠几条正则永久解决。可靠方案需要版本化原始数据、显式例外、可追溯转换和真实地址回归样本。

为什么重要

• 对开发者：不要把物理行等同于业务记录，也不要无条件删除括号和注释词。
• 对产品团队：日本地址搜索、物流和表单体验取决于本地规则，而非简单翻译。
• 对数据团队：官方数据仍需质量评估、版本管理和转换可追溯性。

参考来源

• Parsing the Japan Post CSV