同一份波兰语词表，在你和同事的两台电脑上打开是两份不同的数据

摘要：一份波兰语关键词表从数据库导出、发给本地顾问、改完再导回来，中间经过的每台电脑都会按自己的地区设置重新解释它一次。逗号分隔文件里没有一处写着自己是逗号分隔的，编码也不自带声明，于是同一份文件在德国同事的机器上会被切成不同的列数，变音字母会被换成问号，型号会被识别成科学计数法。这些改动全部发生在数据库之外，而那段路上没有任何日志。更麻烦的是小语种恰好落在最难发现的那一档：坏掉的只有一小部分字符，坏了之后看着仍像正常的词。

同一份波兰语词表，两台电脑打开连列数都不一样

一个健康器械客户的波兰语词表，交出去一轮就散了

有个客户做健康器械，电子血压计、体脂秤、颈椎牵引器、筋膜枪这几条线。

德国市场先做的，波兰是第二个市场，词表由本地顾问补。

流程看着很正常：从后台导出一份表格，发给顾问，顾问填完发回来，技术导进系统。

一轮走完，波兰站上线，问题在两周后才被发现。

筛选器里出现了几个谁也不认识的取值，商品标题里有两个词中间多了半个方块，还有一个型号变成了一串带加号的数字。

顾问那边很委屈，说他只填了空白列，别的一个字没动。事后复盘证明他说的是实话，那几处损坏没有任何一个是人改出来的。

这条流程在德国市场跑过一轮没出事，所以没人怀疑它。

德语词表里带变音符号的词比例低得多，而且那位德国顾问的电脑地区设置跟导出端恰好对得上，两个巧合叠在一起，让这条链路看上去是安全的。

顺带说一句，波兰这一轮之所以出事，还有一个流程原因：德国那份词表是内部同事填的，波兰这份是外部顾问填的，链路多了一段，而没人重新评估过风险。

谁也没改过内容，可两边的文件确实不同

把两份文件放进比对工具，差异一目了然。

发出去的那份是十二列，收回来的那份被切成了九列。

发出去时写着一个波兰语词，收回来变成了同一个词少了一个字母，那个位置换成了问号。

发出去时是一个横杠连接的区间，收回来是一个日期。

三处变化，三种成因，没有一处经过人的决定，全部是软件在打开和保存这两个动作里自己做的。

还有一处差异当时被忽略了：行序也变了。

顾问按波兰语的字母顺序排了一次，而波兰语的排序规则跟系统默认不一样，于是回来的文件行序整个错开，任何按行比对的工具都会报出满屏差异，反而把真正的三处损坏淹掉了。

比对工具本身也要选对：按字符比对的工具能标出问号那一处，按行比对的工具只会告诉你这一行变了。

三处损坏，三种成因，全都发生在数据库之外

先把结论摆前面，后面几节逐条拆。

列数变化来自分隔符，因为这类文件里没有一处声明自己用什么符号分列。

问号来自编码，因为文本文件不自带编码信息，软件只能猜。

日期来自类型识别，因为表格软件会主动判断一个格子里的东西像什么。

这三件事有一个共同点：它们都不在你的系统里发生，都发生在别人的电脑上，而你连那台电脑装的是什么语言版本都不知道。

第四处成因也常见，只是这次没撞上：文件在压缩传输时文件名被转码，收到的附件名变成一串问号。

文件名不是内容，损坏了不影响数据，但它会让人误以为文件本身坏了，于是干脆重新建一个，把原始那份丢掉。

把四种成因排个序，按不可逆程度从高到低是：编码损坏、自动更正改词、类型识别改值、分列错位，最后一种至少还能靠原始文件重来。

数据库有日志，页面有版本，唯独这段路没有记录

这是这类问题最难缠的地方。

数据库改一条记录，有操作日志。

页面改一段文案，内容库里有版本。

而一份文件在别人电脑上被打开又保存，什么都不会留下。

你手上只有改前和改后两份文件，中间发生了什么只能靠推理，而顾问本人多半也不知道，因为对他来说他只是双击、填空、按了保存。

能留下的痕迹只有一处：文件的修改时间。

而这一处恰好什么也说明不了，因为无论对方做了什么，只要按了保存，修改时间都会更新。

所以这类事故的复盘几乎都要靠重演，而不是靠查记录，重演的成本又高，于是多数团队复盘到一半就放弃了。

顺带把这一篇跟前两篇的关系说清楚：讲合规弹窗那段字不在你的翻译队列里和讲评论的语言不由你决定的那两篇，说的都是页面上不由你产出的文字；这一篇正相反，数据从头到尾都是你自己的，它坏在运输途中。

为什么同一份文件在不同电脑上会变成不同的数据？

逗号分隔文件里，没有一处写着自己是逗号分隔的

这类文件的格式规范其实很短，核心只有几条：一行一条记录，字段之间用逗号，字段里含逗号时用引号包起来。

规范里没有任何机制让文件自己说明用了哪个分隔符。

换句话说，分隔符是约定，不是声明。

只要读的人跟写的人约定不一致，同一份字节就会被切成不同的形状。

这跟本站讲Windows-1251时代的西里尔页面被抓回去的是一串认不出的拉丁字母那一篇的机制是同构的：那一篇讲的是同一串字节被按不同的编码解读，这一篇讲的是同一行文本被按不同的分隔符切开，都是缺少自描述带来的歧义。

规范里还有一条常被忽略：字段内部允许出现换行符，只要整个字段被引号包住。

这意味着一段带换行的商品描述在结构上是合法的，可一旦引号在中途被处理坏，后面所有行的边界都会跟着错位。

顺带一提，字段里含分隔符时要用引号包住，而某些导出功能默认不加引号，这等于把定时炸弹写进了文件。

表格软件用的是系统地区设置里的列表分隔符

关键在这里：表格软件不问你，它读系统设置。

操作系统的地区设置里有一项叫列表分隔符，表格软件双击打开文本文件时用的就是它。

这一项跟界面语言不是一回事，它跟你选的国家或地区绑定。

所以同一台电脑，把地区从一个国家改到另一个，同一份文件的打开结果就变了。

这条设计其实有它的道理：小数点用逗号的地区，再拿逗号当分列符号就会打架。问题只在于没有人在交付文件时想到过对方的地区设置是什么。

更细一点说，这一项在系统设置里跟着国家或地区走，而不是跟着界面语言走。

所以一位用英语界面但地区设成德国的同事，打开结果跟用德语界面的同事完全一样，这也是为什么按界面语言去猜谁会出问题总是猜不准。

顺带一提，在线协作表格没有这一层，因为它的解析发生在服务端，跟你本地设成哪个地区无关。

欧洲多数地区的默认分隔符是分号

具体到数字上，这件事影响面很大。

小数点写成逗号的地区，包括德国、法国、波兰、西班牙、意大利、荷兰、北欧多数国家，列表分隔符默认是分号。

小数点写成句点的地区，包括英美和多数亚洲市场，列表分隔符默认是逗号。

而做欧洲市场的团队，本地顾问、译员、渠道商，绝大多数在第一类地区。

也就是说，你从系统里导出的逗号分隔文件，在这条链上大部分人的电脑里都不是原样打开的，这不是偶发事故，是默认状态。

这条分界跟小数点的写法完全重合，因为它本来就是为了避开冲突而设计的。

记住这条对应关系很有用：凡是把一点五写成一逗号五的地区，它的列表分隔符就是分号。

顺便记住一个反查方法：想知道对方的分隔符是什么，让他在软件里随便存一个两列的文件发回来看看就行。

于是同一份文件在两地打开，列数不同

把机制走一遍就明白那九列是怎么来的。

顾问的电脑按分号切，可文件里没有分号。

于是整行被当成一个格子塞进第一列。

他看到的是一列很长的文本，于是他手动用分列功能重新切了一次。

手动分列时那些本身含逗号的字段就散了，比如一条带逗号的描述被切成两半，列数从此错位。到这一步文件已经彻底变形，而他做的每一步在他看来都是在修复。

更糟的是分列这个动作在他看来是修复，所以他会把修复后的版本存下来发回给你。

于是你收到的不是原始损坏，是一份被人善意加工过的损坏，追查起来比原始损坏难得多。

正确的做法是发现列数不对就退回去要原始文件，而不是自己动手分列，因为分列这一步会把可逆的错误变成不可逆的。

编码这一层，为什么小语种的损坏是不可逆的？

文本文件不自带编码声明

跟分隔符一样，编码也是约定。

一份文本文件里存的只有字节，没有一处写着这些字节该按哪套规则解释。

网页可以在头部声明编码，数据库有字符集设置，唯独裸的文本文件没有。

唯一算得上线索的是文件开头那几个特殊字节，也就是字节顺序标记。

而这个标记本身就是一件有争议的东西：加了它，某些程序会把它当成内容；不加它，表格软件多半会猜错。本站讲记事本存出来的字节顺序标记怎么让网页白屏那一篇讲的就是加了之后的麻烦，这一篇要讲的是不加之后的麻烦。

数据库有字符集设置，网页可以在头部声明编码，接口可以在响应头里写明，唯独裸的文本文件什么都没有。

本站讲Windows-1251时代的西里尔页面被抓回去的是一串认不出的拉丁字母那一篇里讲过没有声明时搜索引擎会怎么猜，表格软件的处境是一样的，只是它猜错之后还会把猜错的结果写回文件。

所以稳妥的做法是在交付说明里把编码写成一句明确的要求，而不是假设对方会用跟你一样的默认值。

双击打开的时候，软件只能猜

猜的依据通常是系统的默认代码页。

波兰地区的默认代码页覆盖的是中欧字母，德国地区的覆盖的是西欧字母。

两者对同一个字节的解释并不一样。

所以一份用通用编码存的波兰语词表，在德国同事的机器上双击打开，那些波兰语特有的字母就落在了西欧代码页覆盖不到的位置。

软件不会因此报错，它会尽力显示：能对上的照常显示，对不上的换成问号或者一个方块。整份文件看起来只是有几个字变丑了，而不是打不开。

顺带说一句，猜的依据在不同操作系统上也不同。

同一份文件在苹果系统的表格软件里打开，行为跟视窗系统并不一致，所以顾问用什么电脑也是一个变量，而这个变量从来没人在交付说明里问过。

所以交付说明里最好直接写清楚用什么软件的什么功能打开，而不是笼统写一句用表格软件打开即可。

猜错的表现是变音字母变成问号或者方块

举个能直接看懂的例子。

德语里的尺码这个词带一个变音字母和一个特殊的双s字母，猜错编码之后就变成两个问号夹在中间。

波兰语里带斜杠的l、带点的z、带尖音符的s和c，都属于这一类。

匈牙利语的长双撇元音、罗马尼亚语的下逗号字母、土耳其语的无点i，同样如此。

这些字母有个共同点：它们都是这门语言里最常用的那批字母，而不是什么生僻符号。一个波兰语词表里带这几个字母的词，占比通常在三分之一以上。

把这批字母数一遍会更有体感：波兰语有九个带变音符号的字母，捷克语有十五个，匈牙利语有九个，罗马尼亚语有五个。

这些字母不是装饰，去掉变音符号之后往往就变成了另一个词，本站讲德语SEO最先卡住的不是技术，是德国人管这东西叫另一个词那一篇里已经算过这笔账。

这也是为什么变音字母在这一层比在别处更要紧：它们不是可选的装饰，去掉之后往往就变成了另一个真实存在的词。

真正致命的是保存那一步，原始字节从此消失

显示错了还有救，保存错了就没救了。

软件把屏幕上显示的那个问号当成真正的内容写回文件。

原来那几个字节被覆盖成问号的字节。

这时候你手上这份文件里，那个字母的信息已经不存在了，任何工具都恢复不出来。

这一条跟本站讲为了让德语长词在手机上不撑破，前端往标题里塞了个看不见的字符那一篇的区别值得说清楚：那一篇讲的是多出来看不见的东西，能靠清洗解决；这一篇讲的是丢掉了本来有的东西，只能回到源头重新取。前者是脏，后者是缺。

还有一个更隐蔽的版本：字母没有变成问号，而是变成了另一个真实存在的字母。

这在两套代码页有部分重叠时会发生，结果是一个拼写合法但意思完全不同的词，连白名单校验都拦不住它。

白名单能拦住变成问号的那一类，拦不住变成另一个合法字母的那一类，后者只能靠母语者抽检。

自动更正会改掉哪些词，为什么专挑外语词下手？

型号被识别成科学计数法

表格软件在你输入或者打开内容时会判断类型。

一串数字加一个E加数字，它认为这是科学计数法。

健康器械这类品类的型号里正好经常出现这种形态。

结果是一个型号变成了一串完全不同的数字，而且原样再也拼不回来。

本站讲平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一那一篇里提过型号这一列的敏感性，这里补一条更早发生的：它在进平台之前，在你自己的表格里就已经被改掉了。

同样的道理也适用于另一个方向：一个格子里如果以等号或者加号开头，表格软件会把它当成公式。

而某些语言的词表里确实有以加号开头的规格写法，打开之后它要么变成错误提示，要么变成一个计算结果。

以等号开头还有一个安全上的老问题，很多系统会在导出时给这类字段加前缀来避免它被当成公式，而那个前缀又会进到你的数据里。

区间写法被识别成日期

这一条在关键词表里出现频率最高。

一个横杠连接的数字区间，比如尺寸区间、重量区间、适用年龄区间。

软件会把它当成日期，然后显示成某月某日。

官方文档里就直接写着这个行为，还给了绕开的办法：先把单元格设成文本格式，或者在输入前加一个空格或撇号。

厂商自己把它当成一个需要解释的常见问题写进帮助文档，说明这件事有多普遍，而它在多语言词表上的后果比在普通表格里严重，因为词表里的每一行最后都会变成页面上的字。

日期识别还有一层地区差异：同一个数字组合，在一个地区被读成三月五日，在另一个地区被读成五月三日。

所以就算你发现了这个问题，回头去看那份文件也未必能推出原来写的是什么。

区间这类写法在健康器械品类里特别多，适用体重、适用年龄、袖带周长，几乎每个商品都有一列。

前导零被吃掉

第三类是数字开头的零。

软件认为这是一个数，而数的前面不该有零。

邮编、条码、内部编号、一部分型号都会中招。

德国和波兰的邮编都有以零开头的，这一条在做地区词表时几乎必然遇到。

厂商同样为这件事单独写了一篇帮助文档，讲怎么保住前导零和长数字，可默认行为并没有因此改变。

条码这一列尤其要小心，因为它既有前导零又足够长，会同时踩中两个坑。

而条码一旦错了，商品在平台侧的匹配会直接断掉，本站讲平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一那一篇里说过，这一列没有容错空间。

检查条码这一列最省事的办法是看长度是否整齐，一整列里突然出现几个短一截的，多半就是被吃了前导零。

拼写自动更正会把外语词改成本地词

最后这一类最隐蔽，因为它改完之后仍然是一个正常的词。

自动更正的词库跟软件的界面语言绑定。

一位用德语界面的同事打开一份波兰语词表，某些波兰语词会被更正成形近的德语词。

这跟本站讲转成小写这一步到了土耳其语站会把词改成另一个词那一篇里的机制是一族：那一篇讲的是同一门语言里的规则在别处不成立，这里是另一门语言的规则被套到了你的词上。

它的可怕之处在于结果完全合法：改出来的是一个真实存在、拼写正确的词，任何校验工具都不会报错，只有母语者读到时会觉得莫名其妙。

还有一类是自动更正的自定义词条：很多人的软件里存着自己加过的更正规则，那是完全个人化的，谁也不知道对方存了什么。

这意味着同一份文件交给两位顾问，回来的结果可能不一样，而原因藏在他们各自的软件设置里。

个人化的更正规则还有个特点：它跟着账号走，换台电脑登录同一个账号，规则也跟着过去。

这些损坏为什么在中文和英文词表上不明显？

英文词表没有变音字母，编码猜错也看不出来

先说英文。

基本拉丁字母在几乎所有编码里的字节都一样。

所以一份纯英文词表，无论按哪套代码页打开，显示结果都一样。

编码这一整类问题，在英文场景下几乎不存在。

这也解释了为什么行业里那些讲表格数据处理的文章几乎不提这一层，它们的默认读者处理的是英文和数字。

顺带补一句：英文场景下真正会出问题的是撇号和长破折号这类排版符号，而它们通常只影响显示，不影响匹配。

所以英文场景下的经验拿到这里通常不适用，那些经验的默认前提是字符本身不会坏。

中文词表猜错是全篇乱码，一眼就发现

再说中文。

中文字符全部落在多字节区间，猜错编码之后是整篇的乱码。

没人会把一屏乱码保存下来接着用。

损坏在第一秒就被发现了，也就不会流到下游。

所以中文场景下这件事的表现形式是打不开，而打不开是一种很好的失败，它至少诚实。

这种失败方式反而是最省钱的，因为它把损失控制在了发现成本上，而不是修复成本上。

本站讲那页规格书在屏幕上是好好的泰语，机器复制走的是另一串字符那一篇里说过同一句话：读到垃圾比读不到更糟，而打不开至少是诚实的。

也正因为如此，遇到整篇乱码时最该做的是原地停下，而不是想办法把它显示出来。

小语种正好落在中间：只坏一小部分，且看着像正常字符

关键差别在这里。

一份波兰语或者德语词表，猜错编码之后大部分内容是正常的。

只有那些带变音符号的字母出问题，而且变成的是问号或者方块这类看着像内容的东西。

文件能打开、能编辑、能保存、能导入，一路畅通。

这跟本站讲那页规格书在屏幕上是好好的泰语，机器复制走的是另一串字符那一篇里的第三类情形是同一种性质：人这一侧看着完好，机器那一侧已经错了，而正因为它看着完好，所以没有任何一个环节会停下来。

占比这个数值得实测一次：把你的波兰语词表跑一遍，数出带变音符号的词占几成。

多数团队跑完会吃一惊，因为这个比例比凭印象估的高，而它直接等于编码损坏时的受影响面。

跑完这个数还有一个用处：它就是后面那条非拉丁字符计数护栏的基准值。

坏得越轻，越难被发现

把三种情况排成一条线，规律就清楚了。

全坏，立刻发现，损失最小。

不坏，无事发生。

坏一点点，能通过所有检查，最后在页面上以怪字符的形式出现在用户眼前。

小语种词表长期处在第三档，这也是为什么这个坑在英文和中文资料里都没人认真写过：写资料的人所在的那两个场景，恰好一个不会坏，一个坏得太明显。

所以这一类问题的正确投入方向不是修复，是把发现成本降下来，让它尽早暴露。

四条断言的意义就在这里：它们把第三档人为地变成了第一档。

换句话说，这类问题的正确投资是买保险而不是买修复工具，而四条断言就是最便宜的那份保险。

一条词表从数据库走到页面，中间经过几双手？

典型的六段路径

把实际链路画出来，多数团队是这样的。

第一段，从系统后台导出一份表格。

第二段，发给本地顾问或者译员。

第三段，对方在自己的电脑上打开、填写、保存。

第四段，回传给你，中间可能经过一次转发或者压缩。第五段，内部有人合并、去重、调整列序。第六段，导入系统。六段里有四段发生在你看不见的地方。

还有两段容易被忘：第七段是有人把词表复制粘贴进邮件正文或者聊天窗口，第八段是有人截图给别人看然后对方照着重打一遍。

这两段听着离谱，但在跨时区协作里相当常见，而它们的损坏率是百分之百。

这两段还有一个共同点：它们都不会留下文件，于是连比对的机会都没有。

每一次交接都是一次重新解释

这条链上的每一次打开都不是简单的读取。

它是一次解码加一次类型识别，两个动作都带默认值。

默认值来自那台电脑的地区设置和软件语言。

所以同一份文件走六段路，可能被重新解释四次。

每一次解释都可能引入一处不可逆的改动，而且这些改动会叠加：先被切错列，再被猜错编码，最后被自动更正改掉一个词。

叠加还有一个恶劣的性质：后一次损坏会把前一次损坏的痕迹盖住。

被切错列之后再被猜错编码，你看到的只是最终结果，中间那一步已经无从还原。

排查时的顺序建议倒着来：先确认列结构对不对，再看字符对不对，因为列错位会让字符比对完全失去意义。

交接方式决定了损坏概率

不同的交接方式风险差别很大。

直接在共享的在线表格里协作，风险最低，因为没有本地打开这一步。

发文件让对方用表格软件打开，风险最高。

用专门的本地化工具走标准双语格式，风险居中，坏的是另一类东西。

把风险最高的那一段找出来通常很快，看一眼谁的交付物是带表格后缀的附件就知道了。

还有一种交接方式风险很高却常被当成安全的：把表格贴进文档或者演示文稿里传阅。

那一步会把数据变成排版对象，格式全丢，回来时只能人工重打。

判断一个交接方式安不安全有个简单标准：中途有没有一次本地打开，有就是高风险。

谁的电脑决定了这份文件长什么样

这句话是本文的题眼。

同一份文件，在你的电脑上是十二列，在顾问的电脑上是九列。

不是文件变了，是解释规则变了，而解释规则跟着人走。

所以这份数据的最终形态，取决于最后一个打开它的人把系统地区设成了什么。

这是一件挺荒谬的事：你的波兰站上那几个词长什么样，由一台你从没见过的电脑的地区设置决定，而那台电脑的主人对此毫不知情。

所以正确的问法不是这份文件对不对，而是这份文件最后是谁保存的、他的电脑设成了哪个地区。

这两个问题在交付说明里各占一行，就能把大部分事故挡在外面。

把这两个问题写进交付说明还有一个副作用：对方会因此意识到这件事是有讲究的，光这一点就能减少一半事故。

损坏之后会在哪里显形，为什么总是很晚才被发现？

页面上：属性值和筛选器里的怪字符

最直接的显形是肉眼可见的怪字符。

商品标题里的问号、属性值里的方块、筛选器选项里少了一个字母的词。

但商品页数量太多，抽查看到的概率不高。

筛选器反而更容易暴露，因为它把所有取值列在一起。

本站讲你的色卡上蓝和绿是两格，120门语言的样本里只有30门这么分那一篇里说过，枚举值是最容易整块出错又最难被察觉的一类数据，编码损坏正好落在这一类上。

筛选器还有个额外的放大效应：它的取值通常做了去重，一个坏掉的取值会以独立选项的形式出现在列表里，跟正确的那个并排。

用户看到的是两个几乎一样的选项，点哪个都只能看到一半商品。

清理这类重复取值时要注意先合并商品关联，直接删掉坏的那个会让一批商品失去属性值。

索引侧：这个词从此匹配不上

第二个显形位置在搜索这一头。

一个字母被换成问号的词，跟用户输入的正确写法不是同一个字符串。

站内搜索搜不到，外部搜索也匹配不上。

而这类失败是静默的：搜索返回零结果，没有任何一处会说这是因为库里那个词坏了。

如果这个词恰好是品类词，那么整个品类在这门语言里的入口就等于关掉了一半。

这类零结果在报表上还会被算成需求不存在，进而影响下一轮的选品和内容排期。

本站讲小语种关键词工具返回的那个零是数据缺口不是需求缺口那一篇讲的是另一种成因，但结论一样：先怀疑测量，再怀疑需求。

更隐蔽的是站内搜索的零结果页本身还会被记进日志，于是它在报表里表现为用户搜了一个不存在的词。

报表里：这个词的量凭空消失

第三个位置在数据这一头。

报表按词汇聚合，坏掉的词自成一行，量很小。

正确的那一行则少了这部分量。

看报表的人只会觉得这个词表现不好，不会想到它是被拆成了两半。

本站讲网页字体在小语种站变成拖慢首屏的最大一块那一篇提过一个类似现象，那里的原因是词形变化，这里的原因是字符损坏，但在报表上的表现完全一样：一个词的量被分散到了它自己的变体上。

更麻烦的是这两行数据在报表里往往不相邻，因为排序按量级排，坏掉的那一行沉在很后面。

除非你专门去找，否则它就是一行没人看的低量词。

所以按量级排序的报表不适合用来找这类问题，要按词形相似度分组看才找得出来。

三个症状归三个团队，没人看见全貌

这是这类问题存活时间长的组织原因。

怪字符归前端或者内容，搜不到归搜索或者产品，量不对归数据分析。

三个人各自记了一笔小问题，各自都不严重到要立项。

把三条线索并排放在一起才能看出它们是同一个根因。

这跟本站讲有些商品在这门语言里根本没有单数，可你的模板第一步就是取单数那一篇里的结构一模一样：一个字符层的小错，分裂成三个分属不同团队的症状，于是谁都没动手。

把三个症状合起来还有一个好处：它给了你一个非常具体的自查入口，任何一处出现，另外两处几乎必然也在。

顺着任何一条线索都能把根因挖出来，问题只在于有没有人把三条线索放在一起。

建议把这三条线索做成一张排查卡片贴在流程文档里，比记住原理更容易被用起来。

这三个症状还有一个共同的组织特征：它们分别落在三份不同的周报里，而没有任何一份周报会写这一条只值得记一行。

有没有办法在导入之前就拦住？

导入前的四条断言

最有效的位置是导入前，因为那是最后一道还能拦住的关口。

第一条，字符集断言：全文不得出现问号和替换字符这两类可疑字符。

第二条，行数断言：导入行数必须等于发出去时的行数。

第三条，字段数断言：每一行的字段数必须一致，且等于表头列数。

第四条，非空断言：关键列不得为空，因为分列错位最常见的表现就是后面几列整列变空。

四条断言里最有价值的是第一条，因为它能抓住不可逆的那一类损坏。

后三条抓的是结构性错误，那类错误至少还能靠重新分列救回来。

第一条断言还有个变体：统计替换字符的出现次数，这个字符在正常内容里几乎不可能出现，一旦出现就是解码失败的铁证。

字符集白名单怎么定

第一条断言需要一份白名单，定法很简单。

这门语言的字母表，加上数字、空格和你允许出现的标点。

任何落在白名单外的字符都列出来人工确认。

波兰语要包含带斜杠的l、带点的z这些字母，德语要包含三个变音字母和那个特殊的双s字母。

白名单还有一个附带收益：它能同时抓出全角半角混用、不间断空格、软连字符这些看不见的东西，本站讲为了让德语长词在手机上不撑破，前端往标题里塞了个看不见的字符那一篇里的那批问题在这一步能一并处理掉。

白名单的另一个用法是反向的：用它去扫存量数据，能一次性把历史遗留的损坏全部找出来。

这个动作跑一次的成本很低，而它给出的清单往往比团队预估的长。

扫存量的时候记得连商品属性表一起扫，词表和属性表往往走的是同一条链路，坏也是一起坏的。

行数与字段数校验

这两条最便宜，也最容易被跳过。

导出时把行数记在文件名或者一个附带的说明里。

导入时先数一遍，对不上就退回。

字段数用一行命令就能统计，每行有几个分隔符，做个频次分布。

如果分布不是单一值，说明这份文件已经被切坏了，此时任何进一步的处理都只会把错误固化。

还有一条更省事的：把表头单独存一份，导入时先比对表头是否一字不差。

表头一旦被翻译或者被自动更正改过，字段映射会整体错位，而这是最容易在导入阶段被误当成数据问题的一类故障。

表头比对还能顺带发现列序被调换的情况，那是另一种常见的人为改动，且同样不会有任何提示。

抽样比对：导出再导入一次，看差异

最后一条是验证流程本身有没有问题。

拿一份不做任何修改的文件，走完整条链路。

发出去，让对方打开、保存、发回来，然后比对。

如果这份没人改过的文件回来之后已经不一样，说明链路本身就在损坏数据。

这个测试半天能做完，而它能一次性回答一个平时靠猜的问题：到底是顾问改坏的，还是链路改坏的。答案通常是后者，而这个答案能省掉很多不必要的互相埋怨。

空跑测试还能顺便测出行序问题：如果回来的行序变了，说明中间有人做过排序，而排序会让后续的比对全部失效。

遇到这种情况，比对要先按主键重新对齐再做，否则看到的差异全是假的。

空跑测试最好每换一位外部合作方就做一次，因为链路的风险是跟着人变的。

正确的交付方式长什么样？

优先不用表格软件，用工具或脚本

最根本的办法是把表格软件从链路里拿掉。

内部处理用脚本，标准库里的解析器会严格按你指定的分隔符和编码工作，不猜。

批量导入导出用系统自带的功能，或者专门的本地化工具。

需要人协作时用在线协作表格，它没有本地地区设置这一层。

这一条能消掉本文前面讲的大部分损坏，因为那些损坏全部来自本地打开这个动作。

脚本方案还有一个附带好处：它可以在解析时就报错。

字段数不对、编码解不开，程序会直接抛出来，而不是像表格软件那样尽力显示一个看着还行的结果。

脚本方案的另一半价值在于可重复：同样的输入永远得到同样的输出，而人的操作做不到这一点。

必须给人看时，怎么让它安全打开

现实里总有人只会用表格软件，那就把打开方式写进交付说明。

第一，不要双击，用数据菜单里的从文本导入功能，那里可以显式选编码和分隔符。

第二，导入时把所有列的类型设成文本，这样类型识别不会动你的数据。

第三，如果对方一定要双击，那就在文件开头加上字节顺序标记，多数表格软件看到它会正确按通用编码打开。

第四，改完之后不要用另存为默认格式，按约定的编码和分隔符另存，或者干脆回传原格式。

第五条也值得写进说明：改完之后先自查一遍带变音符号的字母还在不在，随便挑三五个词看一眼就行。

这一步花不了一分钟，却能让对方在发出去之前自己发现问题。

这四条写成一页纸贴在交付说明的最前面，比写在合同附件第七页管用得多。

分隔符与编码要显式声明

还有两个成本极低的技巧。

一是改用制表符分隔，因为制表符不参与任何地区设置，各地打开结果一致。

二是在文件第一行写一句分隔符声明，部分表格软件会识别它并按声明切列。

再配上文件名里带编码和分隔符的标注，接收方一看就知道该怎么打开。

这三招加起来不用十分钟，能解决掉链路上最常见的那两类损坏，而多数团队从来没做过其中任何一条。

制表符方案唯一的代价是字段里不能含制表符，而词表这类数据几乎不可能出现制表符，所以这个代价约等于零。

还有一个细节：制表符分隔的文件后缀最好也跟着改，别再用逗号分隔的后缀，否则接收方还是会按老习惯双击。

把词表当代码管，进版本库

最后一条是流程上的升级。

词表是资产，它跟代码一样会被多人修改、会有版本、会需要回溯。

放进版本库之后，每一次改动都有差异记录，谁改的、改了什么一目了然。

真出了问题也能直接回到上一版，而不是去邮箱里翻附件。

本站讲平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一那一篇里提过一个类似的判断：凡是最终会变成页面上文字的数据，都值得按对待代码的标准去管，而词表是其中最典型的一类。

声明行也有兼容性代价：某些解析器会把它当成一行数据。

所以这一招只在明确知道对方用表格软件打开时使用，走脚本的链路上不要加。

还有一个折中：文件名里直接标注编码和分隔符，接收方一眼就知道该怎么打开，成本是零。

团队层面怎么让这件事不再复发？

交付规范写进合同和工单

把要求写在需求里，比事后检查便宜得多。

给外部顾问的合同附件里加一页交付规范。

内容包括：用什么格式、什么编码、什么分隔符、怎么打开、怎么保存。

再加一条验收条件：回传文件必须通过四条断言。

这一页纸的成本是一次性的，而它把责任边界也划清楚了：链路怎么走是你定的，顾问只负责内容。

版本库对这类数据还有一个特别的好处：文本差异是按行按字符算的，一个字母从正确变成问号会被清清楚楚地标出来。

而这正是表格软件永远给不了你的东西。

进版本库之后还能顺手加一个提交前检查，把四条断言挂上去，不通过就提交不了。

三条硬约束

第一条，任何要交给外部的词表，一律用制表符分隔加通用编码，不用逗号。

第二条，任何回传文件，先跑断言再看内容，不通过直接退回，不要自己动手修。

第三条，原始导出文件必须留存，且留存的是发出去的那一份而不是回来的那一份。

第三条最容易被忽略，可它是所有恢复动作的前提：只要源头那份还在，任何损坏都只是重做一次，源头没了才是真的丢了数据。

规范里还要写清楚一件事：不接受任何形式的截图、文档内嵌表格和聊天窗口粘贴。

这句话看着多余，但写上之后能省掉很多次解释。

规范落地之后还要留一个例外通道，总有临时情况需要走别的方式，明确写出来比让人偷偷绕过去好。

一次性清理历史损坏的办法

存量数据也要处理，方法是全库扫一遍。

先按字符集白名单扫，把所有含可疑字符的记录拉出来。

再按长度扫，同一批词里明显偏短的可能是被吃掉了字母。

最后按重复扫，两个词只差一个字符的，多半其中一个是坏的。

三遍扫完，人工确认一次，一个中等规模的词表半天能清完，而清完之后把这三条扫描做成定时任务，以后就是自动的。

第二条里的不要自己动手修需要强调一下：自己修会掩盖问题，下一批还会一样坏。

退回去还有一个好处，它让对方那一侧也建立起对这件事的意识。

三条硬约束里第三条最容易被跳过，因为留存看起来没有立刻的收益，直到某一天它成为唯一的救命稻草。

每次交付要留的两个数

最后给两个最省事的护栏。

第一个数是行数，发出去多少行，回来必须还是多少行。

第二个数是非基本拉丁字符的总数，也就是这份文件里变音字母和非拉丁字符加起来有多少个。

这个数发出去时记一笔，回来再数一笔。

如果回来的数明显变小，那就是编码损坏，一个数就能判定，不需要逐行比对。这两个数放在交付说明的第一行，是整条流程里性价比最高的两行字。

清理时按品类优先级排序，先清那些是品类词和属性值的行，它们直接影响页面和索引。

长尾词那一批可以放到第二轮，因为单个词的损失小得多。

清完之后把三条扫描做成定时任务，以后就是自动的，这一步是让治理从一次性变成常态的关键。

常见问题解答

为什么同一份关键词表在同事电脑上打开列数不一样？

因为逗号分隔文件里没有任何一处声明自己用什么符号分列，表格软件双击打开时用的是系统地区设置里的列表分隔符。小数点写成逗号的地区，包括德国、法国、波兰、西班牙、意大利和北欧多数国家，默认分隔符是分号；英美和多数亚洲市场是逗号。做欧洲市场的团队，本地顾问和译员绝大多数在第一类地区，所以这不是偶发事故，是默认状态。改用制表符分隔可以绕开，因为制表符不参与地区设置。

还有一个更省事的替代方案：交付时统一改成制表符分隔，制表符不参与任何地区设置，各地打开结果一致。

变音字母变成问号之后还能恢复吗？

显示成问号还有救，保存之后就没救了。软件会把屏幕上那个问号当成真正的内容写回文件，原来的字节被覆盖，任何工具都恢复不出来，只能回到源头重新取。这跟不可见字符那类问题性质不同：那一类是多出了看不见的东西，可以清洗；这一类是丢掉了本来有的信息，属于缺失。所以原始导出文件必须留存，而且要留发出去的那一份，不是回来的那一份。

所以真正的护栏是留存源头文件，且留存的是发出去那一份。只要源头还在，任何损坏都只是重做一次。

为什么这些坑在中文和英文词表上很少听说？

因为它们分别落在两个极端。英文只用基本拉丁字母，在几乎所有编码里字节都一样，编码猜错也看不出来。中文猜错是整篇乱码，第一秒就被发现，不会流到下游。小语种正好在中间：只有带变音符号的那批字母出问题，占比通常三分之一左右，而且坏成问号或方块之后看着仍然像内容，文件能打开能保存能导入，一路畅通。坏得越轻，越难被发现。

顺带一提，这也是为什么讲表格数据处理的通用资料几乎不提这一层：它们的默认读者处理的是英文和数字。

表格软件把型号和区间改掉了，有没有开关能关掉？

没有一个总开关，但有可靠的绕法。导入时不要双击，用数据菜单里的从文本导入功能，在向导里把所有列的类型设成文本，类型识别就不会动你的数据。已经在编辑的表格里，可以先把单元格格式设成文本再粘贴，或者在内容前加一个撇号。厂商自己的帮助文档里就写着数字变日期和前导零消失这两个行为，还给了这几种绕法，说明它们是被承认的常见问题而不是故障。

还有一条值得记：某些语言的规格写法以加号或等号开头，那会被当成公式，处理办法同样是先把列设成文本。

导入之前该做哪些检查才能拦住这类问题？

四条断言就够。字符集断言：全文不得出现问号和替换字符，白名单是这门语言的字母表加数字标点。行数断言：导入行数必须等于导出行数。字段数断言：每行字段数一致且等于表头列数。非空断言：关键列不得为空，因为分列错位最常见的表现就是后面几列整列变空。再补一个最省事的护栏：记录这份文件里非基本拉丁字符的总数，回来时再数一遍，数字明显变小就是编码损坏。

再补一条最省事的护栏：数一数这份文件里非基本拉丁字符的总数，发出去记一笔，回来再数一笔，数字变小就是编码损坏。

怎么判断是顾问改坏的还是流程改坏的？

做一次空跑测试。拿一份不做任何修改的文件走完整条链路，发出去、让对方打开保存、再发回来，然后比对。如果这份没人改过的文件回来之后已经不一样，说明链路本身就在损坏数据，跟顾问无关。这个测试半天能做完，而它能省掉很多互相埋怨的时间。经验上答案通常是链路的问题，因为那些改动全部发生在打开和保存这两个动作里，人根本没有参与。

顺带说一句，空跑测试还能测出行序有没有被重排，而行序一变，之后所有按行比对的结果都是假的。

权威参考资料