避坑指南：用FontCreator 14修改中文字体属性，彻底解决TMP SDF生成乱码问题

避坑指南：用FontCreator 14修改中文字体属性，彻底解决TMP SDF生成乱码问题

最近在项目里折腾一个挺有设计感的第三方中文字体，美术同学兴冲冲地丢过来，结果一进Unity，用TextMeshPro的Font Asset Creator一生成SDF，预览里除了几个可怜的英文字母，其他全是“？？？？”。这场景，估计不少Unity技术团队都遇到过——满怀期待地导入新字体，结果在TMP里给你上演一出“字符消失术”。问题往往就出在字体文件自身的元数据上，特别是那些带有中文名称的字体，与TMP的SDF生成管线存在兼容性“暗礁”。今天，我们就以FontCreator 14.0.0.2814这个版本为手术刀，深入字体文件的“内部”，通过修改关键属性，一劳永逸地解决这个乱码顽疾。

1. 问题根源：为什么TMP对中文字体名“水土不服”？

当我们将一个.ttf或.otf字体文件拖入Unity，并启动TMP Font Asset Creator时，这个工具会启动一个复杂的预处理流程。它首先会尝试读取字体文件内部的元数据（Metadata），其中最关键的一项就是字体名称（Font Name）。这个名称并非我们看到的文件名，而是嵌入在字体文件二进制结构深处的标识信息。

TMP的SDF生成引擎，在底层依赖于一套对字符编码和路径处理有特定预期的库。当它遇到一个包含非ASCII字符（比如中文、日文、特殊符号）的字体名称时，在某些环境下，路径解析或字符串处理环节就可能出现编码错误或截断。这直接导致引擎无法正确“定位”和“理解”这个字体文件，于是在生成Signed Distance Field（SDF）纹理图集时，所有非ASCII字符（也就是我们绝大部分的中文字符）的轮廓信息都无法被成功提取，最终在预览和运行时表现为乱码或问号。

这不仅仅是Unity或TMP的“锅”，而是一个在跨平台、跨语言开发工具链中常见的兼容性问题。许多优秀的第三方中文字体，其设计师为了品牌统一或美观，常常在字体内部署上中文名，这本身无可厚非，但却无意中为后续的技术集成埋下了隐患。

注意：这个问题与字体文件本身包含的字符集（Glyphs）是否完整无关。即使字体包含了全部GB2312或GBK字符，只要其内部名称含有中文，就可能触发TMP的解析异常。

2. 工具准备：获取与安装FontCreator 14

工欲善其事，必先利其器。要修改字体内部的“基因”信息，我们需要一款专业的字体编辑软件。这里我们选用High-Logic FontCreator 14.0.0.2814。选择这个特定版本是因为其界面和功能稳定，且我们接下来的操作步骤均基于此版本验证，可以确保一