本文要点
- 中文地址通常从省市区写到楼层房间和收件人
- 拉丁字母国际写法常从收件人和详细位置写向城市国家
- 邮编是六位文本标识符
- 音译、英译和邮政验证不可混为一步
作者与审核
查看编辑与审核原则- 作者
- Random Address Generator 编辑团队
- 审核
- 国际地址格式审核组
- 最近实质更新
- 依据万国邮联中国地址格式资料，核对中文层级、拉丁字母顺序和六位邮编。
中文国内地址的大到小层级
中文地址一般从省级地区、市、区县继续到街道、门牌、小区、楼层和房间，最后写收件人。直辖市会让“省”和“市”的值看起来重复，因此数据模型不应强迫所有地址都具有不同的省和市字符串。
国际表单应使用可本地化标签和多级行政区域，而不是把所有层级压到 City 和 State 两个框里。
拉丁字母国际写法
万国邮联的中国参考资料将拉丁字母地址按从小到大的顺序排列：收件人、房间楼层楼宇、门牌道路、区县、邮编与省市，最后是 P.R. CHINA。
这个过程需要组合结构化字段，不是将中文字符串倒放。人名和地名的拉丁字母写法应由用户确认。
国际表单的字段映射
数据库应保留原始完整地址，同时将省级区域、城市、区县和详细地址作为可选的结构化字段。不要设定一个全球通用的固定行数。
| 字段 | 含义 | 测试点 |
|---|---|---|
| address-level1 | 省、自治区或直辖市 | 允许直辖市模型 |
| address-level2 | 城市 | 不强制与 level1 不同 |
| address-level3 | 区县 | 保留后缀或标准代码 |
| address-line1 | 道路与门牌 | 支持中文字符 |
| address-line2 | 小区、楼层、房间 | 允许为空或较长 |
| postal-code | 六位邮编 | 存为文本 |
字符编码、姓名与导出测试
完整链路必须使用 Unicode：浏览器输入、API JSON、数据库、CSV 导出和 PDF 字体任何一环都可能造成乱码或缺字。测试要读回导出文件，而不是只断言“下载成功”。
姓名不应默认拆成西式 firstName 和 lastName 后再反向组合。可以保存 fullName 并将分解字段设为可选。
- JSON 往返不丢字
- CSV 使用 UTF-8 并验证重新导入
- PDF 嵌入支持中文的字体
- fullName 不因空格规则被截断
- 邮编前导零保留
格式、转写和真实性要分开
一条合成记录可以展示正确层级，但不代表其中的门牌和房间真实存在。如果业务需要实际配送，应使用合法数据源并由用户确认。
将原文、结构化字段和国际输出放在一起审核
审核不要只看最终英文标签。在同一页并排显示原始中文、解析后的省市区与详细行、用户确认的拉丁字母写法。审核者需要能从任一输出回到原始组件，并发现楼层、房间或区县是否在排序时丢失。
然后将同一记录经过移动端输入、JSON API、数据库、CSV 和 PDF 五个边界。对每个边界比较 Unicode 文本、邮编长度和行数。一个常见陷阱是 CSV 打开时看似正常，再导入系统后才发现邮编已被当作数字或中文已按错误编码读取。
- 并排审核中文原文、解析组件和国际输出
- 让人名与地名的拉丁字母写法可修正
- 对 API、CSV 和 PDF 做实际往返而不是视觉抽查
- 将转写状态与邮政验证状态分列存储
常见问题
中文地址翻成英文只需要倒过来吗？
不是。需要先识别收件人、房间、道路、区县和城市等组件，再按国际顺序组合。
中国邮编应该存数字吗？
应存文本。邮编是六位标识符，不用于算术，文本也能保留前导零。
可以只保留拉丁字母地址吗？
不建议。原始中文便于当地核对，拉丁字母写法则主要服务国际输出。