【入门夯实】火星文公告：文件编码错位让中文串变乱码

学员常见误区

脚本在本机跑得好好的，传到服务器中文公告变火星文：兑换成功四个字成了六串怪符号。根因是编码错位——编辑器用 GBK/ANSI 保存，引擎按 UTF-8 解读，同一个"兑"字两种码表各说各话。更隐蔽的是 pattern 里的中文：字符串字节整体错位后，中文匹配永远失手，而纯英文代码段一点症状都没有，问题就像随机出现。错误场景：

-- 兑换柜台：祖玛头像换金条
local function exchange(actor)
    actor = getplayerbyname(actor)
    sendmsg(actor, 1, "兑换成功，获得金条")
end

代码一行没错，错在文件落盘的码表。

正确姿势

全链路统一 UTF-8（无 BOM）：编辑器保存格式设为 UTF-8、上传工具关掉自动转码、引擎加载端保持默认。用文件头三字节做体检：UTF-8 BOM 是 239、187、191，GBK 中文首字节则落在另一些区段。示例代码如下：

local function checkFileHead(path)
    local f = io.open(path, "rb")
    if f == nil then
        return "file missing"
    end
    local head = f:read(3)
    f:close()
    if head == "\239\187\191" then
        return "UTF-8 with BOM"
    end
    return "no BOM"
end

本篇的新技术点是字节级体检：不看编辑器自报的编码名，直接读文件头字节下结论，GBK 的伪装一查便知。

引擎验证

三步验证：故意把测试脚本另存为 ANSI 重载，观察公告乱码与中文 pattern 失配；转回 UTF-8 无 BOM 再重载，公告恢复且 triggerchat 中文指令正常命中；用 checkFileHead 抽查三个脚本文件头，确认全部无 BOM 且中文正常。

举一反三

散落在代码里的中文字符串越多，编码事故面越大：把玩家可见文案集中到一张表里，脚本只引用键名，乱码只需修一处。示例代码如下：

local TEXT = {
    exchangeOk = "兑换成功，获得 2 根金条",
    lackItem = "祖玛头像不足，无法兑换",
}