邮政编码校验实战:批量检查一份地址表里填错的邮编

去年帮一个跨境电商朋友做收货地址清洗,他从三个渠道导出了客户表,合在一起两千多行。要往物流系统里推之前,他想先把填错邮编的挑出来。我打开那张表扫了几眼就头疼:有的中国地址写了 5 位,有的美国地址写成了 6 位,还有人把电话尾号填进了邮编那一列。靠肉眼一行行看根本不现实。这类活其实不需要写脚本,用 邮政编码列表校验器 在浏览器里跑一遍就能分出有效和无效,而且数据不离开本机。

各国邮编格式不一样,这是校验的第一个坑

很多人以为邮编就是一串数字,真正动手才发现各国规则差很多。中国大陆是 6 位纯数字,比如 100008;美国是 5 位,常见的 ZIP+4 还会带个连字符写成 12345-6789;英国混了字母,像 SW1A 1AA;日本是 7 位带一个连字符,写成 123-4567。

所以一份混了多国地址的表,不能用同一条规则去卡。一个工具如果只认 6 位数字,会把所有美国邮编都判成无效,反而制造噪音。校验的意义不是机械套一个长度,而是按这一列实际所属的国家,识别出明显不合规的那些行,再把原因标在旁边。

一个真实的输入输出例子

假设你手上有这么几行,混着对的和错的:

100008
10008
SW1A 1AA
9A1B7
12345
123456789

跑一遍校验后,大致会分成这样:

• 100008:有效,符合中国 6 位
• 10008:无效,少一位,中国邮编应为 6 位
• SW1A 1AA:有效,符合英国格式
• 9A1B7:无效,该是数字的位置掺了字母
• 12345:有效,符合美国 5 位
• 123456789:无效,位数超长,更像是把别的字段填了进来

关键在最后那一列原因。10008 少一位、9A1B7 字母放错位置,这正是你要退回去给人改的行。很多人图通过率好看,会把无效项直接丢掉,结果错误数据照样进了系统。我的习惯恰恰相反,失败清单才是这次校验真正的产出。

收货地址清洗的标准流程

做运营交付,我一般按这个顺序走:先把几份导出的原始文本全粘进来,这一步常常带着从网页复制时混进来的隐藏空白,所以先规范化再去重,顺序别反。如果只是想把一份脏列表里的重复值清掉,可以单独用 邮政编码去重器 先收一遍,再回到校验器做格式检查。

清洗完之后导出。校验器支持逐行、CSV、JSON、SQL IN 和 TypeScript union 几种格式。要交给同事复核就导 CSV,带上行号和原因,对方一眼能定位到原文哪一行;要直接喂给导入脚本,就导 JSON 或 SQL IN,省得手工补引号和逗号。下载出来的就是可交接的产物,不用再手工整理一遍。

为什么坚持本地处理

收货地址这种东西,本质上是客户的个人信息。把整张表传到某个在线工具的服务器去校验,我个人是不放心的。这个工具所有解析、校验、去重、导出都在浏览器当前标签页里完成,上传的本地文件也是用浏览器的 File API 在本机读取,不会发到服务器。对要过合规复核的团队来说,这一点比快几秒重要得多。

还有一句要提醒:邮编格式正确,不等于这个地址真实存在。校验只负责挑出格式明显不对的行,真实性得靠下游的地址库或物流系统再核一次。把校验当成真实性证明,是另一个常见的坑。

几个能省时间的小习惯

如果原始导出列特别多,检查觉得卡,多半是你把整张大表直接喂进来了,先裁到只剩邮编那一列再跑。需要保留审计线索时,别只复制最终列表,把带行号的 CSV 一起下载下来存档。要把清洗结果接到别的文本处理流程,比如还要抽取里面的链接或转成表格,可以接着用 Markdown 链接提取器 这类同系列工具,它们的输入输出习惯是一致的,衔接起来不别扭。

一份两千行的混国地址表,这套流程跑下来不到五分钟,该退回去修的行清清楚楚列在那里。比起肉眼一行行扫,这才是这类清洗活该有的样子。

---

Made by Toolora · Updated 2026-06-13