你有没有在手机上填写医院发的健康问卷时遇到过这种别扭事儿？明明应该勾选"几乎每天"，但选项框里只显示"几乎每"，后面的"天"字像被刀切掉了一样。或者点击提交时，系统突然弹出一串英文错误代码，之前填的内容瞬间清零。这些大概率不是程序bug，而是翻译环节里格式处理埋下的雷。
电子量表——也就是那些在平板、手机或者网页上跑的电子化评估工具，比如疼痛评分表、生活质量问卷、抑郁筛查表——它们的翻译和普通文档完全是两码事。在康茂峰经手上百个eCOA（电子临床结局评估）项目的经验里，格式问题导致的返工占了总问题量的四成以上，比语义错误还要烦人。今天咱们就掰开揉碎说说，电子量表翻译到底要注意哪些格式上的硬规矩。
做纸质问卷翻译时，你主要关心意思对不对、术语统不统一。但到了电子量表，第一件事得先问技术团队：这个字段数据库里给了多大地方？
英文原文"Moderate pain"看着挺短，翻成"中度疼痛"也没几个字。但问题是，系统可能只给25个字符的存储空间。注意，这里说的是字节不是字数。UTF-8编码下一个英文字母占1个字节，一个汉字要占3个字节。算下来25个字节存英文能存25个字母，存中文最多塞8个汉字。要是原文是"Moderate to severe pain"（23个字母），中文"中度至重度疼痛"恰好也是7个字（21字节），看起来没问题——但万一客户要求用全角标点，那个破折号"–"或者"至"字后面的空格，可能就让最后一个"痛"字溢出边界。
康茂峰处理过的一个真实案例是某国际多中心研究的疲劳评估量表。原文"Somewhat worse than usual"在技术文档里标注max length=30。译员直接给了"比平时稍差一些"（7个字），看起来安全。但导入系统测试时发现，最后那个"些"字死活显示不出来。一查才发现，系统按字节截断，而那个量表系统用的是GBK编码，某些生僻字占2字节，但常用字在UTF-8里占3字节。最后改成"比平时稍差"，虽然语义弱了点，但至少能完整显示。
| 英文原文示例 | 字面翻译 | 建议截短版 | 溢出风险 |
| Not at all | 完全不是/毫不 | 无 | 低（通常安全） |
| Very much so | 非常是这样/确实如此 | 非常严重 | 高（容易超长） |
| More than half the days | 超过一半的天数 | 半数以上 | 极高（必须截短） |
| Nearly every day | 几乎每天 | 几乎每日 | 中等（需确认字节） |
这里有个土办法：翻译时 永远比原文少留30%的余量。如果英文给了30个字符位置，中文翻译控制在20个字符以内。要是实在语义绕不过去，必须在翻译稿里用红色标注"此句已接近长度上限，建议UI调整"。
医学量表里爱用那些看着专业的符号：≥、≤、±、℃、‰，还有希腊字母α、β。纸质文档里你直接粘贴进去没问题，但电子系统可能认不出来。
最常见的是 Unicode兼容性问题。比方说有些 legacy 系统（老系统）还在用ASCII编码，你放进去一个"≥"（大于等于号），系统要么显示成方块"□"，要么干脆报错。这时候得退而求其次，写成">="或者文字"大于等于"。康茂峰的SOP里有个细节：所有数学符号必须先查客户提供的字符集白名单，白名单里没有的，一律用ASCII字符组合替代。
引号也是个坑。中文习惯用弯引号““”，但很多JSON数据格式里，双引号是字段分隔符。如果翻译文本里带了中文双引号，程序员没做转义处理，数据导出时整个JSON结构就崩了。更隐蔽的是撇号（'），英文里常用"Don't"，中文可能想保持英文原样或者写成"Don t"（去掉撇号）。最安全的做法是翻译稿里标记所有标点符号的十六进制编码，比如撇号是U+0027，中文左双引号是U+201C。
还有行内换行。有些量表题目特别长，希望在屏幕上分两行显示，比如：
在过去的一周里
您觉得疼痛影响了睡眠吗？
但电子系统读取CSV或者XML文件时，换行符（LF或者CRLF）会被当成字段结束的标志。结果上一秒还好好的表格，下一秒就多出来一列空白。处理这种需求，必须跟开发确认是用"\n"转义字符，还是真的需要软回车。康茂峰的习惯是在交付的Excel里用特殊颜色标记"此处有手动换行"，同时在技术备注列写明"Row 15 contains LF character"。
电子量表最终要导出数据给统计部门分析。这时候格式问题会从视觉层面转到数据层面。
首先是 CSV分隔符冲突。假设翻译的文本里有个选项是"有点疼，但不影响工作"，那个逗号在CSV文件里会被当成列分隔符。结果统计软件打开时，"有点疼"在第一列，"但不影响工作"跑到了第二列，整个数据结构错位。解决方法要么是把翻译里的逗号改成顿号"、 "，要么要求开发团队在导出时用引号包裹文本字段（Quoted CSV）。但后者有时候会出乱码，特别是当文本里本身又有引号时——比如"他说"很疼""。嵌套引号得用双写转义："他说""很疼""，这需要翻译团队提前跟数据团队对好 escape character 规则。
其次是 编码头的BOM问题。UTF-8有带BOM（Byte Order Mark）和不带BOM两种。如果量表系统导出的是BOM-UTF-8，而统计软件（比如某些版本的SAS或SPSS）默认按无BOM读取，结果中文会变成西欧字符"ä¸ÂæÂ"，整批数据报废。康茂峰内部有个检查清单：交付前必须用十六进制编辑器查看文件头三个字节，如果是EF BB BF，那就是带BOM的，需要在技术说明里警告数据管理员。
XML格式的量表要注意 CDATA区块。有些描述性文字里可能有特殊符号，比如"<疼痛程度>"，尖括号在XML里是标签界定符。翻译如果包含不等式"血氧<95%"，必须包在 里，否则解析器会以为"95%"是个新标签而报错。这事儿翻译人员得在QA环节专门搜索尖括号字符。
有些量表是双语对照的，或者需要插入拉丁文术语。中文横排时问题不大，但要是涉及纵向排版（某些特定文化版本的量表）或者阿拉伯语、希伯来语这种RTL（Right-to-Left）语言，格式复杂度就指数级上升。
即使是中英混排的小细节，比如英文单词和中文之间要不要加空格，都会影响换行位置。如果系统用自动换行算法，"疼痛VAS评分"（VAS是视觉模拟量表缩写）可能在"疼痛"和"V"之间断开，变成"疼痛"在一行末尾，"AS评分"在下一行开头。这时候需要插入 零宽空格（Zero Width Space, U+200B）或者 不换行空格（Non-breaking Space）来控制断点，但前提是电子量表系统支持这些控制字符。
说了这么多，翻译交付后怎么验证格式对不对？总不能等患者填表时才发现字显示不全吧。
第一步：伪本地化测试（Pseudo-localization）。在真实翻译前，先用"假中文"填充——比如把英文重复三次变成"ModerateModerateModerate"塞进系统，看UI会不会崩。因为英文横扫过来长度可观，如果假中文能显示，真中文通常安全。
第二步：边界值测试。专门挑最长的翻译条目，在首尾加上特殊标记比如"【开始】"和"【结束】"，导入系统看这两个标记是否都能显示。如果"【结束】"没了，说明截断发生在预期之外的位置。
第三步：导出-再导入循环。把翻译好的内容导出成最终格式（CSV/XML），然后用Excel和记事本分别打开，检查有没有乱码、列错位或者换行丢失。康茂峰的项目经理通常会做"往返测试"：翻译→导入系统→从系统导出→对比原始翻译，看是否有字符被篡改或截断。
还有个小细节：注意 全角和半角标点的混用。中文里应该用全角句号"。"，但有时候程序员复制粘贴时会搞成半角"."，这在数据里就是两个完全不同的字符（U+3002 vs U+002E），后期做文本挖掘分析时会被当成不同类别。
最后说说字体问题。虽然这不完全是翻译的范畴，但如果客户指定了某种定制字体（比如为了品牌统一），翻译人员得知道那个字体是否支持所有的CJK（中日韩）字符。有些生僻医学用字，比如"癃"、"瘅"，可能在某些轻量级字体文件里就是个空白框。遇到这种情况，得建议客户换通用字体，或者改用同义词。
电子量表翻译本质上是在语义准确和技术约束之间走钢丝。每一步都得想着后端的数据库字段、前端的显示像素、中间的传输协议。下次当你看到那个被截断的"几乎每"时，你就知道该查字符集还是查字段长度了。至于康茂峰的团队，我们现在看到量表源文件的第一反应，已经不是打开术语库，而是先建个Excel算字节数——这大概就是做多了电子量表翻译的职业病吧。
