那是一个深夜，屏幕前的你正沉浸在某个热门游戏当中。剧情渐入佳境，角色对话跃然屏上——可就在某个瞬间，你突然愣住了。
“这个‘关’字，怎么看起来这么别扭？”（“关”字看起来很窄，更像部首而不像完整的字）
明明是中文字，却透着一股说不出的“日式风味”。你揉了揉眼睛，以为是熬夜太久眼花。可仔细一看，“门”字中间多了一竖，“将”字的右上角也变了样……
这不是翻译错误，也不是你的错觉。
这是一场由游戏引擎“自作聪明”引发的字体迷案——而背后的真相，远比想象中更无处不在、也更隐蔽。
“将” “门” “关” 三个字在日文字体下的截图
近日，让全网苦等6年的《空洞骑士：丝之歌》终于发售，但其游戏内的翻译问题也引发了广泛讨论。我们暂且按下文本翻译的质量不表，来揭秘一个更为普遍、却常被忽视的技术问题：为什么许多Unity游戏里的汉字，看起来总有一股“日味儿”？
🖊
这个问题的核心，在于Unity为方便开发者而内置的一套本地化插件（常与TextMeshPro配合使用）。这套插件为了实现无需重启游戏即可瞬间切换语言的炫酷功能，采用了一种叫做“备用字体清单”（Fallback Font List）的机制。
它的工作原理很简单：
绝大多数独立游戏为了保证字库完整、避免版权风险，都会使用Google的Noto系列字体（思源字体）。其中，中日韩三国文字被合并为一个名为“CJK”的字符集，但细分为不同的字体文件，如：
NotoSansJP（日文）
NotoSansKR（韩文）
NotoSansSC（简体中文）
NotoSansTC（繁体中文）
问题就在于，Unity备用字体清单的默认顺序，往往是日文（JP）排在简体中文（SC）前面。于是，当游戏要显示一个汉字（如“关”）时，引擎会沿着清单一路查找：
先在NotoSansJP里找→找到了！好，就用日文字体里的这个“关”字显示出来。
既然已经找到了，它就不会再去NotoSansSC里查找真正的中文“关”字了。
因为汉字在中日文中大量通用，但字形设计略有差异，最终导致了游戏中汉字“日里日气”的观感。而数字、拉丁字母因为所有字体都包含，所以永远显示为默认的第一套字体，无法随语言切换而改变风格。
对于玩家而言，如果发现某个游戏有此问题，可以向开发者反馈一个治标的方法：在Unity的TextMeshPro设置中手动调整备用字体清单的顺序，将简体中文字体拖到日文之前即可。
但对于开发者而言，治本的解决方案则更为重要：
这也正是为什么许多海外独立开发者会掉进这个坑——他们通常在项目尾声才考虑本地化，此时游戏已有成千上万个文本框，再回头修改无疑是大海捞针，只能无奈采用引擎的默认方案。
《丝之歌》的案例（即便其问题或许仅存在于部分后期添加的文本框中），恰能印证一个共识：游戏本地化本就是多维度协同的系统工程。
这个案例的提醒意义更在于：一些本应被客户重视的技术问题，实操中易成“被忽视的角落”。
技术实现：字体、UI布局、文本编码（如Unicode）、控件适配等；
整体体验：翻译后的文本是否与游戏的美术风格、字体表现融为一体。
……
对开发与本地化团队而言，若能关注这些技术与体验的联动，往往能让本地化效果更贴近玩家预期：
项目启动阶段即规划本地化是最高效的路径
技术上，提前确认游戏引擎对动态字体替换、扩展字符集的支持能力；
美术设计时，优先选用特定语言版本（如简体中文）的字体，或预留好字体切换的技术接口；
预算层面也可提前考量多语言字体的授权或定制成本；
……
这样的前期投入虽可能增加初期规划成本，却能显著降低后期因技术适配问题反复修改的损耗，也能让玩家获得更顺畅舒适的体验。
落实LQA流程，通常是确保本地化质量的重要环节
某些时候，开发团队有测试规划，但执行中可能因各种原因难以落实。此时往往需要全面核查所有界面（包括主机端）的字体渲染、文本排版等细节，通过更细致的LQA流程，最大程度保障译文在技术层面无误、体验层面统一。
当翻译文本通过成熟的技术手段与游戏美术、交互逻辑自然融合时，本地化才算完成了其使命。这要求开发团队将本地化视为贯穿项目的系统工程，而非尾声的附加任务，积极主动与本地化团队紧密协作，聚焦每处细节对用户体验的影响。
字体的精准渲染、文本的顺畅显示这类细节，和剧情打磨、关卡设计一样，都是连接游戏与全球玩家的重要纽带——它们既通过技术传递着对玩家的尊重，让不同地区的用户感受到制作用心，也保障了跨语言体验的完整性与沉浸感。
唯有如此，游戏才能真正跨越语言与文化的隔阂，让各国玩家收获同等的乐趣与感动，而这，也正是本地化工作尊严与价值所在。
图片设计 | 曹蕴露
本文审稿｜全球资源管理团队 柯凡
*本文技术分析部分来源于B站UP主谜之声，已获作者授权。
