为什么你的应用英文测试全过，日本用户一输入就崩？

英文测试全绿，日本用户敲进名字按下回车，表单却只提交了半个词。一位日本本土开发者把这类问题归为「安静的假设」：词与词之间有空格、长度等于字符数、回车就是发送、按字符串排序等于按读音排序。这些假设没有一个会报错，它们只是让应用在日本用户手里显得「有点坏」。

他列出了自己最常遇到的七种情况，并附上可直接复制的代码。

一、输入法转换中的回车不是「发送」

日语通过输入法（IME）输入：敲出 kaigi，看到 かいぎ，按空格转换成 会議，再按回车确认转换。如果聊天框或搜索框把回车当作发送，发出去的就是半成品文本。这是他在日本以外开发的聊天应用、评论框和待办应用里最常见的问题。

处理方式是在按键事件里判断输入法是否正在转换：isComposing 为真时直接返回，交给输入法处理；再用 keyCode === 229 覆盖旧版 Safari——它在转换结束后才触发确认用的回车。用 React 的开发者应检查 e.nativeEvent.isComposing。

二、length 数不出「一个字」

'野家'.length 返回 4，因为 在基本多文种平面之外，占两个 UTF-16 单元；展开成数组后才是 3 个码点。码点仍不等于用户眼中的「一个字」：带连接符的 emoji 由多个码点组成，'‍‍家族' 展开是 7，用 Intl.Segmenter 按字形簇切分才是 3。

所以做「最多 20 字」的截断、预览、通知时，要按字形簇切，否则会把一个字劈成两半，显示成乱码符号。他给了一段 truncate 函数示例，把文本按字形簇切分后取前 max 个再补省略号。

还有一层：日语信息密度高，20 个日文字符大致相当于 40 到 60 个英文字符。英文下合适的限制放到日语里可能很宽松，但每个字符宽度约为两倍，像素宽度反而常常变大——不要给按钮设一个按英文调好的固定宽度。

三、换行：没有空格，有些字符不能出现在行首

日语词间没有空格，浏览器可能在任意两个字符之间断行，包括词中间。两个 CSS 属性有帮助：line-break: strict 保证句号、顿号、长音符号和小假名不出现在行首；word-break: auto-phrase 让断行发生在短语之间而非词内部，需要 Chrome/Edge 119 以上。短标题可以用 text-wrap: balance 让长度更均匀。

auto-phrase 只在元素标记了 lang="ja" 时生效，不支持的浏览器会保持原行为，所以加上是安全的。对标题来说，最可靠的做法仍是短到能在手机上一行放下。

四、不要用字符串拼接造句

语序不同：英语动词在前，日语动词在最后。所以把「删除」「数量」「文件」几段拼起来再交给翻译是行不通的，翻译器只看到碎片。正确做法是把整句连同占位符交给翻译，例如英文的 'Delete {count} files?' 对应日文的 '{count}件のファイルを削除しますか？'。

日语没有复数变化，Intl.PluralRules 对 1 和 2 都返回 "other"，但量词随名词变化：3件、3個、3人、3枚。量词属于名词，应留在翻译字符串里，而不是写进代码。列表连接用 Intl.ListFormat，日语的连接结果是「りんご、みかん、ぶどう」。

五、按字符串排名字，排不出读音顺序

Intl.Collator('ja') 能把平假名和片假名按あいうえお顺序排在一起。但汉字不携带读音，直接排汉字姓名会得到日本人意想不到的顺序：山田、佐藤、鈴木、田中排出来是佐藤、山田、田中、鈴木，而按读音应是佐藤（さとう）、鈴木（すずき）、田中（たなか）、山田（やまだ）。

这就是日本表单要填姓名读音（振假名）的原因。列出人员或客户时，应按读音字段排序，而不是姓名字段。

六、搜索要让平假名、片假名、半角都能匹配

同一个词可能有多种写法：やまだ、ヤマダ、ﾔﾏﾀﾞ。用户期望搜索都能找到。做法是对查询和数据做同样的归一化：先用 NFKC 把半角片假名和全角字母转成常规形式并转小写，再把平假名折叠成片假名。示例中 fold('ﾔﾏﾀﾞ') 与 fold('やまだ') 相等，都变成「ヤマダ」；fold('ＡＢＣ１２３') 得到 "abc123"。

切词做索引或高亮时，Intl.Segmenter 也能用于日语，按词粒度切出「今日」「は」「東京」「で」「会議」「が」「あり」「ます」。它不如真正的日语分词器，但内置可用，远好于按空格切——日语里根本没有空格。

七、同一个字可能长得像中文

中文和日文共享许多码位相同的汉字，但字形有细微差别，直、骨、角、写是典型例子。如果字体是按中文选的，日本读者会察觉，看起来像打错了字。修法是告诉系统这段文本是日语：在 :lang(ja) 下指定 "Hiragino Sans"、"Noto Sans JP"、"Yu Gothic UI"、"Yu Gothic" 等字体。

移动端同理：显示日语时把应用或视图的语言环境设为日语；游戏里要确保随包发布的是日文字体（Noto Sans JP 免费），而不是中文字体。混合内容是难点，比如日文页面里显示中文用户的评论，知道语言时给它单独标上 lang 属性。

他最后给了一份清单：输入法转换中的回车不发送；字符限制和截断按字形簇计数；日语文本启用 line-break: strict 与 word-break: auto-phrase，按钮不设固定宽度；用带占位符的整句，量词放进翻译；人员按读音排序；搜索折叠平假名、片假名、半角；标记 lang="ja" 并使用日文字体。

这些都不是翻译问题。日文文案可以完美无缺，应用仍会因为这些细节显得「不是为这里做的」。好消息是，每一处都是小修小补。