Delphi 12 字符串与编码：UTF-8、UnicodeString 与文件读写边界
2026/07/10
Delphi 12 里字符串日常用起来很顺，但只要一碰文件读写、接口返回、数据库或者老代码混用，编码边界的问题很快就会冒出来。这篇就是我自己踩坑后的整理。
我这几年在 Delphi 项目里遇到最多、也最容易被低估的问题之一，就是编码边界。平时在 IDE 里写字符串、控件里显示中文，大多数时候都没事，所以很容易让人误以为“UnicodeString 时代已经没有编码问题了”。实际并不是这样，问题只是从“字符串本身”转移到了“字符串进出系统的边界”。
最常见的坑有几个：文件读写、HTTP 接口、数据库字段、第三方 DLL、以及从老版本代码迁移过来的 AnsiString 逻辑。只要其中一个环节默认编码跟你想的不一样，结果就会非常诡异。有时候是中文乱码，有时候是长度判断错误，更麻烦的是某些场景下表面一切正常，只有到了特定机器或者特定数据才炸。
我现在处理这类问题的原则很明确：不要靠“猜默认值”，而是把编码写明白。读文件时明确指定 UTF-8 还是 ANSI，写文件时确认对方程序能按什么方式接收，接口收发时把请求头和响应内容的编码一起核实，数据库层也别偷懒，字段、连接、驱动三边都得对齐。只要开始依赖“系统应该会帮我处理好”，后面大概率会补坑。
另一个很实际的经验是，老代码里凡是还混着
PAnsiChar、AnsiString、字节数组手工转换的地方，都值得重点检查。不是说这些类型不能用，而是很多早年写法默认了本地代码页，一旦迁到新环境、接新接口，行为就不再稳定。这个阶段如果只盯着界面有没有乱码，通常是不够的。 我自己后来养成了一个习惯：只要数据要离开当前函数上下文，就先想清楚“它现在是什么编码，下一站希望它是什么编码”。这个问题听起来有点啰嗦，但真能挡掉很多低级事故。尤其是做工具类软件、日志处理、文本导入导出这类场景，编码边界想不明白，后面排查时间会非常浪费。
所以我现在对 Delphi 12 的字符串处理有个很现实的判断：日常开发确实比以前轻松，但编码问题并没有消失，只是更集中地出现在系统边界上。把这些边界盯住，比背概念更有用。