中文乱码问题看似是显示异常，但深层原因往往出在编码传递链的某个环节缺少明确的UTF-8声明。系统默认使用GBK解析，而程序实际输出的是UTF-8，导致编码错位，乱码随之产生。尤其在配置文件中包含中文路径、日志需要写入中文内容，或PowerShell调用时跳过用户配置文件（许多AI工具会添加-NoProfile参数）的情况下，乱码会悄然发生——终端显示可能暂时正常，但字节已被错误编码解读，等到AI处理时，源文件甚至可能被“写坏”。
确认并强制配置文件使用UTF-8 with BOM
OpenClaw读取config.yaml或settings.json时，若未明确指定编码，便会依赖系统ANSI——在Windows上即GBK。即使文件内容已为UTF-8，只要缺少BOM（字节顺序标记），系统仍会误判为ANSI，导致读取时出现乱码。
- 使用VS Code或Notepad++打开配置文件，查看右下角编码标识（例如显示“UTF-8”），点击后选择“Save with UTF-8 BOM”。
- 请勿使用Windows自带的记事本另存为UTF-8——它默认不带BOM。若已用记事本保存，需用其他编辑器重新转存一次。
- 验证方法：用十六进制查看器检查文件开头是否为
EF BB BF，这是UTF-8 BOM的正确签名。
PowerShell会话级编码固化
PowerShell默认的OutputEncoding为GBK，而AI工具常以-NoProfile启动，绕过您设置的个性化环境，这正是隐藏乱码最常见的来源。
- 执行以下三行命令，一次性将输入、输出、管道的编码全部对齐到UTF-8：
[Console]::InputEncoding = [System.Text.Encoding]::UTF8
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8 - 如需永久生效，运行
notepad $PROFILE，将上述三行命令粘贴进去并保存。下次启动PowerShell时即可自动加载。 - 验证方法：输入
"中文测试"，应完整显示，而非变成???或æ–‡。
启动脚本中嵌入chcp指令
批处理（.bat）或PowerShell脚本直接调用openclaw时，CMD会话仍处于CP936状态。即使配置文件正确，日志输出和交互提示仍可能出现乱码。
- 在
.bat文件的第一行添加：@chcp 65001 >nul - 在PowerShell脚本开头添加：
chcp 65001 | Out-Null - 若通过Node.js子进程调用（例如
child_process.exec），需在options中显式设置encoding: 'utf8'。
Node.js层强制解码逻辑
OpenClaw底层是Node.js应用，其fs.readFile、require('yaml')等模块若未指定编码，会使用系统默认——Windows下即为GBK。
- 若您修改过源码或使用了自定义插件，在读取中文配置的地方显式传递编码参数：
fs.readFileSync('config.yaml', 'utf8')
yaml.load(fs.readFileSync('config.yaml', 'utf8')) - 推荐全局生效：在项目根目录创建
.env文件，写入：
NODE_OPTIONS=--experimental-specifier-resolution=node --enable-source-maps
LANG=en_US.UTF-8 - 重启OpenClaw服务，使环境变量生效。
以上几个步骤看似彼此独立，但实际上覆盖了从文件存储、终端解析、进程读取到代码执行的完整链路。任何一个环节缺少显式UTF-8声明，乱码都可能在不经意的操作中突然出现。说起来并不复杂，但确实容易被忽略。