📚 课程目录第3章字符编码与字体基础

3. 字符编码与字体基础

在HMI多语言项目中，文字显示异常往往不是“翻译错了”，而是编码或字体链路出了问题。要真正理解多语言显示，必须把“字符—编码—字体—字形—渲染”这条链路拆开看。本节从Unicode码点出发，讲清UTF-8与UTF-16的差异、字体文件格式的作用，以及字形如何最终被绘制到屏幕上。

一、核心原理：从字符到像素的五层链路

一个汉字或字母要显示在HMI屏幕上，需要经过五个层次：字符集、编码、字体文件、字形轮廓、光栅化渲染。字符集定义“有哪些字符”，编码定义“如何用字节表示”，字体文件定义“字符长什么样”，字形轮廓是矢量描述，光栅化则把矢量变成屏幕像素。

Unicode是当前最通用的字符集标准，它为世界上几乎所有文字系统中的每个字符分配一个唯一码点，例如“中”是U+4E2D，“A”是U+0041。码点只是一个逻辑编号，真正存储和传输时，需要UTF-8、UTF-16或UTF-32等编码方案把码点转换为字节序列。

关键认知：Unicode是“字符编号表”，UTF-8/UTF-16是“编号到字节的转换规则”，字体是“编号到图形的映射表”，渲染器是“图形到像素的绘制器”。四者缺一不可。

二、UTF-8与UTF-16：编码方式对比

UTF-8使用1到4个字节表示一个码点，兼容ASCII，英文占1字节，中文通常占3字节，emoji占4字节。UTF-16使用2或4个字节，基本多文种平面内的字符占2字节，超出部分用代理对表示4字节。两者没有绝对优劣，关键看使用场景。

对比项	UTF-8	UTF-16
英文存储	1字节/字符	2字节/字符
中文存储	3字节/字符	2字节/字符
ASCII兼容	完全兼容	不兼容
字节序问题	无	有BOM/大小端
典型场景	文件、网络、配置	Windows API、Java/JS内存

在HMI工程中，资源文件、翻译表、CSV导入导出通常使用UTF-8，因为它跨平台、无字节序问题、便于版本管理。而某些组态软件内部或Windows接口可能使用UTF-16，转换时需注意BOM和代理对。

# 查看文件编码（Linux）
file -i strings_zh.csv
# 输出示例：strings_zh.csv: text/plain; charset=utf-8

# 转换 UTF-8 到 UTF-16 LE
iconv -f UTF-8 -t UTF-16LE strings_zh.csv -o strings_zh_utf16.csv

# Python 读取时显式指定编码
with open("strings_zh.csv", encoding="utf-8-sig") as f:
    rows = f.readlines()

三、字体文件格式与字形渲染

字体文件格式决定了字形如何被组织和访问。常见格式包括TrueType、OpenType、WOFF/WOFF2以及嵌入式点阵字体。TrueType使用二次贝塞尔曲线描述轮廓，OpenType支持更复杂的排版特性，WOFF主要用于Web，点阵字体则常见于资源受限的HMI屏。

字形渲染的核心是“码点→字形ID→轮廓→位图”。渲染器先通过字体中的cmap表把Unicode码点映射到glyph ID，再读取该字形的轮廓数据，最后经过抗锯齿、Hinting、亚像素渲染等步骤生成屏幕像素。如果字体缺少某个码点的字形，就会显示为方框、问号或空白，这就是常说的“豆腐块”。

四、案例场景：多语言HMI的字体配置

假设一个HMI项目需要支持简体中文、英文、日文和阿拉伯文。英文和中文可用同一套字体，但日文需要包含假名和汉字字形，阿拉伯文则需要从右到左排版和连字支持。若只嵌入一套中文字体，日文假名可能缺失，阿拉伯文更会完全无法显示。

合理的做法是按语言分组配置字体回退链：主字体优先，缺失字形时回退到备用字体。例如中文用思源黑体，日文用Noto Sans JP，阿拉伯文用Noto Naskh Arabic。同时，翻译表必须统一保存为UTF-8，避免在导入导出过程中被本地代码页破坏。

# 字体回退链配置示例（伪配置）
font_family:
  zh-CN: ["SourceHanSansSC", "NotoSans"]
  en-US: ["NotoSans", "SourceHanSansSC"]
  ja-JP: ["NotoSansJP", "SourceHanSansSC"]
  ar-SA: ["NotoNaskhArabic", "NotoSans"]

# 检查字体覆盖范围（fontTools）
from fontTools.ttLib import TTFont
font = TTFont("NotoSansJP-Regular.otf")
cmap = font.getBestCmap()
print(hex(0x3042) in cmap)  # 检查是否包含“あ”

五、误区与复盘

误区一：认为“UTF-8就是Unicode”。Unicode是字符集，UTF-8是编码方式，二者不是同一层概念。
误区二：只改翻译表不改字体。编码正确但字体缺字形，依然会显示豆腐块。
误区三：忽略BOM。UTF-8 BOM可能导致配置文件首字段解析失败，HMI工程中建议使用无BOM UTF-8。
误区四：用字符数计算显示宽度。中文、英文、emoji的显示宽度不同，UTF-16代理对还会让长度计算翻倍。
误区五：只在PC上验证。PC字体丰富，目标HMI屏字体有限，必须在真机或模拟器上验证。

排查多语言显示问题时，建议按“编码→字体→字形→渲染→控件”的顺序逐层检查：先用十六进制查看字节，再确认字体是否包含目标码点，最后检查控件是否支持该语言的排版方向。

阿拉伯文、希伯来文等从右到左语言不仅涉及字形，还涉及双向文本算法和连字。若HMI运行时库不支持复杂文本布局，即使字体正确，显示顺序也可能错误。

掌握这条链路后，再面对“中文乱码”“日文方框”“阿拉伯文反向”等问题时，就能快速定位是编码层、字体层还是渲染层的问题，而不是盲目替换字体或反复导出翻译表。