波斯语和阿拉伯语共用一套字母，伊朗人常打的那四个字母阿拉伯语里没有

摘要：波斯语借用了阿拉伯字母，但它是印欧语系的语言，语法、构词和词汇跟阿拉伯语都不是一回事。字母表里多出四个阿拉伯语没有的字母，两个常用字母各有两套码位，数字还是另一组符号，词里又夹着一个既不是空格也不是连写的半连接符。这四件事决定了阿拉伯语的词表在伊朗市场用不了。这篇把它们逐条讲清楚。

共用一套字母，为什么关键词表不能共用？

同一批字形背后是两个不同的语系

波斯语属于印欧语系，跟英语、德语、俄语是远亲。

阿拉伯语属于闪含语系，构词方式建立在三辅音词根上。

两者的亲缘距离，大约相当于英语和汉语之间的距离。

共用字母这件事，性质上跟越南语用拉丁字母写是一样的。

没有人会因为越南语用拉丁字母就拿英语词表去做越南语。

可换成阿拉伯字母，这个错误几乎每个团队都会犯一次。

犯错的根源在于视觉判断走在了语言判断前面。两段文字长得像，人的第一反应就是它们是一回事，而拉丁字母的世界里大家早就习惯了同一套字母写几十种语言，唯独换到这套字母就忘了。做阿拉伯语的选词与布局攒下的经验，能带过来的只有书写方向那一部分。

有个反向的例子能帮着记住这件事：土耳其语在近百年前用的也是这套字母，改用拉丁字母之后没有人再把它和阿拉伯语混为一谈。可见让人产生错觉的从来是字形，不是语言本身。

借来的是文字，不是词汇和语法

波斯语确实从阿拉伯语借了大量词汇，比例相当高。

但借词进来之后按波斯语的规则活着，不再遵守原来的构词法。

语法上更是两回事：波斯语的动词在句末，名词没有性。

阿拉伯语的动词变位、双数、破碎复数，波斯语一概没有。

所以哪怕两边写着同一个词，它在句子里的形态也可能完全不同。

关键词是短语不是单词，短语的形态由语法决定。

举个具体的：一个品类词加一个修饰词，在阿拉伯语里要处理定冠词与格的配合，在波斯语里只需要在两个词之间加一个连接音，而这个连接音在书面上根本不写出来。同一个概念，两种语言的词表条目长得完全不一样。

借词比例高这件事还有个反直觉的后果：它让机器翻译在这两门语言之间的表现看起来不错，因为大量实词能对上。可实词对上不等于短语对上，真正决定搜索能不能命中的恰恰是短语的组织方式。

拿阿拉伯语词表当起点会错在哪几处

第一处是那四个多出来的字母，阿拉伯语词表里根本不会出现。

第二处是两个常用字母的码位不同，字符串比对直接失效。

第三处是数字形态，两边用的是不同的一组符号。

第四处是半连接符，波斯语大量使用，阿拉伯语基本不用。

第五处是借词的意思漂移，同形词未必同义。

五处叠加下来，能直接复用的条目通常不到两成。

更划算的做法是把阿拉伯语词表只当作品类结构的参考，也就是用它来确认要做哪些类目、类目之间是什么关系，具体的词一个都不抄。结构这一层跨语言是稳定的，词那一层跨语言几乎全要重来。

这五处里前三处是字符层的、后两处是语义层的，排查顺序必须是先字符后语义。字符层没理干净的时候去讨论词选得对不对，会被一堆看起来重复实际不同的条目干扰，判断全乱。这个顺序在早年编码遗留的排查里也是同一条。

那四个多出来的字母会在哪些环节出事？

四个字母各自对应什么音

波斯语里有四个音，阿拉伯语的音系中不存在。

它们分别是清双唇塞音、清塞擦音、浊擦音和浊软腭塞音。

用拉丁转写大致写作p、ch、zh、g这四组。

为了写出这四个音，波斯语在原有字母上加点造了四个新字母。

造字的方式很朴素：在最接近的那个字母下面或上面加三个点。

这四个字母在阿拉伯字母的码表里有各自独立的码位。

加点造字这件事本身值得记一笔：它意味着这四个字母跟它们的原型字母在字形上极其接近，只差点的数量和位置。手写体、低分辨率屏幕和粗字重下，人眼分辨都有困难，机器如果做了过度宽松的模糊匹配，也会把它们混起来。

知道它们是加点造出来的还有个实用价值：做模糊搜索或者拼写纠错时，绝对不能把点的差异当成可忽略的噪声。有些通用的纠错库会做这种简化，用在波斯语上会把四对完全不同的词混成一对。

品类词里带这四个字母的比例

这四个音在波斯语的常用词里出现频率很高。

随便挑一批日常品类词，带这四个字母的能占到三到四成。

自行车相关的词里尤其密集，因为不少是近代外来词。

外来词进入波斯语时，这四个音正好是最常需要的。

换句话说，越是现代品类，踩中这四个字母的概率越高。

做电商的类目词，基本躲不开。

这条可以直接拿来做一次快速自查：把现有的波斯语词表导出来，统计带这四个字母的条目占比。如果这个比例明显低于三成，那多半说明词表是从阿拉伯语那边翻过来的，或者是机器转换时把这四个字母替换成了原型字母。

顺带说一句，这四个字母在人名和地名里出现得更密集。如果站上有本地作者署名、门店地址或者配送区域列表，这些字段同样要纳入检查范围，它们常常是从别处导入的，最容易保留错误的替代写法。

输入法与老系统里的替代写法

早期的编码方案和键盘布局不一定包含这四个字母。

那个年代的通行做法是用最接近的原型字母代替。

清双唇塞音写成浊双唇塞音，浊软腭塞音写成小舌音。

这些替代写法留在老内容、老数据库和老用户的习惯里。

今天仍然有一部分查询是用替代写法打出来的。

比例不高，但在长尾词上足以影响判断。

处理的原则跟处理任何一种历史写法一样：在匹配层做等价折叠，在展示层只用规范写法。千万不要为替代写法单独建页面，那等于把一个本来就小的量再切一刀，两边都做不起来。

要摸清替代写法在自己市场的实际占比，最可靠的来源仍是站内搜索日志。把规范写法和替代写法各数一遍，比例通常在几个百分点，看着不多，但换算成绝对量在大类目上并不小。

排序与索引里这四个字母排在哪

按码位排序，这四个字母会落在字母表的末尾附近。

按波斯语的正字法排序，它们各自紧跟在原型字母后面。

两种排序给出的结果完全不同。

字母索引导航、按名称排序的商品列表，都会受影响。

解决办法是排序时用本地化的比较规则，不要用字节比较。

这跟任何一门有扩展字母的语言遇到的问题是同一类。

验证方法很直接：造一组只在这四个字母上有差别的词，按你的系统排一遍，看它们是紧挨着原型字母还是被甩到最后。这个测试三分钟能做完，却能拦住一整类用户找不到商品的投诉。

排序规则的差异还会影响分页。按名称排序的类目页如果排序规则前后不一致，同一件商品可能在两页里都出现或者两页里都不出现，这类问题在抓取时表现为页面内容不稳定，比排错顺序本身更麻烦。

同一个词两套码位，怎么在索引里对齐？

两个常用字母各有两个合法码位

波斯语里有两个字母，跟阿拉伯语的对应字母长得几乎一样。

但它们在编码里是两个不同的字符，各占各的码位。

一个是词尾形态有没有两个点的差别，一个是字母末端笔画的差别。

视觉上，在很多字体里这两对根本看不出区别。

编码上，它们是彻底不同的字符，比对时不相等。

这就是波斯语内容里最隐蔽也最普遍的一个坑。

为什么会有两套并存，原因在历史：早期的编码方案里波斯语被当作阿拉伯语的一个变体处理，直接沿用了阿拉伯语的码位；后来标准里补上了波斯语专用的码位，可老内容和老输入法并没有跟着改，两套就这样一直共存到现在。

这个坑之所以特别难缠，是因为它同时满足三个条件：视觉上不可分辨、编码上完全不等、出现频率极高。三个条件里去掉任何一个，问题都会容易得多，而波斯语这两对字母恰好三个都占齐了。

用户实际打出来的是哪一套

取决于他用的键盘布局，而键盘布局的分布相当分散。

系统自带的波斯语键盘通常输出波斯语码位。

某些第三方输入法和老设备输出的是阿拉伯语码位。

从网页上复制粘贴过来的文字，带的是原页面用的那一套。

所以同一个用户在不同场景下打出来的可能不是同一个字符串。

这件事他自己完全无法察觉，因为看起来一模一样。

拿自行车这个词做例子：它的常见写法里正好含有其中一个有争议的字母，于是站内搜索日志里会出现两条看着完全相同的记录，各自带着一部分搜索量。把它们分开统计，任何一条都显得没什么需求。

后台编辑同样是污染源。运营从供应商文件里粘贴商品标题，粘进来的是文件里那一套码位；自己手打的又是键盘那一套，同一个类目下的商品标题因此可能带着两种字节形态，页面上看起来完全一致。

有个办法能量出污染的程度：把商品标题字段整体导出，按两套码位分别统计出现次数。两边都有相当数量，就说明数据已经混了，此时先做一次全量清洗再上线映射层，比只做映射层干净得多。

归一化要放在哪一层

标准里的归一化处理不解决这个问题，因为这两对不是等价字符。

标准归一化管的是同一个字符的不同表示方式，比如组合与预组合。

波斯语这两对属于不同的字符，归一化的适用范围覆盖不到。

所以必须自己写一层映射，把阿拉伯语码位映射到波斯语码位。

这一层要放在最靠近入口的位置，请求进来立刻处理。

入库、检索、比对全都用映射之后的形式。

顺便把常见的兼容字符一起处理掉：某些老内容里会出现呈现形式区的字符，也就是把字母的连写形态当成独立字符存起来的那种写法，这类字符看起来正常但完全无法匹配，映射表里加两行就能一并解决。

映射的方向要定下来并写进文档：统一往波斯语码位映射，而不是反过来。方向不一致会造成两个模块各映射各的，最后又对不上。选波斯语码位作为规范形态的理由是它才是这门语言的正式编码。

地址、文件名与数据库的连带影响

如果地址里用了本地字符，两套码位会生成两个不同的地址。

两个地址内容相同，等于自己给自己造了重复。

文件名同理，图片路径里带波斯语字母时容易出这个问题。

数据库的排序规则如果不区分，查询结果又会不一致。

最稳妥的做法是地址与文件名一律用转写，不用本地字符。

本地字符只出现在页面内容和标题里，那里的归一化由应用层负责。

已经上线的老地址不要为这个理由去改，收益远小于风险。正确做法是把新增的路径规则改掉，老地址维持原样并确保两套码位的版本之间做了明确的指向，让系统知道哪一个是主版本，这比批量改地址安全得多。

数据库这一侧还要确认排序规则的设置。有些默认的排序规则会把这两对字母视为等价，这在检索时是好事，但会掩盖数据里的不一致，等到换了一套规则或者迁移到别的存储时，隐藏的问题会一次性爆出来。

波斯语的数字为什么跟阿拉伯语长得不一样？

三套数字形态与它们的码位区间

第一套是通行世界的那组符号，用在拉丁文字里。

第二套是阿拉伯语区常用的那组，有自己的码位区间。

第三套是波斯语用的，又是另一个码位区间。

第二套和第三套里，有几个数字的字形明显不同。

四、五、六这三个数字，两套写法差别最大。

其余几个字形相同，但码位仍然不同。

字形相同码位不同这一点特别坑：肉眼校对完全发现不了问题，只有把字符串按码位打印出来才能看见。所以数字相关的排查必须用工具做，靠人眼看两遍不解决任何问题。

另一个容易忽略的细节是这两套数字的排列方向。数字本身在双向文本里属于弱方向字符，一串数字在从右往左的段落里仍然按从左往右读，但它跟相邻符号的相对位置会变，价格加货币符号的组合最容易在这里出问题。

价格、尺码与年份三类字段的分布

价格通常用波斯语数字展示，因为它出现在正文语境里。

技术规格里的尺码往往用通行数字，因为规格表是从供应商那里来的。

年份最乱，两套都有，还要叠加历法的差别。

伊朗使用的历法跟公历不是同一套，年份数值差了六百多。

用户搜某一年的车型时，心里想的可能是本地历法的年份。

这一条在选词时经常被整个忽略掉。

处理办法是在页面上把两种历法的年份都写出来，正文里用本地历法、规格表里注明公历对应，两边都能被搜到。这个做法的额外好处是它顺手解决了促销排期的沟通问题，因为本地团队和总部说的年份根本不是同一个数。

促销活动的时间表是第四类容易出事的字段。本地的节庆按本地历法走，日期每年在公历上的位置都不一样，拿去年的公历日期推算今年的活动周期一定会错开，这个错误在跨时区协作的团队里几乎每年都会犯一次。

展示与查询要分开定规则

展示端按本地习惯，正文和价格用波斯语数字。

查询端全部归一到通行数字再做比对。

筛选器的数值输入两套都要接受。

排序一律按数值排，不要按字符排。

结构化数据里的数值用通行数字，那是机器读的。

两条规则分开定，一条服务人一条服务机器。

还有一处容易漏：小数点和千分位。波斯语区常用的小数分隔符跟通行写法不是同一个字符，用户从别处粘贴过来的价格带着这个符号，直接送进数值解析会静默失败，表现为搜索无结果而不是报错，日志里很难定位。

把这条原则写进模板层最省事：输出数值时统一走一个格式化函数，接收数值时统一走一个解析函数，两个函数各自处理本地化与归一。散在各处手写的话，总会有某个新页面的开发者忘掉其中一半。

半连接符到底是不是空格？

它做什么用、写在哪些位置

波斯语的字母在词内是连写的，前后字母会连成一体。

有些情况下，两部分在语法上是一个词，书写上却不该连起来。

这时就要插入一个零宽度的符号，让连写在这里断开。

它不占宽度，不是空格，但会阻断字母的连笔。

最常见的用法是复数后缀，以及某些动词的前缀。

一个词里出现一到两次是很正常的。

这个字符位于通用标点区，跟其他几个零宽度控制字符放在一起，通用标点的码表里能查到它的确切位置和用途说明。它的存在感为零，删掉之后页面看起来只是字母连到了一起。

需要它的位置是有限且可以穷举的：几个常用的复数后缀、几个动词前缀、少数几类固定构词。把这份清单整理出来大约几十条，是后面所有自动化检查的基础，值得花半天时间做扎实。

三种输入情形的比例

第一种是打对了，插入了这个符号。

第二种是打成了普通空格，视觉上很接近。

第三种是干脆不打，两部分连成一个词。

手机键盘上这个符号通常要长按或者切层才能打出来。

所以移动端第二种和第三种的比例明显更高。

三种写法在搜索日志里是三条不同的记录。

把三种写法的量加起来才是真实需求，这跟移动端输入成本抬高省略率是同一个机制在起作用：只要打出规范形态需要多按一次键，相当比例的用户就会选择不打。

桌面端的比例分布也不是打对占绝对多数。相当一部分用户从来没意识到有这个符号存在，他们的习惯是打空格，因为视觉效果最接近正确形态。所以这不是移动端独有的问题，只是移动端更严重。

分词与匹配层怎么处理这三种

匹配层要把三种写法折叠成同一个键。

折叠的方式是把这个符号和它位置上的空格都去掉。

去掉之后三种输入得到同一个字符串。

但正文和标题里必须用规范写法，不能因为好匹配就不写。

因为不写会影响可读性，也会影响本地用户对页面质量的判断。

匹配宽松、输出规范，这条原则在很多语言里都适用。

要注意折叠不能一刀切：有些位置上的空格是真正的词间空格，去掉会把两个词粘成一个。安全的做法是只对已知会带这个符号的后缀和前缀做定向折叠，维护一份几十条的规则表，比写一条通用规则可靠得多。

规则表的维护有个省事的做法：按后缀而不是按词来写规则，几十条后缀能覆盖成千上万个词。按词写规则的方案看起来更精确，但维护量会随品类扩张线性增长，几个月后就没人愿意更新了。

复制粘贴与后台编辑里的丢失

这个符号在复制粘贴时经常丢失。

某些编辑器会把它当成不可见字符清理掉。

某些表单会在提交时把它过滤成空。

数据库如果按字节截断，也可能把它切掉一半。

丢失之后页面看起来只是连笔多了一点，很难被发现。

写一个检查脚本定期扫一遍，成本很低。

扫描规则也简单：把已知需要这个符号的后缀列成清单，检查这些后缀前面有没有它。发现缺失就报出来人工确认。这类脚本一次写好可以用很多年，比指望编辑手动核对靠谱得多。

富文本编辑器是重灾区，很多编辑器会在保存时做一次内容清洗，把不可见字符当成垃圾清掉。选型时把这一条列进测试用例，粘一段带这个符号的文字保存再读出来，看它还在不在，两分钟能测完。

伊朗用户实际怎么打字、怎么搜？

键盘布局的分裂带来的输入差异

这个市场的键盘布局不止一种，且没有绝对主流。

不同布局对那两个有争议字母的输出不一样。

对那四个专有字母的按键位置也不一样。

对数字形态的默认输出更是各有各的做法。

这三个变量组合起来，同一个词有好几种字节形态。

这是波斯语市场比大多数语言更麻烦的地方。

面对这种分裂，唯一稳妥的策略是把宽容度做在匹配层而不是做在词表上。词表只收规范写法保持干净，匹配层负责把各种变体折叠过来。反过来做的话，词表会膨胀成几倍大且永远维护不完。

这种分裂也解释了为什么这个市场的关键词工具数据格外不可信：工具通常只按一种形态查询，返回的量只是真实需求的一部分。判断需求大小时应该把各种变体的量加起来看，而不是直接采信工具给的单一数字。

拉丁转写在什么场合还会出现

本地用户之间的日常交流里，转写用得不多。

但在品牌名、型号和技术术语上，拉丁写法很常见。

自行车的变速套件型号，几乎没人会去转写成本地文字。

所以商品标题里本地文字和拉丁字母混排是常态。

混排就要处理方向问题，这跟阿拉伯语那边是同一套机制。

混排的坑在窄屏上尤其明显。

这一点跟另一门文字并存拉丁转写的语言不一样：那边是整句都可能被转写，用户会用拉丁字母打整个查询；波斯语这边只有专名和型号用拉丁字母，正文查询仍然是本地文字。覆盖策略因此完全不同。

型号这类拉丁字符串还带来一个连带问题：它们在从右往左的段落里属于强方向字符，会形成一个方向岛，前后的标点跟着走位。商品标题里如果型号后面紧跟着一个句号或者括号，位置很可能跑到你不期望的一端。

移动端的输入成本与查询长度

这门语言在手机上打字，成本比拉丁字母高。

字母形态随位置变化，输入法的候选逻辑更复杂。

加上那个半连接符要额外操作，成本又高一截。

结果是移动端查询更短、更依赖建议列表。

短查询意味着更少的修饰词、更多的品类词直接搜索。

词表要相应地把短词的权重提上来。

可以拿站内搜索日志按设备切开量一次：比较两端查询的平均词数。如果移动端明显更少，说明这个偏移在你的市场成立，值得给高频短词单独准备落地页而不是只做长尾。

建议列表的质量因此格外重要。用户既然更倾向于选而不是打，那么列表里出现什么词就直接决定了最终的查询分布，站内搜索的建议逻辑如果只按历史热度排，会形成一个自我强化的循环，把长尾彻底压住。

从阿拉伯语借来的词，意思真的一样吗？

同形不同义的几类典型

第一类是意思缩小：借来之后只保留了原义中的一个分支。

第二类是意思转移：借来之后用在完全不同的领域。

第三类是语体升降：在一边是日常词，在另一边是书面词。

第三类最难发现，因为词典上两边的释义看起来是一样的。

而语体决定了它会不会出现在搜索框里。

书面词写进标题，搜索量就会低得莫名其妙。

判断语体有个不需要语言能力的办法：把候选词搜一遍，看返回结果里本地零售站和论坛占多少、词典与新闻占多少。后者占多数的基本是书面词，可以放进正文但不该拿去写标题。波斯语词典的词条页能确认释义，但确认不了今天的使用频率。

还有一类更隐蔽的是搭配差异：词本身两边同义，但能跟它组合的词不一样。直译过来的短语单看每个词都对，合在一起本地人不这么说，这类问题词典完全查不出来，只能靠抓真实语料里的相邻组合来发现。

复数形式借来之后被当成单数

阿拉伯语的复数形式在波斯语里经常被整体借用。

借过来之后，说话人未必知道它原本是复数。

于是它被当成单数用，再加上波斯语的复数后缀。

结果是一个词身上带了两层复数标记。

这种写法在正式文体里被认为不规范，在口语里非常普遍。

而搜索框里出现的通常是口语那一种。

这就构成一个典型的取舍：写规范形态显得专业但接不住搜索，写口语形态能接住搜索但可能被本地用户认为不够正式。折中做法是标题用规范形态、正文里自然带出口语形态，两边都覆盖到。

这个现象在其他借用了外来复数的语言里也有，处理思路可以互相借鉴：判断标准不是语法正确与否，而是这个形态在搜索框里出现的频率。语法洁癖在选词这件事上通常会付出流量代价。

品类词里最容易踩的那几个

凡是涉及价格、质量、保证这类抽象概念的词，都要单独验。

这几类词借用比例最高，语体差异也最大。

具体的实物名词反而安全，因为多半是本土词或者近代外来词。

动作类词要小心，购买、配送、退换的常用说法两边不同。

形容词最不稳定，同一个词在两边的褒贬色彩可能不一样。

验的成本不高，一个母语用户两小时能过完一份词表。

验完记得把结论写进一份表里长期保存，标明每个词的语体、频率和适用位置。下一次新增品类时这份表就是起点，不必从头再验一遍，几轮之后它会变成团队最有价值的本地化资产。

还有一类要单独拎出来的是尺寸与规格的单位词。这类词在两门语言里常常写法相同但习惯用法不同，比如用不用缩写、缩写后加不加点，写法差一点就匹配不上，而它们在筛选器里出现的频率非常高。

波斯语的构词与复数怎么影响关键词覆盖？

两套复数后缀，哪一套进词表

波斯语有两个常用的复数后缀，用法有分工。

一个用于有生命的名词，一个通用性更强。

通用的那个用在商品名上更自然。

但两个后缀在实际使用中有交叉，不是严格互斥。

词表里应该以单数为主条目，复数作为变体收录。

因为搜索时用单数还是复数，取决于查询意图而不是语法。

值得单独说的是通用复数后缀要用半连接符跟词干分开写，这就把前面那个坑又叠了一层：一个复数形式可能有打对、打成空格、不打三种写法，再乘上码位的两套，一个词能裂出六种字节形态。这也是为什么匹配层的折叠必须做扎实。

六种字节形态听起来吓人，实际处理起来并不复杂，因为它们经过折叠之后都会收敛到同一个键。真正麻烦的是统计口径：如果报表按原始字符串聚合，一个词的量会被拆成六份，每一份都小到看不出价值。

复合词与连接结构

波斯语用一个连接音把两个名词串起来表示所属或修饰。

这个连接音在标准书写里通常不写出来。

不写出来意味着两个词之间只有一个空格。

所以从字面上看不出来这是一个短语还是两个独立的词。

分词器只能靠词典和统计来判断边界。

这跟复合词粘成一个长词的语言正好相反。

对做词表的人来说，这意味着不能靠形态来判断哪些是固定搭配。只能反过来做：从真实的查询日志和本地站的标题里抓高频的相邻组合，把它们当成固定短语收进词表，这是唯一可靠的来源。

这个特点还影响标题的长度控制。因为短语之间只有空格没有形态标记，标题在视觉上很容易显得松散冗长，本地站的常见做法是把最核心的两三个词放在最前面，后面的修饰成分能省则省。

形容词与名词的顺序

波斯语的形容词放在名词后面，跟英语相反。

山地自行车这个概念，词序是自行车在前山地在后。

直接按英语词序翻译，得到的短语本地人不会那么搜。

这个错误在机器翻译产出的词表里非常常见。

检查办法是看主品类词在短语里的位置。

主品类词应该在前面，修饰词跟在后面。

这条规则还能顺手用来做批量筛查：把词表里所有短语按主品类词的位置分两堆，主品类词在后的那一堆几乎全是有问题的条目，一次能挑出大部分翻译痕迹，比逐条人工看快得多。

词序这件事还会影响标题被截断时的信息保留。主品类词在前意味着窄屏截断时最重要的词能留下来，如果按英语词序写，截断之后留在屏幕上的可能只剩修饰词，用户完全看不出这是什么商品。

本地字符域名与转写并存，地址栏里写哪一套

本地字符域名的实际使用情况

伊朗有自己的本地字符顶级域，早已完成委派。

但它的实际使用率并不高，多数商业站仍用拉丁后缀。

本地字符域名在输入时要切换键盘，成本不低。

用户更多是通过搜索和链接进入，很少手打域名。

所以本地字符域名的价值主要在品牌展示而不是流量。

做不做取决于品牌策略，不影响自然搜索表现。

本地字符域名在技术上是用编码转换成拉丁字符再解析的，这套编码方案的规范规定了转换规则；实际影响是链接被分享出去时可能显示成一串看不懂的字符，社交场景里观感不好。

还有一个现实考量是外部工具的兼容性。不少分析工具、广告平台和第三方服务对本地字符域名的支持并不完整，会把它显示成编码后的形态甚至直接报错，这些摩擦成本累加起来往往超过品牌展示带来的收益。

地址里的路径段怎么写

路径段用转写，理由前面说过：避开两套码位的分裂。

转写方案要在全站统一，写成一份规则文档。

规则要覆盖那四个专有字母怎么转、长短元音怎么处理。

不统一的后果是同一个词在不同页面转写成不同的路径。

路径不一致会让站内结构显得混乱，也不利于人读。

这属于架构层的决策，多语言站的地址结构与语言地区标注那套照做就行。

转写规则里最容易吵起来的是元音。波斯语的短元音在书写里通常不标出来，转写时到底补不补、补哪一个，没有唯一答案。实用的处理是选一套公开的转写方案照抄，别自己发明，这样至少保证一致且可解释。

路径里还要处理那个阻断连写的符号。它是零宽度的，转写时应该当成词的分界处理成连字符，而不是直接删掉。删掉会把两部分粘成一个看不懂的长串，处理成连字符则既可读又跟本地写法对得上。

转写不统一带来的分裂

品牌名的转写不统一，会让外部引用分散到几个写法上。

用户搜品牌名时打的是哪一种，取决于他在哪里见过。

所以要选定一种官方写法并在所有对外场合坚持使用。

其余写法在页面里提一次，让系统知道它们指同一个东西。

这跟任何一门非拉丁文字语言的品牌名处理是同一个问题。

早定早省事，改起来的成本随时间线性增长。

选写法时有一条经验：优先选本地用户自己已经在用的那一种，而不是语言学上最准确的那一种。准确的转写如果没人用，坚持它等于自己给自己制造一个没人搜的词。

选定之后要把这个写法固化到几个地方：站内的品牌名字段、对外的社交账号名、给媒体的资料包、以及商品标题模板。这四处覆盖了外部引用的绝大部分来源，锁住它们基本就锁住了转写的一致性。

一套波斯语词表怎么建、怎么验收？

起点不是翻译，是抓本地站的真实用词

第一步是找出这个市场里排在前面的几个本地零售站。

把它们的类目名称、商品标题、筛选项全部抓下来。

统计高频词和高频组合，这就是词表的原始素材。

这一步完全不需要懂这门语言。

抓下来的词是本地人真实在用的，比任何翻译都可靠。

翻译只在最后一步用来确认这个词是什么意思。

抓的时候顺手记下每个词出现在什么位置：类目名里的偏正式，筛选项里的偏简短，商品标题里的最接近用户说法。三个位置的词性质不同，后面分配用途时直接按这个分类走，省掉再判断一遍。

抓取的对象里别漏掉本地的分类信息站和论坛交易板块。这两类站点的用词比正式零售站更口语化，正好补上零售站偏正式的那一半，两边的词合起来才能覆盖用户的实际说法。这跟另一门书写系统里靠语料反推词形的做法是同一个路子。

六个必查项

第一查那四个专有字母有没有被替换成原型字母。

第二查两个争议字母用的是哪一套码位。

第三查数字形态是否统一。

第四查半连接符该有的地方有没有。

第五查借词的语体是否适合放在标题里。

第六查短语的词序是不是主品类词在前。

六项里前四项可以完全用脚本自动查，写一次能反复用；后两项需要人判断，但有了前四项的自动过滤，人要看的条目会少很多。把这六项做成词表交付前的固定关卡，新语言上线时这类问题基本可以清零。

六项之外还可以加一条软性检查：把词表里每个词丢进搜索引擎看返回结果的类型。返回的多是本地零售站说明这个词在商业场景里活跃，多是词典百科说明它偏书面，这一条不需要语言能力，五分钟能验十个词。

六项检查最好做成提交前自动运行的形式，而不是靠人记得去跑。词表这类资产的特点是改动频繁且改动的人不固定，任何依赖自觉的流程半年内一定会失效，只有卡在流程里的检查能长期生效。

交给谁验、验什么

脚本验编码层，母语用户验语言层，两边分工不重叠。

母语用户要验的只有三件事：这个词本地人说不说、语体对不对、词序自然不自然。

不要让母语用户去查编码问题，他看不出来也不该看。

也不要让脚本去判断语体，它做不到。

两轮验收加起来，一份三百条的词表大约需要半天。

验完的词表要标注验收日期，半年后复验一次。

复验的重点是新增品类和外来词。这两类的说法变化最快，尤其是新进入市场的品类，用户的叫法可能在一年内换一次。老品类的词非常稳定，复验时抽查即可，不必全量重来。

找母语用户时优先找在这个行业里工作过的人，而不是单纯的语言人才。品类词的判断需要行业语感，一个不熟悉自行车的母语者对变速套件的叫法未必比抓来的语料更可靠，这一点在专业品类上尤其明显。

常见问题解答

已经做了阿拉伯语市场，波斯语能不能直接复用词表？

不能，能直接复用的条目通常不到两成。波斯语属于印欧语系，阿拉伯语属于闪含语系，两者共用字母的关系类似于越南语和英语共用拉丁字母，亲缘距离非常远。具体的阻碍有五处：波斯语多出四个阿拉伯语没有的字母，两个常用字母各有两套不同的码位，数字用的是另一组符号，词内大量使用一个阻断连写的零宽度符号，以及借词的意思和语体在两边发生了漂移。这五处叠加下来，字符串层面就已经对不上了，更别说语法和词序的差别。正确的复用方式是把阿拉伯语词表当作品类结构的参考，用它来确认要做哪些类目、类目之间是什么关系，具体的词一个都不抄。结构这一层跨语言是稳定的，词那一层几乎全要重来。判断复用价值时可以先做个小测试：随机挑二十个阿拉伯语词表里的条目丢进波斯语的搜索里，看有多少条能返回本地零售站的结果，命中率通常低得让人意外。

两套码位的问题该怎么彻底解决？

写一层字符映射，把阿拉伯语码位映射到波斯语码位，放在请求进来后的第一时间处理，入库、检索、比对全部用映射之后的形式。注意标准的归一化处理解决不了这个问题，因为这两对字母是不同的字符而不是同一个字符的不同表示，归一化的适用范围覆盖不到。映射表里顺便把呈现形式区的兼容字符也一起处理掉，那类字符看起来正常但完全无法匹配，加两行规则就能解决。放置的位置很关键，越靠后每个经过的模块都要各自处理一遍，漏掉任何一个整条链路就前功尽弃。已经上线的老地址不要为这个理由批量改写，把新增路径的规则改掉、并让系统知道两个版本里哪个是主版本，比大规模改地址安全得多。映射的方向要在文档里写死，统一往波斯语码位靠，否则不同模块各映射各的，绕一圈之后又对不上了。

那个阻断连写的符号，用户不打怎么办？

在匹配层做折叠，同时在页面输出上坚持规范写法。用户的输入有三种情形：打对了、打成普通空格、干脆不打，移动端后两种的比例明显更高，因为这个符号通常要长按或者切换键盘层级才能输入。折叠的做法是把这个符号和相应位置的空格都去掉，三种输入就得到同一个键。但折叠不能一刀切，有些位置的空格是真正的词间空格，去掉会把两个词粘成一个，安全做法是维护一份几十条的规则表只对已知会带这个符号的前后缀做定向折叠。页面上必须用规范写法，因为不写会影响可读性和本地用户对页面质量的判断，匹配宽松、输出规范这条原则在很多语言里都适用。需要这个符号的位置是可以穷举的，整理出来大约几十条后缀和前缀，这份清单是所有自动化检查的基础，值得一次做扎实。

价格和年份该用哪一套数字？

展示端按本地习惯用波斯语数字，查询端全部归一到通行数字再比对，两条规则分开定，一条服务人一条服务机器。筛选器的数值输入要两套都接受，排序一律按数值排不要按字符排，结构化数据里的数值用通行数字因为那是给机器读的。年份要额外注意历法问题：伊朗使用的历法跟公历不是同一套，年份数值差了六百多，用户搜某一年的车型时心里想的可能是本地历法的年份。处理办法是页面上把两种历法都写出来，正文里用本地历法、规格表里注明公历对应。还有一处容易漏的是小数分隔符和千分位，本地常用的符号跟通行写法不是同一个字符，粘贴过来的数字直接送进解析会静默失败，表现为搜索无结果而不是报错。促销活动的时间表也要按本地历法排，拿去年的公历日期推算今年的活动周期一定会错开，跨时区协作的团队几乎每年都会在这里栽一次。

怎么判断现有词表是不是从阿拉伯语翻过来的？

做两个统计就能看出来。第一个是统计带那四个波斯语专有字母的条目占比，正常情况下日常品类词里这个比例能到三到四成，尤其是近代外来词密集的品类更高，如果明显低于三成，多半说明词表来自阿拉伯语那边或者机器转换时把这四个字母替换成了原型字母。第二个是看短语里主品类词的位置，波斯语的形容词放在名词后面，主品类词应该在前修饰词跟在后，如果词表里有一大堆修饰词在前的短语，那基本就是按英语或者阿拉伯语词序直译的。这两个统计都能用脚本做，几分钟出结果，比逐条人工审阅快得多，而且结论很硬，不会有争议。第三个可选的信号是看词表里有没有出现阿拉伯语特有的定冠词前缀，波斯语不用这个前缀，出现了基本就能确认来源。

没有母语同事，词表能不能自己先做出来？

能做出很像样的初稿，最后一步仍然需要人。做法是先找出这个市场排在前面的几个本地零售站，把它们的类目名称、商品标题和筛选项全部抓下来，统计高频词和高频组合，这就是词表的原始素材，整个过程不需要懂这门语言。抓的时候记下每个词出现的位置，类目名里的偏正式、筛选项里的偏简短、商品标题里的最接近用户说法，后面分配用途时直接按这个分类走。编码层的六项检查里前四项完全可以脚本自动完成。真正需要母语能力的只有三件事：这个词本地人说不说、语体对不对、词序自然不自然，一份三百条的词表大约需要母语用户半天时间。初稿做完先跑一遍前四项自动检查再交给母语用户，这样他看到的条目已经在编码层是干净的，注意力能全放在语言判断上，效率明显更高。

波斯语市场的搜索入口跟别的市场一样吗？

入口的分布确实有自己的特点，但那属于引擎层而不是语言层，这一篇讲的是语言本身带来的功课。需要判断在这个市场投哪个入口、各入口的排序规则有什么差别时，那是另一类专门的讨论。放在这里只强调一件事：无论从哪个入口进来，前面讲的字母、码位、数字、半连接符四类问题都同样成立，因为它们是文字系统本身的属性，跟谁来抓取无关。所以正确的顺序是先把语言层的地基打好，再去讨论入口分配。反过来做的话，入口选对了页面却因为字符串对不上而接不住搜索，投入会被浪费掉，而且这类损失在报表里看起来像是入口选错了，很容易得出错误结论。换个角度说，语言层的功课做扎实之后，换任何一个入口这批工作都不用重做，这是它优先级更高的根本原因。

权威参考资料