CAM350 脚本中文乱码完全解决
CAM350 脚本中文乱码完全解决：v12.1 .scr 的 GBK 编码、系统代码页与中文字库三层排查
写「加板边」「加流程字」这类宏时，只要脚本里出现中文，几乎一定会遇到乱码。网上最常见的回答是「把编码改成 ANSI」—— 但这只解决了其中一层。同样是乱码，可能是文件存成了 UTF-8，可能是 Windows 代码页不对，也可能是 CAM350 自带字库根本画不出汉字。三种成因现象不同、解法完全不同，混着调只会越改越乱。本文按症状分层，给出可复现的判断方法和完整解决方案。
一、先看症状：乱码长什么样，决定往哪一层查
别急着改编码。先跑一个只弹一个中文标签的最小脚本，看窗口里出来的是什么：
| 看到的现象 | 对应层次 | 第一动作 |
|---|---|---|
| 「锟斤拷」「涓枃」「涓枃鏄剧ず」这类莫名其妙的汉字，或一串问号 | 第一层：文件编码 | 把 .scr 转成 ANSI(GBK)、去 BOM |
| 中文变成方框 ■、空心块、空白 | 第三层：字库不含中文字形 | 换字体 / 外挂字库 / 转曲线，改编码无效 |
| 编码已改成 GBK 仍然乱码 | 第二层：系统代码页 | 检查 chcp 是否为 936 |
| 整个脚本不执行，第一行命令像被吃掉 | 第一层的 BOM 问题 | 去掉 UTF-8 BOM（EF BB BF） |
| 只有注释里的中文是乱的，脚本功能正常 | 无害 | 不用修，删掉中文注释更省事 |
一句话二分法：变成「别的汉字 / 问号」是字节被解错了（编码、代码页）；变成「方框 / 方块」是字形画不出来（字库）。前者改编码，后者改字体或字库，两者互不替代。
二、第一层：文件编码 —— v12.1 按 ANSI 读，不按 UTF-8 读
为什么会乱
CAM350 v12.1 的宏解释器是很老的 BASIC 实现，它按系统 ANSI 代码页逐字节读取 .scr。简体中文 Windows 上，ANSI 就是 GBK / CP936，一个汉字占 2 字节；而 UTF-8 里一个汉字占 3 字节。用记事本或现代编辑器把脚本存成 UTF-8 后，那串 3 字节序列会被硬按 2 字节一组拆开解释，于是「中文」变成「涓枃」，反复替换后就成了经典的「锟斤拷」。
带 BOM 更麻烦：UTF-8 BOM 的 EF BB BF 会落在文件最前面，老解释器不认识，轻则第一行显示异常，重则第一行命令直接失效——表现出来就是「宏点了一点反应都没有」。
正确格式：三个条件同时满足
ANSI / GBK / CP936 编码
无 BOM
CRLF 换行（LF-only 在部分版本会整段静默失效）
图形界面操作：记事本「另存为 → 编码：ANSI」；Notepad++「编码 → 转为 ANSI」后保存；VS Code 用「通过编码保存」选 GBK / gb2312。
命令行转换（推荐，可批量）
Git Bash / WSL 里用 iconv 单文件转换：
iconv -f UTF-8 -t GBK hello.scr > hello_ansi.scr
批量转换整个目录，转完再统一核对：
mkdir -p gbk for f in *.scr; do iconv -f UTF-8 -t GBK "$f" > "gbk/$f"; done
Windows PowerShell 5.1 等价写法（Default 即系统 ANSI 代码页）：
Get-Content -Raw -Encoding UTF8 hello.scr | Set-Content -Encoding Default hello_ansi.scr
注意 Set-Content 可能改变行尾，转换后确认仍是 CRLF；批量操作前先备份原文件。
怎么确认转换对了
不要靠编辑器「看起来正常」判断，直接看字节。「中文」的 GBK 编码是 D6 D0 CE C4：
od -An -tx1 -N 48 hello_ansi.scr # 应能在引号后看到 d6 d0 ce c4 ... od -An -tx1 -N 3 hello_ansi.scr # 前 3 字节若不是 ef bb bf，说明已无 BOM；首字节应为命令首字母 iconv -f GBK -t UTF-8 hello_ansi.scr | head -3 # 能正常回读出中文，说明编码正确
可直接运行的中文测试脚本
把下面内容以 ANSI/GBK 保存（文件名 encoding_test.scr），放进 Scripts 目录跑 Macro → Play：
OpenForm #1, 46, 7, "中文显示测试", character, OK AddForm #1, 2, 1, "板号 ABC123 流程 感光线路", PRINT AddForm #1, 2, 3, "Hello world !", PRINT AddForm #1, 2, 5, "中文正常 = ANSI/GBK 生效", PRINT DisplayForm #1 DeleteForm #1 end
配套还提供了一个 encoding_test_utf8.scr：内容完全相同，只是存成 UTF-8。两个脚本先后各跑一次，就能直观看到「涓枃」是怎么来的，也能顺带验证本机 CAM350 到底按哪个代码页在读文件。
三、第二层：系统代码页 —— GBK 存对了还是乱
文件是 GBK，中文依然乱码，问题通常不在文件，而在 Windows 把 ANSI 解释成了别的代码页。打开 cmd 输入：
chcp
输出 活动代码页: 936 才是简体中文 GBK。如果是 437、1252（英文系统）或 65001（UTF-8），老程序按 GBK 存的字节就会被按别的规则解读，照样乱码。
常见原因和对应处理：
| 情况 | 处理 |
|---|---|
| 英文版 / 繁体版 Windows，或区域设置为非简体中文 | 控制面板 → 区域 → 管理 → 「非 Unicode 程序的语言」改为中文（简体，中国），重启生效 |
| 勾选了「Beta: 使用 Unicode UTF-8 提供全球语言支持」 | 取消勾选并重启。该选项会把 ANSI 代码页改成 65001，几乎所有老版 CAM / CAD 软件的中文都会乱 |
| 公司统一镜像不便改系统设置 | 脚本保持全 ASCII；或在中文区域设置的虚拟机 / 专用机里跑宏 |
改完 chcp 复查一次，再跑 encoding_test.scr。这一层经常被忽略，也是「我明明存成 ANSI 了怎么还乱」最常见的答案。
四、第三层：字库 —— 编码全对，中文仍是方框
前两层解决的是脚本字符串在窗体标签、提示里的显示。但另一类中文是写进 CAM 图形数据的：用 add_text@ 之类命令加板号、流程字、日期字到板上。这时即使编码、代码页全对，中文也可能变成方块 —— 因为 CAM350 内置的 stroke 字体（默认 Simple 一类）本身不含中文字形，它不是「解错字节」，而是「根本没有这个字」。
三条可行路线：
外挂中文字库。国内 CAM 工程普遍用
*.clb字库，宏里先加载字库再写文字，典型写法（路径按本机实际字库位置改）：
lib_setextlib@ 1,1,1,"c:\ACT_60\scripts\work.clb" set_caplib@ 1
这也是很多「加板边 / 流程字」宏必须随附一个字库文件、换机器就失效的原因 —— 迁移时字库和路径要一起带走。
中文转曲线 / 图形：把文字先转成多边形或线段再写入 CAM 数据，不依赖字库，跨机器最稳，代价是数据量大、后期不可编辑。
只用英文代号：板号、流程、日期一律用 ASCII 字符（如
A1、ROUTE、20261108），最省事，也最不容易在交接时出问题。
另外，窗体里中文显示成方框时，也可以检查 Settings → Text → Font 选的字体是否包含中文字形；这一项只影响界面文字，不影响写入 CAM 数据的图形文字，别和第三条路线混为一谈。
五、完整排查顺序
跑最小中文脚本（
encoding_test.scr），先看症状属于「别的汉字 / 问号」还是「方框」。查文件：
od看有没有EF BB BF开头、中文是不是D6 D0 ...这类 GBK 字节；不对就用iconv转，并确认 CRLF。查代码页：
chcp必须是 936；不是就改区域设置 / 关掉 UTF-8 全球支持并重启。再跑一次：窗体标签里的中文正常了，第一、二层解决。
检查写入 CAM 数据的中文：仍是方框 ⇒ 第三层，加载
.clb字库或转曲线，与编码无关。注释乱码不用管：只要功能正常，删掉中文注释即可，不必为此折腾编码。
排查时一次只改一个变量。同时改编码、改代码页、换字体，最后好了也不知道是哪个起作用，下次换台机器又会重来一遍。
六、工程规范：最省事的做法是全 ASCII
把上面所有坑一次性绕开的办法，是让脚本源码保持全 ASCII：变量名、窗体标题、提示、日志一律英文或拼音代号，中文只交给外部 GBK 文本或字库处理。这样换机器、换系统语言、换 CAM350 小版本都不用重新调编码。
脚本文件统一：ANSI/GBK + 无 BOM + CRLF，或用纯 ASCII（两种编码等价，最安全）。
中文文案外置到单独的 GBK 文本文件，用
LINE INPUT#读入；读入后仍受代码页影响，所以跨机器交付时优先用代号。字库文件与脚本一起备份、一起版本管理，路径写相对路径或统一固定目录。
重装 CAM350 会重置安装目录，
Scripts里的脚本和字库都会被清掉，务必单独留一份。
七、几个常见误区
| 说法 | 实际情况 |
|---|---|
| 「统一改成 UTF-8 更通用」 | 对现代编辑器成立，对 v12.1 宏解释器恰好相反，它按 ANSI 读 |
| 「加个 BOM 保证编码不出错」 | BOM 会落到脚本首行，老解释器可能直接让第一行命令失效 |
| 「装个中文字体就好了」 | 只可能改善窗体界面文字；写入 CAM 图形数据的 stroke 文字要看 CAM350 字库，不是系统字体 |
| 「注释乱码说明脚本坏了」 | 注释不参与执行，通常无害 |
| 「14.6 的脚本照这个改」 | 14.6 的 .vbs 是 WinWrap Basic / COM 另一套引擎，本文结论针对 .scr 宏，不能照搬 |
| 「Macro → Play 没反应也是编码问题」 | 不一定。也可能是安装损坏：用 Macro → Record 能否正常生成 .scr 来判断，必要时重装 |
八、一页速查
| 层次 | 判据 | 解法 |
|---|---|---|
| 文件编码 | 乱码汉字 / 问号 / 首行失效 | ANSI(GBK) + 无 BOM + CRLF；iconv -f UTF-8 -t GBK |
| 系统代码页 | 文件已是 GBK 仍乱；chcp 非 936 | 区域设置改中文（简体，中国）、关闭 UTF-8 全球支持、重启 |
| 字库 | 中文变方框 / 空心块 | 外挂 .clb 字库、中文转曲线、或改用 ASCII 代号 |
把「字节解错」和「字形缺失」分开，中文乱码就不再是玄学：前者改编码与代码页，后者改字库或数据形态。按这个顺序走一遍，v12.1 的加板边、流程字、板号标注这些中文字处理都能稳定下来。
原创技术稿 · 适用 CAM350 v12.1 / .scr 宏体系 · 转载请注明出处
