最后更新: 2026-09-06

各国地址格式与字数差异 - 表单设计中的地址字段长度指南

地址的差异不只在书写顺序，还在邮政编码的位数、构成要素的多少，以及哪一个要素会把整条地址拉长。不清楚长度从哪里来就去设计表单，结果往往是真实存在的地址填不进去。本文先把一条日本地址拆开逐个数出字符数，再读出一国邮政规范实际定义的字段上限，最后把这两者换算成能够逐条说明依据的 maxlength 值。

各国地址的书写顺序与构成要素

地址格式因国家和地区而异，最基本的分歧是从大范围写到小范围，还是从小范围写到大范围。下表整理主要国家的构成要素与书写顺序，这一部分属于公开的书写惯例。

印度的地址之所以容易变长，原因与层级本身无关，而在于许多地区的街道命名和门牌编号并不统一，因此地址要靠地标 (「近克里希纳神庙」「州立银行对面」) 和多级地区名来定位。例如「Flat 302, Building A, Sunrise Apartments, Near Krishna Temple, Sector 15, Vashi, Navi Mumbai, Maharashtra 400703」这一条为 112 个字符，若字段在 60 个字符处截断，地址会被砍掉一半，配送也就无从进行。

日本地址的实测拆解 - 长度来自哪个要素

要看清哪一部分决定了地址的长度，最快的办法是把一条地址拆开来数。下表逐个要素数出一条具有代表性的日本地址，数法为：分隔用的半角空格计为 1 个字符，日本邮政的邮编符号 〒 不计入。

变动集中在建筑名这一项。把上表各例用单个空格连接起来，整条地址为 45 个字符。同一条地址在为国际配送而罗马化之后会明显变长，因为汉字每个字符承载的信息量远高于拉丁字母。「东京都港区六本木 6-10-1 六本木新城森大厦 49 层」为 29 个字符，而「49F Roppongi Hills Mori Tower, 6-10-1 Roppongi, Minato-ku, Tokyo 106-6149」为 73 个字符。按汉字版本的长度去设定单行字段，罗马化版本就会被截断。

邮政编码的格式与字符数

邮政编码看似简单，但各国的格式差异很大。仅用数字验证邮政编码会导致许多国家的用户无法通过表单验证。下表的字符数在格式本身含有空格时把该空格计入。

英国的邮政编码最难验证。格式从「A9 9AA」(含空格 6 个字符) 到「AA9A 9AA」(8 个字符)，空格的位置随前段编码的长度而移动。完整的英国邮政编码指向的是大致十个左右的地址构成的一组，或是收取大量邮件的单个投递点。许多开发者放弃严格验证，只检查 5 至 7 位字母数字加一个可选空格，这在实践上说得通，但也会放过无效编码。爱尔兰的 Eircode 于 2015 年启用，每个编码为 7 个字符，前 3 个字符是标识投递区域的路由码，后 4 个字符标识具体的地址，因此「A65 F4E2」指向的是某一栋建筑而不是一个街区。这一设计解决的是当地的实际问题：不少爱尔兰住宅既没有门牌号，也没有唯一的街道名。设定邮政编码字段时不要按日本的 7 位数字去固定长度，留出 8 个字符左右，字母和空格才放得下。

地址规范定义的字段长度 - 英国皇家邮政的 PAF

当邮政运营方自己公布了字段上限时，就没有必要去猜最大长度。英国地址背后的地址数据库规范 Postcode Address File (PAF) 为它收录的每一个要素都定义了最大长度。

值得注意的是这份规范没有说什么。常被引用的「街道一行最多 80 个字符」是两个字段的合计值，即街道名 60 个字符加种别词 20 个字符，并不存在这么大的单一字段。把上表列出的 13 个字段相加为 471 个字符。几乎没有地址会把它们全部填满，但这个算术给出了单行自由输入需要顾及的上限。「Flat 3, 27 Elm Street, Kensington, London, W8 5DL」是为说明格式而虚构的示例，其顺序依次为副建筑名、建筑编号、街道名、地区名、邮政城镇、邮政编码。

地址字段的推荐长度设计

有了上面的实测值和规范定义的上限，就足以给出每一条都能说明依据的 maxlength。字段太短会截断地址，太长则浪费界面空间和数据库存储。

反复出现的失误是把地址行 1 设为 40 或 50 个字符。这对不少美国和英国地址够用，但罗马化的日本地址、带地标的印度地址、含 complemento 的巴西地址都会溢出，上文的 73 个字符与 112 个字符两例就是如此。把上限设为 100 个字符在数据库存储上几乎没有代价 (使用 VARCHAR 而非 CHAR)，却能消除一整类本可避免的失败。另外不要把每个字段的含义都按国家逐一固定下来：更通用的做法是只把国家和邮政编码结构化，其余部分交给只固定顺序的自由输入行，也就是「地址行 1」和「地址行 2」。由于任何一行都不绑定特定要素，同一套表单既能容纳门牌号写在街道名之前的国家，也能容纳写在之后的国家，而一个取自上述规范数值的宽松的单行上限，就替代了一整棵按国家分支的规则树。

地址的多语言字符数差异

同一个地址用不同语言书写时，字符数可能相差数倍。这对多语言系统的地址存储和显示设计提出了挑战。下表的字符数同样按前述数法实测，即空格计为 1 个字符。

汉字的信息密度使同一条地址的中文或日文写法明显短于英文写法，上表这 3 例分别为英文写法的 46%、46%、30%。但在数据库设计中，字段长度应以最长的语言版本为基准，否则英文地址会被截断。显示侧也是同样的道理：按中文写法的宽度去排版地址栏，切换到英文时就会换行或溢出。

地址验证 API 与字段设计

地址验证与地址数据类的服务能把用户输入整理成规范格式，也能在用户只填一部分时补全其余要素。下表整理的是可公开确认存在的服务及其用途。

其中由邮政编码自动填入的做法对减少输入量最直接。用户只填 7 位邮编，都道府县和市区町村就已确定，剩下需要手填的只有町名番地和建筑名，也就是上文拆解表中变动最大的那两项。在表单设计中，减少用户需要输入的字符本身就是最有效的长度管理手段。至于字段上限，不要依赖这些服务把地址「缩短」之后的长度，仍应按规范定义的上限留出余量：能否调用外部服务和地址本身能否填进去，是两件必须分开考虑的事。