小语种URL用本地字母还是拉丁转写，地址栏里看不出差别，日志和外链里差得很明显

摘要：浏览器地址栏会把本地字母的网址解码成好看的样子，可这只是显示层的礼貌。真正流通的那一串是百分号编码，一个西里尔字母展开成九个字符。转写看着安全，但一门语言常常有好几套转写标准，别人写外链时用的不一定是你选的那一套。

地址栏里看到的和实际传输的不是一串东西

浏览器替你做了一层解码

把一个带本地字母的网址粘进地址栏，看起来一切正常。

字母清清楚楚，跟你在编辑器里写的一模一样。

但这只是显示层的处理，浏览器为了好看做的解码。

真正发出去的请求里，那些字母全部变成了百分号加十六进制。

服务器日志、抓取记录、数据导出里存的都是编码后的形态。

两者是同一个地址的两种表示，但你能看到的场合完全不同。

这个错觉造成的后果是决策时用的是显示层的直觉，而承担代价的是传输层的现实。判断该用哪种写法之前，先做一件事：把候选网址复制出来粘进纯文本编辑器，你看到的就是真实形态。所有讨论都应该基于这个形态，而不是地址栏里那个已经被美化过的版本。

不同浏览器的解码策略还不完全一样，有的会在地址栏里显示解码形态但复制出来是编码形态，有的两边一致。所以团队内部沟通地址时不要口头描述，直接贴纯文本，否则两个人说的可能是同一个地址的两种形态而彼此不知道。

一个字母展开成几个字符

展开的倍数取决于这个字母在编码里占几个字节。

拉丁字母加变音符号通常占两个字节，展开成六个字符。

西里尔字母、希腊字母占两个字节，同样是六个，西里尔页面被抓回去变成一串认不出的拉丁字母讲的就是字节这一层。

汉字、假名、天城文这类占三个字节，展开成九个字符。

表情符号和某些扩展字符占四个字节，展开成十二个。

所以一个十二个字母的本地词，能展开成上百个字符。

算一下具体的量级：一个由三个词组成的分类路径，本地字母写出来大概二十来个字符，编码之后能到一百二十个以上。加上域名和目录层级，整条地址轻松超过两百个字符，而这个长度会出现在你所有的报表、导出文件和外链锚里。

长度还有一个隐性上限要留意，某些服务器和代理对请求行的长度有默认限制。正常的分类路径不会碰到，但带多个筛选参数的地址在编码之后可能接近甚至超过限制，表现为个别筛选组合直接报错，而这类错误只在特定组合下出现，很难被测试覆盖到。

长度会在哪些地方咬人

长度本身不影响抓取，引擎处理长地址没有问题。

咬人的地方在人和工具要处理这串字符的那些环节。

表格软件的单元格、日志分析工具的列宽、报表的截断。

邮件和即时消息客户端的自动链接识别也是一个常见断点。

有些客户端遇到非拉丁字符就停止识别，链接被截成两半。

用户复制粘贴分享时，断掉的那半截会变成无效链接。

真正难受的是这类问题不会集中爆发，而是零散地降低每一个分享环节的成功率。你在数据里看到的只是社交渠道的引荐流量偏低，没法归因到具体原因上。相比之下拉丁转写的地址在任何客户端里都能被完整识别，这一条是它最实在的优势。

还有一个受影响的场合是纸质和图片素材，包装、说明书、线下广告上印的地址如果是编码形态，那就完全没法看；要印的话必须准备一个短的拉丁形态作为替代入口，并配好跳转。这件事往营销部门那边一说通常都能理解，但等到素材已经付印才发现就来不及了。

域名和路径为什么走两套不同机制？

域名那一段走的是另一条路

本地字符的域名和本地字符的路径，机制完全不同。

域名部分不能直接放非拉丁字符，要先转成一种特殊编码。

转出来的结果以两个字母加两个连字符打头，后面跟一串字符，算法本身写在RFC 3492的Punycode定义里。

这个转换是可逆的算法，不是百分号编码，两者不通用。

路径部分才用百分号编码，走的是RFC 3986对保留字符与编码的规定那一套。

把这两个机制混着说，是这个话题上最普遍的误解。

为什么必须分开：域名要经过域名系统解析，而域名系统历史上只接受有限的字符集合，所以需要一种把任意字符压进这个集合的算法。路径不经过域名系统，它由服务器自己解释，所以可以直接用字节的百分号表示。两套机制解决的是两个不同的约束。

这个算法的另一个特点是转换结果对输入的大小写和规范化形式敏感，所以域名在转换之前要先做统一处理。国际化域名的相关规范专门定义了这套预处理流程，包括哪些字符允许、哪些必须映射、哪些直接禁止，不按流程走可能生成一个语法上合法但解析不到的域名。

混淆之后会犯什么错

最常见的错是以为域名能用本地字母，路径就自动能用。

或者反过来，以为路径要转写，域名也必须转写。

两个决策其实是独立的，可以任意组合。

本地字符域名配拉丁转写路径，这个组合相当常见。

拉丁域名配本地字符路径，也完全成立。

四种组合各有适用场景，不该被绑成两个选项。

混淆的另一个后果是排查问题时找错方向。域名解析层面的问题和路径处理层面的问题症状可能相似，都表现为访问不了或者跳转异常，但排查工具完全不同。先确认是哪一层出问题，再选工具，能省下大量时间。

还有一种混淆出现在配置层面，把域名的国际化设置和服务器上路径的字符编码设置当成同一件事去改。两者由不同的组件负责，改错了地方的典型症状是改动完全没有效果，然后有人开始怀疑缓存，一路查到很晚才发现方向从一开始就错了。

两套机制的规范各自在哪里

路径的百分号编码规则定义在网址的基础规范里。

用非拉丁字符表示网址的那套扩展，另有RFC 3987定义的国际化标识符这份独立规范。

域名那一段的编码算法有自己的独立文档。

域名系统的国际化处理还有一整套后续规范在管。

做技术决策时，这几份文档要分清楚各自管什么。

引用错了文档，团队内部讨论会一直对不上。

实操上不需要通读这些规范，但要知道遇到分歧时该翻哪一份：路径怎么编码翻网址规范，非拉丁字符怎么表示翻那份扩展规范，域名那一段怎么转翻编码算法文档，国际化域名的合法性规则翻后续那套规范。分清楚这四个入口，讨论就不会绕圈。

除了这几份规范，还有一份把网址处理写成可实现算法的现代标准，浏览器实际是照它实现的。规范之间偶有细节差异，遇到浏览器行为跟规范描述不一致的情况，以那份可实现算法为准，因为它才是真正被执行的那一套。

转写为什么比看起来危险？

一门语言常常有好几套转写标准

转写听起来像个确定的操作，实际上远不是。

同一门语言往往同时存在好几套互不兼容的转写方案。

国际标准一套、地名机构一套、护照系统又一套。

各国的国家标准还会再来一套，媒体有自己的习惯写法。

同一个字母在不同方案里转出来的拉丁形态完全不同。

你选了哪一套，只有你自己知道，外面的人不知道。

问题的严重程度可以这样估：如果某个字母有三套常见转写，一个含两个这类字母的词就有九种可能的拉丁写法。你的地址只占其中一种，剩下八种如果有人写成外链，全部落在不存在的地址上。这不是理论风险，做过俄语和阿拉伯语市场的都遇到过。

方案多还带来一个内部管理问题，就是不同部门可能各自选了不同的方案。技术团队按国际标准生成地址，市场团队按媒体习惯写素材，客服按证件方案回答用户，三套并行且互不知情。上线前把选定的方案写进一份所有人都能看到的规范，比事后统一便宜得多。

那些分歧最大的字母

分歧集中在少数几个音上，而它们恰好都是高频字母。

西里尔字母里发擦音的那几个是重灾区。

同一个字母能被转成一个字母、两个字母或者带记号的形态。

还有的方案用两个字母，另一个方案用四个字母。

做词表时，这几个字母出现在词里的概率相当高。

换句话说，受影响的不是个别词，是相当大一部分词。

应对办法不是选一套最好的，而是先统计自己的词表里含这些高分歧字母的比例。比例低的话随便选一套都行；比例高就必须做多套并存加跳转，因为无论选哪一套都会漏掉大半的外部写法。这个统计用一段简单的字符匹配就能跑出来。

统计的时候要按加权算而不是按词数算，用每个词的搜索量或者页面流量做权重。含高分歧字母的词如果都是长尾，影响面比看着小；如果集中在头部词上，哪怕比例不高也必须做多套并存，因为损失全落在最值钱的那批流量上。

有官方一一对应的语言风险低得多

不是所有语言的转写都这么乱，有几门语言运气很好。

关键的判据是这门语言有没有官方的一一对应拉丁正字法。

塞尔维亚语就有，联合国给它的罗马化方案里两套字母严格一一对应。

每个西里尔字母只对应一个拉丁形态，反过来也一样。

这种情况下转写是确定的，外部写法不会分叉。

俄语没有这种对应，同一机构给俄语的方案跟其他几套并存，阿拉伯语和泰语同理，风险高得多。

这条判据可以直接当决策的第一道闸：有官方一一对应正字法的，转写路线安全，可以放心用；没有的，要么走本地字符路线，要么做多套并存。判断办法是查这门语言的官方语言机构或者地名罗马化系统的现行文件，看它是不是给出了完整的双向对应表。

即使有官方一一对应正字法，也要确认一件事，就是这套对应表里有没有用到带记号的拉丁字母。如果有，那些字母在地址里又要面对折叠的问题，等于把风险从转写层转移到了折叠层。真正低风险的是那些对应表全落在基本拉丁字母上的语言。

外链会落在哪一套上不由你决定

这是转写路线最难受的一点，你控制不了外部写法。

本地媒体写你的品牌名和商品名时，用他们习惯的转写。

论坛用户手打地址时，按自己的键盘习惯来。

国际媒体可能用国际标准，本地媒体用国家标准。

这些写法都不是你的地址，全部落在四百零四上。

你只能事后发现，然后一条条做跳转补救。

正确的做法是提前建一张变体表：把每个高分歧字母的全部常见转写列出来，组合生成主要变体，全部预先配好跳转指向正确地址。这件事在上线前做只要几个小时，上线后再补要一条条从抓取报告里捞，成本完全不同。

变体表的规模是可控的，因为高分歧字母只有几个，而且不是每个词都含它们。实际生成出来通常在几百到几千条量级，用一条带模式匹配的跳转规则就能覆盖，不需要一条条写。规则要放在服务器配置里而不是应用层，这样不占应用的处理开销。

折叠变音符号会撞出什么？

两个不同的词折成同一个

还有一条中间路线，就是保留拉丁字母但去掉变音符号。

这条路线看着最省事，实际上有个致命的碰撞问题。

捷克语和斯洛伐克语分家之后的选词差异里提到的两个词，去掉记号之后拼写完全相同。

一个是形容词的阴性形式，另一个是表示序列的名词。

它们折叠之后都变成同一串字母，地址会撞车。

克罗地亚语跟斯洛文尼亚语的字母表差异、越南语带调与不带调的两拨人那边都有大量类似的对子。

碰撞的处理办法有三种：给后来的加后缀、把碰撞的两个词合并到一个页面、或者对这批词保留记号走百分号编码。第三种最干净但会让地址风格不统一，第一种最常用但要保证后缀规则稳定，不能这次加数字下次加单词。选定一种就写进规范，别每次临时决定。

碰撞还有一种更隐蔽的形式，就是折叠之后跟一个已存在的英文单词撞上了。这种撞车在功能上不报错，但会让地址的语义变得莫名其妙，也可能让引擎误判页面的语言。检测时把英文常用词表也加进比对范围，能提前发现这类情况。

折叠规则是按语言定的

更麻烦的是折叠本身没有唯一正确答案。

德语的变音字母正确的折叠是加一个字母，不是去掉记号。

把它简单去掉记号，得到的词在德语里是错的。

土耳其语一个词后面挂五层后缀那边还有个陷阱，无点字母不能折成普通的那个字母，那是另一个音。

匈牙利语的长元音字母折成短元音还是加字母，也有分歧。

所以折叠表必须按语言存一份，不能全站共用一个函数。

验证自己的折叠表对不对有个便宜办法：找二十个包含变音字母的当地高频商品词，折叠之后拿去做站外的精确匹配查询，看返回的结果是不是同一个概念。折叠错的词返回的结果会明显跑偏，二十个词跑完不到半小时。

折叠表还要跟站内搜索的处理保持一致。如果地址生成用的是一套折叠规则，站内搜索的模糊匹配用的是另一套，用户从搜索结果点进来可能落到不存在的地址上。两处共用同一份配置是最省事的做法，也是最容易被忽略的一致性要求。

大小写在两个地方会出问题

网址路径是区分大小写的，这一点比想象中重要。

生成地址时统一转小写，是绝大多数系统的默认做法。

但转小写这个操作在某些语言里不是逐字符的简单映射。

土耳其语的大写点字母转小写之后应该带点，普通规则给的是不带点。

希腊语词尾的西格玛转大写再转回来，形态会变。

这两类错误会让同一个词生成出两个不同的地址。

防这类错误的办法是在转小写时显式指定语言，多数运行时都支持带地区参数的大小写转换。这一行代码的差别会决定土耳其语站上一批地址是对的还是错的，而且错了之后症状很隐蔽：地址能访问，只是跟你词表里的那个不是同一串。

除了这两门语言，还有一类风险来自那些大小写映射不是一对一的字符，比如某些连写字母转大写之后会变成两个字母。这类字符在地址里很少见但确实存在，稳妥的做法是在生成地址时限制字符集合，只允许基本拉丁小写字母、数字和连字符，从根上避开整类问题。

规范化形式也要统一

带记号的字符在编码里可能有两种表示方式。

一种是一个独立的码位，另一种是基本字母加一个组合记号，波斯语同一个词两套码位怎么在索引里对齐讲的是同一类问题。

两种表示看起来完全一样，字节序列却不同。

字节不同，百分号编码出来的地址就不同。

所以生成地址之前必须先按UAX #15的规范化形式做一次统一。

不做这一步，同一个词在不同来源会生成两个地址。

规范化这一步在苹果系统的文件名和某些编辑器里特别容易出问题，因为它们默认用的是分解形式，而多数网页和数据库用的是合成形式。从这类来源导入词表时不做规范化，你会得到一批看起来正确却打不开的地址。

规范化的选择上，网页世界普遍用合成形式，所以地址生成也应该统一到合成形式再做编码。要注意的是有些运行环境的默认行为不是这个，需要显式指定。这一行的默认值差异会导致同一份代码在开发机和服务器上生成出不同的地址，排查起来非常费时间。

排序和去重会在哪里出错？

编码后的串按字节排序

百分号编码之后的地址是纯拉丁字符串。

拿它排序，得到的是按字节顺序的结果。

字节顺序跟这门语言的字母顺序基本没有关系。

报表里按地址排序看数据，顺序会显得毫无逻辑。

要按语言顺序排，得先解码再用语言相关的排序规则。

这一步在多语言站的报表里经常被漏掉。

影响不只是好看不好看。按错误顺序排的报表会让人误判分布，比如以为某一类地址集中在某个区段，实际上那只是字节序造成的错觉。做地址结构审计时，先解码再排序是必须的一步。

排序还有一个实际场景会受影响，就是站点地图和地址清单的人工核对。按字节序排出来的清单，同一个分类下的地址会散落在各处，核对时很容易漏看。做核对用的清单一定要先解码再按语言排序，或者干脆按目录层级分组之后再排。

去重要在解码之后做

去重同样有个顺序问题，容易搞反。

同一个地址可能以编码和未编码两种形态出现在数据里。

直接对字符串去重，两种形态会被算成两条。

正确做法是先统一解码并规范化，再去重。

不这么做，抓取统计和收录统计的数字会虚高。

虚高的比例取决于数据来源的混杂程度，有时相当可观。

还有一层更隐蔽的重复，就是百分号后面的十六进制字母有大小写两种写法。规范建议用大写，但很多工具生成小写，两者指向同一个地址却是不同的字符串。去重之前统一成一种大小写，这一条经常被漏掉。

还有一类重复来自尾部斜杠和默认文件名，这跟字符编码无关但会跟它叠加出现，让重复的形态组合变多。去重的规范化步骤应该把这几项一起处理：统一大小写、统一解码、统一规范化形式、统一尾部斜杠，四项一次做完再比对。

同形字符会伪装成合法地址

还有一类问题跟安全相关，也影响地址设计。

不同文字系统里有一批字符长得几乎一模一样。

拉丁字母和西里尔字母之间就有十几对同形字符。

用它们能构造出视觉上完全一样的假地址。

浏览器为此对本地字符域名的显示做了限制。

混用两种文字的域名，很可能被强制显示成编码形态。

这一条直接影响本地字符域名路线的可行性：如果你的品牌名里同时含拉丁字母和本地字母，浏览器可能拒绝把它显示成好看的形态，那么本地字符域名最大的优势就没了。上线前用主流浏览器各试一遍显示效果，别只在一个浏览器里看。

同形字符的问题在路径部分同样存在，只是不像域名那样有浏览器帮你拦。如果你的地址里允许出现多种文字的字符，理论上可以构造出视觉相同但实际不同的路径，用来做钓鱼或者混淆内部链接。限制地址的字符集合是最简单的防线。

怎么在四种组合里选一个？

先回答四个问题

选择的输入是四个可以直接查的事实，不是偏好。

第一个问题，这门语言有没有官方一一对应的拉丁正字法。

第二个问题，你的外链主要来自本地媒体还是国际来源，这跟两个市场的关键词表一样而落地页要拆成两种是同一类市场判断。

第三个问题，品牌名本身是拉丁字母还是本地字母。

第四个问题，站上有没有已经积累了流量的存量地址。

四个答案凑齐，选项通常只剩一个或者两个。

四个问题的权重不相等，第四个是硬约束，有存量的话讨论空间很小；第一个是决定性输入；第二个和第三个是调节项。按这个顺序问，能避免团队在偏好上争论，因为四个问题的答案都是客观事实，查一下就有。

四个问题之外还有一个软性输入值得记下来，就是团队里有没有人长期负责这门语言。有的话，本地字符路线带来的额外运维成本是可承担的；没有的话，选通用性更好的那条路线更稳妥，因为出问题时没人能快速判断是哪一层的问题。

本地字符路线适合谁

本地字符路线的最大优势是给本地用户的亲和感。

用户在搜索结果里看到自己语言的地址，可信度更高。

地址里的关键词对本地用户是可读的，这点有实际价值。

适合的情形是外链主要来自本地、品牌名本身是本地字母。

不适合的情形是有大量国际来源的外链和分享。

也不适合品牌名混用两种文字的情况。

选这条路线要接受一个长期成本，就是所有涉及地址的运维工作都要多一道解码步骤，包括日志分析、报表制作、外链核对、批量改动。这个成本不高但会一直存在，团队里得有人知道这件事，否则每次换人都要重新踩一遍。

这条路线还有一个容易被高估的好处，就是地址里的关键词。地址里的词对排名的作用本来就有限，加上编码之后在很多场合下不可读，所谓关键词可见的收益主要体现在搜索结果页的加粗上。把这一项当成主要理由去选，通常会失望。

转写路线适合谁

转写路线的优势是通用性，在任何环境里都不出问题。

地址短、可复制、任何客户端都能完整识别。

适合的情形是这门语言有官方一一对应的正字法。

也适合国际来源外链占比高、需要跨市场统一风格的站。

不适合的情形是这门语言的转写方案有多套且分歧大。

选这条路线必须配那张变体跳转表，不然外链会漏掉大半。

转写路线还有一个容易被忽略的好处，就是它让跨市场的地址结构可以保持一致。做多个小语种市场时，一致的结构让模板、日志分析脚本、报表口径全部能共用，这部分节省的工程量在市场数量多的时候相当可观。

转写路线的一个附带要求是转写规则必须写成代码而不是让人手填。手填的地址在几百条以内还能维持一致，到了几千条必然出现同一个字母在不同地址里转法不同的情况，那时候补救比重做还麻烦。上线前就把生成器写好，成本很低。

混合路线怎么划边界

实际做的时候，混合往往是最务实的选择。

常见的划法是目录层用转写，最末一级用本地字符。

目录层是有限的几十个，转写之后稳定又好管。

末级是商品名，数量巨大且本地可读性最有价值。

另一种划法是品类页用本地字符，内容页用转写。

划完之后要写进规范，别让不同的人各自决定。

混合路线的风险在于边界模糊之后会退化成随意混用，那比任何一种纯路线都糟糕。防这个的办法是把规则写成生成器的配置而不是文档里的一段话：地址由程序按规则生成，人不手写，边界就不会漂。

划边界时有个实用建议，让边界跟内容的更新频率对齐。变动少的层级用转写，因为它一旦定下来就长期不动；变动多的层级可以用本地字符，因为反正每次都是新生成的。这样规则的稳定性和可读性的收益各自落在最合适的位置上。

上线前该怎么把这套规则验一遍？

先建一份最难的测试词表

验证的第一步是准备一份专门用来找麻烦的词表。

这份表不用大，三十到五十个词就够，但每个都要有针对性。

把全部高分歧转写字母各找两个真实商品词放进去。

把已知的折叠碰撞对子成对放进去，两个都要有。

把带特殊大小写行为的字母各找一个词放进去。

再放几个含两种表示形式的带记号字符的词。

这份表要跟着代码一起进版本库，每次改动地址生成逻辑都跑一遍，输出结果跟上一次比对。它的价值在于把语言知识固化成了可执行的检查，团队换人之后新人不需要懂那门语言也能验证改动没有破坏什么。

三条必跑的自动检查

光有词表还不够，要配三条能自动跑的断言。

第一条是唯一性，词表里不同的词必须生成不同的地址。

第二条是幂等性，同一个词跑两次必须得到完全相同的结果。

第三条是可逆性，生成的地址解码之后要能还原成预期形态。

三条任何一条不过，都说明生成逻辑里有随机或者有状态。

三条都过，剩下的问题就只是审美和策略问题了。

幂等性这一条最容易被认为是多余的，实际上它挡住了一类很难查的问题：如果生成过程依赖了当前时间、随机数、或者某个可变的全局状态，同一个词在不同时刻会生成不同地址，症状是数据库里悄悄多出一批重复内容而没人知道从哪来的。

真机与真客户端上跑一遍分享

最后一步是模拟用户的实际使用，这步没法自动化。

把几个代表性地址复制出来，往各种客户端里粘一遍。

目标市场常用的即时消息、邮件、社交平台各试一次。

看链接有没有被截断，有没有被识别成两段。

再在手机上点开一次，确认跳转和显示都正常。

这一遍通常半小时能跑完，能发现自动检查发现不了的问题。

测试时要用目标市场真实在用的客户端版本，而不是自己手机上装的国际版。不同地区的客户端在链接识别上的行为可能不一样，尤其是那些本地化程度高的应用。找当地的同事或者用户帮忙点一遍是最靠谱的办法，比在自己这边反复推测有效得多。

已经上线了还能不能改？

先算存量的代价

存量地址的迁移成本是最先要算清楚的一项。

算的方法是把有外链或者有自然流量的地址挑出来数一数。

这批地址每一条都要配跳转，而且要长期保留。

数量不多的话，改动是可行的，几百条跳转不算负担。

数量到了几万条，跳转规则本身会变成一个维护负担。

这时候更划算的做法通常是不改，只对新增内容用新规则。

算存量代价时要注意区分两类地址：有外部链接指向的和只有内部流量的。前者必须永久保留跳转，后者可以在内部链接全部更新完之后逐步下线。两类的比例决定了跳转规则表的长期规模，这个数才是真正的成本。

算代价时别忘了把内部依赖也数进去，包括邮件模板里的链接、广告投放的落地页地址、第三方平台上填的站点链接、以及各种文档和截图。这些地方的地址不会自动更新，改地址之后要一处处去改，数量往往比想象中多，有时比跳转规则本身更费时间。

新旧并存要有明确边界

决定不改存量的话，新旧并存的边界要写清楚。

最省事的边界是按目录切，某个目录下全部用新规则。

按时间切也可以，某个日期之后新建的内容用新规则。

最糟的是没有边界，同一个目录下两种风格混在一起。

混在一起的后果是没人知道该按哪套写，规范形同虚设。

边界写在生成器的配置里，比写在文档里可靠得多。

并存状态下有一件事必须做，就是在内部链接里全部指向新地址，一个旧的都不留。跳转是给外部用的，内部链接还指着旧地址会白白消耗抓取，也让报表里同时出现两套地址，分析时要额外做合并，纯属自找麻烦。

并存期间还要处理站点地图，新旧两套地址不能同时提交。只提交新地址，旧地址靠跳转承接外部流量就够了。同时提交的后果是引擎会把两套都当成有效地址去抓，白白消耗抓取额度，在小语种站上这份额度本来就不多。

什么情况值得下决心改

有三种情况改动的收益明显大于成本。

第一种是当前地址里的转写选错了标准，外链大面积落空。

第二种是折叠碰撞已经造成了地址冲突，功能上有问题。

第三种是大小写处理有错，同一个词有两套地址在跑。

这三种都是功能性缺陷，不改的话问题会持续累积。

纯粹为了风格统一而改，通常不值得。

判断属不属于这三种的办法是看它有没有产生正在流失的流量或者正在增长的重复。有，就是功能缺陷该改；只是看着不顺眼，就留着。改地址的隐性成本在于它会打断你对历史数据的连续观察，这个代价在评估时经常被低估。

如果确实要改，改动的时机也有讲究，避开流量高峰和大促期间，选一个数据平稳的时段。这样迁移期的波动能跟正常波动区分开，你才判断得出改动本身有没有引入新问题。在大促前改地址是最糟糕的选择，出了问题连归因都做不到。

哪些不归语言层，要交出去？

地址结构本身是架构层的事

目录分几层、参数怎么处理、路径怎么组织，都不在这一篇里。

那些决策跟语言无关，换成英语站一样要做。

URL结构与slug命名的七维设计与上线后铁律已经把这部分讲透了。

本篇只处理一件事，就是字符该用哪一套写。

两件事的交集只在生成地址的那一个函数里。

把边界划清楚，讨论才不会互相干扰。

实操上的接口是这样：架构层给出地址的骨架，也就是有几段、每段是什么语义；语言层决定每一段里的字符怎么写。两层的输出拼起来才是完整的地址生成规则，任何一层缺失都会让规则不可执行。

两层的职责分开之后，还要约定一件事，就是谁来维护那个生成函数。放在架构那边容易忽略语言细节，放在内容那边容易改坏结构。比较稳的做法是函数由技术方维护，但语言相关的配置表由懂那门语言的人维护，两者用配置文件解耦。

多语言的地区定位归另一层

一个站怎么向引擎说明哪个页面给哪个市场，是另一套机制。

那套机制跟地址里用什么字符没有关系。

本地字符的地址不会自动让引擎认为这是给本地市场的。

反过来，拉丁转写的地址也不会削弱地区定位。

把地址里的字符当地区定位信号用，是个常见误解。

地区定位有专门的标记方式，跨语言的实体对齐那一层也各有各的信号，靠地址传信号不可靠。

这个误解会导致一个具体的错误决策，就是为了地区定位而强行用本地字符地址，付了成本却没有收益。真正影响地区定位的是语言标记、地区标记和服务器所在地这几项，地址里的字符至多是一个很弱的辅助信号。

还有一个相关的误解是以为本地字符地址能提升本地搜索引擎的偏好。就已知的公开信息看，各引擎并没有把地址字符当作地区偏好的依据。真正起作用的还是那几项显式信号，与其在地址上做文章，不如把那几项配对配全。

转写在页面内容里是另一个问题

本地字符和拉丁转写并存的问题，在页面内容里也存在。

但内容层的处理跟地址层完全不同，不能套用同一套结论。

内容里两种写法可以同时出现，地址只能选一种。

内容层要做的是覆盖两批用户的查询习惯。

希腊字母与拉丁转写并存时怎么覆盖和用哪套字母写商品名比写了什么更决定谁能搜到讲的就是内容层的做法。

本篇只管地址，两者的结论不要混用。

混用会犯一个具体的错：因为内容层要覆盖两套写法，就以为地址也要做两套。地址做两套的代价是重复内容和抓取浪费，而收益几乎为零，因为用户不会手打地址。地址只需要一套加上必要的跳转就够了。

内容层和地址层唯一需要联动的地方是站内搜索：用户可能用两种写法搜同一个东西，而站内搜索最终要把他导到唯一的那个地址上。所以内容层的同义词表要包含两种写法，而地址层保持单一形态，联动点就落在这张同义词表上。

常见问题解答

本地字符的网址会不会影响排名

就排名机制本身来说，两种写法没有系统性的高低差别，引擎两种都能正常抓取和索引。真正会产生影响的是间接因素，而且这些因素有正有负。正面的一侧是本地用户在搜索结果里看到自己语言的地址时点击率可能更高，尤其是地址里含有他刚才搜的那个词的时候，加粗显示会更明显。负面的一侧主要是外链，如果这门语言的转写方案有多套，或者本地字符地址在某些客户端里被截断，外链的实际获得量会低于应有水平，这一项的长期影响可能比点击率那点收益更大。所以判断该用哪种写法，正确的问法不是哪种排名好，而是在自己这个市场的具体条件下，哪种写法的外链损耗更小、点击收益更大。两个数都可以粗略估出来：外链损耗看高分歧字母在词表里的占比，点击收益看目标词在地址里出现的比例。还有一个常被忽略的细节，本地字符地址在搜索结果里的显示长度按解码后的字符数算，比编码形态短得多，所以担心地址太长而在结果页被截断这件事其实不用太在意，真正吃亏的地方还是外链和分享。

已经用了本地字符地址，要不要全部换成转写

默认答案是不换，除非属于三种功能性缺陷之一。三种缺陷分别是转写标准选错导致外链大面积落空、折叠碰撞导致地址冲突、大小写处理错误导致同一个词有两套地址在跑。这三种不改的话问题会持续累积，越晚改代价越大。如果不属于这三种，只是觉得地址太长或者风格不统一，那么改动的收益很难覆盖成本。成本包括跳转规则的长期维护、历史数据连续性的中断、内部链接的全量更新，还有迁移期间不可避免的一段流量波动。一个折中做法是不动存量，只对新增内容用新规则，同时把边界写进地址生成器的配置里而不是写在文档里，这样并存状态是受控的而不是失控的。并存期间有一条必须守住，内部链接全部指向新地址一个旧的都不留，否则报表里会一直有两套地址需要人工合并。另外提醒一点，如果决定不改，就把这个决定和理由写进规范存档，否则半年后来的新人会重新提出同样的问题，团队又要把这一轮讨论完整跑一遍，而那份讨论并不会产出新的信息。

怎么知道外链落在了哪一套转写上

三个地方能看到。第一个是四百零四的日志，把这批请求的地址导出来，做一次模式归类，你会看到明显聚集的几种写法，那就是外部实际使用的转写方案。第二个是站长工具里的抓取错误报告，它会列出被引用但不存在的地址，还能看到引用来源，比日志多一层信息。第三个是主动去搜自己的品牌名和主要商品名的各种转写形态，看有没有别人写的链接指向不存在的地址。三个来源合起来能覆盖绝大多数情况。发现之后的处理很直接，给每种常见变体配一条跳转指向正确地址。要注意跳转要用永久跳转而不是临时跳转，这样外链的权重才能传递过去。还有一点，做完跳转别忘了统计一下这批变体带来的流量占比，如果占比高得离谱，说明你选的那套转写跟当地习惯不一致，值得考虑把主地址换成主流的那一套。补跳转之后要在抓取报告里持续盯两三个月，看有没有新的变体形态冒出来。外部写法会随着新媒体报道和新论坛帖子而增加，变体表不是一次性交付物，它需要跟着外链的增长慢慢补全。

折叠碰撞怎么系统性地检测出来

方法很机械，跑一遍就有结果。把全部要生成地址的词导出来，对每个词执行你的折叠函数，把折叠结果作为键做一次分组统计，任何一个键下面有两个以上不同的原词，就是一处碰撞。这个脚本几十行就能写完，跑一次几秒钟。检测出来的碰撞按处理方式分三类：如果两个词其实是同一个概念的不同形态，合并到一个页面；如果是两个不同的概念，给后来的那个加后缀或者对这批词保留记号走编码形态；如果其中一个是低价值的长尾词，直接不给它单独页面。这个检测要放进上新流程里定期跑，因为碰撞是随着词表增长而出现的，上线时没有不代表以后没有。特别提醒一点，检测要用完整的词表包括商品名，而不只是分类名，商品名的数量级大得多，碰撞几乎必然会出现在那里。检测脚本的输出要留档，每次跑完把碰撞对子记下来，因为同一批碰撞可能在不同的上新批次里反复出现。有历史记录的话，第二次遇到直接套用上次的处理方式，不需要重新判断该合并还是该加后缀。

百分号编码的地址在报表里全是乱码怎么处理

那不是乱码，是正常的编码形态，只是不可读。处理办法是在数据进入报表之前加一道解码步骤，把地址还原成可读形态再展示。解码之后要再做一次规范化，把带记号字符的表示形式统一，否则同一个地址可能出现两行。做这一步的时候顺手把百分号后面十六进制字母的大小写也统一掉，很多工具生成小写而规范建议用大写，两种写法指向同一个地址却是不同的字符串，不统一的话去重会失效。这道处理最好做在数据管道里而不是让每个人在自己的表格里手工转，手工转的问题是每个人的转法不一样，做出来的报表口径对不上。还有一个实用建议是在报表里同时保留编码形态和解码形态两列，编码形态用来跟日志和其他系统对接，解码形态给人看，两列都有的话任何场景都不用临时转换。管道里加解码这一步还有一个附带收益，就是解码之后的地址可以直接跟内容管理系统里的标题做匹配，报表里能同时显示地址和页面标题，看数据的人不必再去后台查这个地址是哪个页面，效率提升相当明显。

转写有多套标准的语言，该选哪一套当主地址

选的依据不是哪套标准更权威，而是当地人实际写的时候用哪一套。判断办法是找当地的主流媒体和大型平台，看它们在写这类词的拉丁形态时用什么方案，取占比最高的那一套。这个统计不需要多大样本，看二三十个真实例子就能看出倾向。选定之后，把其余常见方案的变体全部生成出来配好跳转，这一步不能省。有一种特殊情况需要单独考虑，就是护照和身份证件上使用的转写方案，如果你的业务涉及用户填写姓名和地址，那么表单和地址页最好跟证件方案保持一致，因为用户会照着证件抄。这时候可能出现主地址用媒体主流方案而表单提示用证件方案的情况，看起来不一致但各有各的道理，写清楚在规范里就行，别为了表面统一强行合并成一套。选定方案之后建议做一次小规模验证，拿十个用主流方案转写的词去搜一下，看有没有别的站已经在用这套写法做同类内容。如果有，说明这套方案在当地确实通行；如果一个都没有，值得回头再确认一次统计样本是不是取偏了。

本地字符域名值不值得注册

先分清两件事，注册和使用是两个决策。注册通常值得，因为成本低而且能防止别人抢注造成品牌混淆，尤其是那些跟你现有域名视觉上接近的形态。使用就要谨慎得多，因为主域名一旦定下来改动代价极大。使用本地字符域名的前提有三条：品牌名本身是本地字母而不是拉丁字母、外链主要来自本地来源、品牌名里不混用两种文字系统。第三条特别容易踩，混用文字系统的域名很可能被浏览器强制显示成编码形态，那样本地字符域名最大的优势就没了，而且看起来还很可疑。稳妥的做法是主域名用拉丁字母，本地字符域名注册下来做跳转，同时在路径层面决定要不要用本地字符。这样既拿到了品牌保护，又不用承担主域名的风险。真要把本地字符域名作为主域名，上线前务必在目标市场的主流浏览器上各试一遍显示效果，不能只在一个浏览器里看。最后补一条注册层面的实用建议，除了本地字符形态，把常见的几种转写形态也一起注册下来做跳转。这批域名单价不高，但能同时挡住抢注和用户手打时的猜错，属于花小钱省大事的一类支出，值得在预算里单独留一笔。

权威参考资料