MySQL与Java字符编码适配问题：读取注册商标符号®生成PDF时显示为fi

首先明确基础判断：注册商标符号®输出为fi而非通用乱码（替换符�、缺字方块），说明问题并非单纯的MySQL字符集不兼容，可沿数据流向分环节定位修复。

1. 核查JDBC数据读取环节的编码匹配 #

既然MySQL命令行客户端能正常读取显示®，说明数据库存储的字符本身是正确的，首先要校验Java从数据库拿到的字符串是否解码正确：

• 核查JDBC连接串配置，必须显式指定统一的字符集规则，不能依赖驱动的默认配置。正确的连接串配置示例为：
  jdbc:mysql://<数据库地址>:<端口>/<库名>?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
  部分版本的MySQL驱动在未显式设置characterEncoding参数时，会默认使用和数据库服务端不匹配的解码规则，虽不会直接将®解析为fi，但可能造成字符解码错位，触发后续渲染环节的异常映射。
• 做最小正确性校验：从数据库获取产品名称字符串后，直接在控制台打印，遍历每个字符输出其Unicode十进制值。如果®对应的字符值不是174（即U+00AE的十进制值），说明问题出在JDBC读取层，对照上述连接串配置修正即可；如果控制台输出的字符值完全正确，说明后续异常和MySQL编码完全无关，直接排查PDF生成环节。

2. 定位PDF渲染环节的字体映射问题 #

这是®输出为fi的最高发诱因：

• 核心原因：常用的PDF生成组件（iText、PDFBox、可视化报表工具等）默认使用的内置西文字体（如Helvetica）未覆盖®这类拉丁扩展符号，同时字体渲染默认开启了自动连字（Ligature）匹配逻辑。当渲染引擎遇到字体中不存在的®字符时，会出现字符索引错位，直接匹配到fi连字的对应字形，最终在PDF中输出fi文本。
• 对应修复操作：
  • 放弃PDF组件自带的默认西文字体，加载覆盖全拉丁扩展字符的字体文件（如思源黑体、常规宋体），在PDF文本渲染前显式指定使用的字体路径，不依赖默认字体的兜底逻辑。
  • 关闭PDF渲染层面的自动连字替换：根据使用的生成组件配置对应参数，关闭字距调整和连字自动替换逻辑，避免不存在的字符被错误映射为其他字形。
  • 如果使用可视化报表工具生成PDF，需要逐次检查模板中所有文本框的字体设置，避免文本框默认继承内置Helvetica字体，统一绑定覆盖全字符集的自定义字体。

常见避坑提示：不要一上来就修改MySQL库表的字符集配置，既然命令行客户端能正确显示®，说明数据库存储的字符编码本身完全正确，仅调整数据库配置根本解决不了PDF端的字符错位问题，纯属无效操作。

内容的提问来源于stack exchange，提问作者N.B