COBOL报表打印出乱码这种事，听过的人多，真正一步步排查过的人少。你说它难吧，无非就是字符在“生成—传输—打印”这条链路上某个环节被换了个模样；你说它简单吧，要在老旧的COBOL程序、主机系统、打印机驱动程序之间找出那一个搞事情的字节，有时候真能让人熬掉半宿。这篇文章就打算用大白话，把从编码到设备控制符的排查路径好好捋一遍。顺便说一句，例子里的命令都是用Shell写的，因为到了排查阶段，用Shell直接看字节流最顺手，COBOL程序本身只需要知道它输出了什么，剩下的交给脚本和工具。

一、乱码是怎么“码”出来的

报表里出现的乱码，不外乎两种来路。第一是字符编码本身对不上。比如COBOL程序在主机上用的是EBCDIC码，而打印机或中间传输系统却按ASCII码来解读。同一个字节数字，两边表示的意思完全不一样。第二是设备控制符在捣乱。比如换页符、回车符、字体切换指令，它们被当成可打印字符送到报表里，于是纸上出现了奇怪的小方块、小三角。打个比方，就像你明明把文件放进了标着“A”的抽屉，结果别人从标着“B”的抽屉里把它拿走了，最后你拿到手的东西自然不是你要的样子。

二、排查前的准备工作

动手之前，把下面几件事问清楚，后面能省一半时间。第一，COBOL程序跑在哪个系统上？是IBM大型机还是Linux上的GnuCOBOL？第二，报表输出到文件，还是直接从程序里往打印机写？第三，打印机是什么品牌型号？它支持哪些代码页？第四，乱码是否只出现在某些固定的列或者固定的字符上？把这些问题记在小本本上，然后开始一步步来。

2.1 准备用顺手的工具

咱们这里的示例统一用Shell，主要靠Linux环境自带的工具。你需要准备：hexdump（或者xxd）、iconv、file、sed，还有最常见的grep。别担心，这些工具都是老牌工具，稳定得很。下面这条命令可以快速确认一下你的环境里有没有这些程序：

# 检查Shell工具是否齐全
for cmd in file hexdump iconv sed grep; do
  if command -v "$cmd" >/dev/null 2>&1; then
    echo "$cmd 可用"
  else
    echo "$cmd 缺失，请先安装"
  fi
done

三、系统化排查步骤

排查乱码最忌讳瞎猜，一定要按顺序来。下面这七个步骤，每一步都对应一个明确的检查点，执行完基本就能锁定问题在哪。

3.1 第一步：用file命令看文件编码

COBOL程序生成的报表文件，如果是个文本文件，file命令能快速给出编码类型。比如：

# 查看报表文件的原始编码
file -bi report.prt

如果输出显示“text/plain; charset=utf-8”，说明文件这层没问题。但要是显示“application/octet-stream”，那多半是二进制流，里面混了不少EBCDIC或者未知控制码，这时候就得继续挖。

3.2 第二步：用hexdump看原始字节

编码猜测靠经验，但字节才是真相。用hexdump把报表文件开头几十个字节列出来，跟ASCII码表对一下。比如：

# 输出文件前128字节的十六进制和ASCII字符
hexdump -C report.prt | head -20

你可能会看到类似“40 40 40”这样的序列，这在EBCDIC里是空格，但在ASCII里是字符“@”。如果你看到一溜“@”，那说明数据还是EBCDIC，没转过来。

3.3 第三步：理解EBCDIC和ASCII的区别

这里稍微多嘴一句。EBCDIC是IBM大型机上用的编码体系，它把字母、数字和符号编排在完全不同的位置上。比如英文字母“A”在EBCDIC中是0xC1，而在ASCII中是0x41。如果你拿ASCII的规则去解读EBCDIC的字节，不但英文会错，中文更是直接变成“天书”。搞清楚这一点，你就明白为什么很多COBOL报表传到非IBM环境后，会出现一大堆莫名其妙的符号。更重要的是，很多COBOL程序里写死的控制字符（比如用DISPLAY输出一个HEX当作空格），在不同编码体系下含义完全不同。所以排查时，一定要先确认报表文件本身是哪种编码，再做下一步。

3.4 第四步：用iconv做编码转换测试

确定了文件里的编码是EBCDIC之后，就可以用iconv把它转成ASCII或者UTF-8试试效果。比如，用IBM037代码页（很多COBOL报表默认用这个）转成UTF-8：

# 将EBCDIC（IBM037）转成UTF-8，输出到新文件
iconv -f IBM037 -t UTF-8 report.prt > report_utf8.prt

转完之后再用cat或者less打开看看，如果汉字和数字都正常了，问题就锁定在编码转换环节。如果转出来还是乱，说明原始编码可能不是IBM037，你得去问一下COBOL程序的编译地方，比如JCL里有没有指定别的代码页。

3.5 第五步：清理换行符和控制字符

报表乱码有时候不是字符集的问题，而是控制符没被正确识别。COBOL输出常常自带“回车换行（CRLF）”或者“换行（LF）”，但不同的打印协议对这两个字符的理解不一样。你可以用sed来查看并修复。下面这条命令把CRLF统一改成本地换行，再把讨厌的换页符（0x0C）过滤掉：

# 将文件中的CRLF统一调整为LF，并移除换页符
sed -e 's/\r$//' -e 's/\x0c//g' report_utf8.prt > report_clean.prt

执行完再使用file命令看看，文件变成了干净的文本。有时候还需要把制表符（0x09）转成空格，避免打印机把它解释成跳到下个输出位置。

3.6 第六步：排查打印机控制符

还有一类乱码来自设备控制符，比如ESC/P、PCL 里的某些转义序列，它们开头是 ESC（0x1b）。在打印前，先用grep查一下是否存在 ESC 字符：

# 查找是否含有ESC控制符（列出所有匹配行）
grep -n $'\x1b' report_clean.prt

如果有一堆输出，说明报表带了不少打印机指令。你需要对照打印机手册，确认这些指令是否和当前打印机型号匹配。不匹配的指令会被打印机当作普通字符打印，于是乱码就出现了。特别留意一下“\x1b&l1H”这种常见于HP激光打印机的换页序列，如果你的目标打印机是爱普生，那它可能就不认账。

3.7 第七步：用测试报文直接打打印机

到了这一步，最好写一个只含几行文本的小文件，直接发给打印机测试。这样能快速区分是文件的问题还是打印机配置的问题。比如：

# 生成一个简单的测试报文，包含中文、数字和制表符
printf '订单号\t数量\t金额\nA001\t2\t10.00\n' > testprint.txt
iconv -f UTF-8 -t GB18030 testprint.txt > testprint_gb.txt
lp -o raw testprint_gb.txt

如果打印出来还是乱，那就得检查打印机驱动和代码页设置，而不是继续在COBOL程序里找问题。注意，lp -o raw 的意思是让打印队列不要对内容做任何转换，直接发给打印机。如果你用的是Windows打印服务器，可能就要用“直接打印”选项。

四、解决方案与示例

排查清楚之后，解决方法通常有四种。第一种，在COBOL程序里直接使用可兼容的编码输出。第二种，在中间层转换，也就是用Shell脚本在报表文件分发之前做一次“清洗”。第三种，调整打印机端的代码页设置，让打印机按你期望的编码去解释。第四种，如果控制符不兼容，就改程序，把旧的打印机指令改成目标打印机支持的指令。下面分别说一说。

4.1 方案一：在COBOL程序里改编码

如果COBOL程序是用GnuCOBOL编译的，你可以在运行时通过环境变量来覆盖默认字符集。比如在Shell里设置：

# 设置GnuCOBOL的运行时字符集为UTF-8
export COB_LANG=zh_CN.UTF-8
./my_report_program

这样做的好处是源文件不用动，坏处是运行的机器上必须装了对应的locale。大型机上的老COBOL程序一般不走这条路，因为系统里头的EBCDIC代码页绕不开。所以这个方案只适合跑在开放系统上的GnuCOBOL场景。

4.2 方案二：用Shell脚本做中间层转换

这是最推荐的方案。在不改动老程序的前提下，把报表输出文件用脚本清洗一遍。下面是一个完整脚本示例。

4.3 方案三：调整打印机代码页

很多打印机的面板或Web管理页面里有“代码页”设置。把打印机调成和报表文件一样的编码，乱码可能立刻消失。比如报表是GB18030，就把打印机的默认代码页设成GB18030。不过这招只对文本打印有效，要是遇到图形报表，那就得另想办法。

4.4 方案四：更换打印机控制符

某些老报表里写死了“ESC V”之类的换页指令，遇到不支持这种指令的打印机就会打出一堆乱码。这时候你需要把旧的指令替换成新打印机的指令。比如用Shell把ESC V换成ESC & l 1H：

# 将ESC V（0x1b 0x56）替换成ESC & l 1H（0x1b 0x26 0x6c 0x31 0x48）
sed 's/\x1b\x56/\x1b\x26\x6c\x31\x48/g' report_clean.prt > report_pcl.prt

替换前一定要确认目标打印机支持PCL指令，不然就是白忙活。

4.5 完整清洗脚本示例

下面这个脚本把上面几步串起来。你把它保存成fix_report.sh，按照实际情况改文件名就能用。

#!/bin/bash
# fix_report.sh - COBOL报表乱码清洗脚本
# 用法：./fix_report.sh 原始报表 输出文件

set -e

INPUT_FILE="${1:?请给出输入文件名}"
OUTPUT_FILE="${2:?请给出输出文件名}"

# 第一步：查看输入文件的编码信息
echo "=== 文件最初编码 ==="
file -bi "$INPUT_FILE"

# 第二步：假设原始编码是IBM037，转换成UTF-8
echo "=== 转换为UTF-8 ==="
iconv -f IBM037 -t UTF-8 "$INPUT_FILE" > /tmp/report_utf8.tmp || {
  echo "转换失败，请检查编码是否真的是IBM037"
  exit 1
}

# 第三步：去掉CR和换页符
echo "=== 清理控制符 ==="
sed -e 's/\r$//' -e 's/\x0c//g' /tmp/report_utf8.tmp > "$OUTPUT_FILE"

# 第四步：在屏幕上简单预览前几行
echo "=== 清理完成，前5行预览 ==="
head -5 "$OUTPUT_FILE"

# 第五步：再次检查最终编码
echo "=== 最终编码 ==="
file -bi "$OUTPUT_FILE"

注意脚本里的临时文件名是 /tmp/report_utf8.tmp，没有空格，放心用。如果原始编码不是IBM037，你可以把第二行中的IBM037改成你确认的代码页，比如IBM1140、IBM284等。脚本只处理了最基础的场景，如果你遇到混合编码或者二进制流，还得再加判断逻辑。

五、一个典型案例的完整复盘

为了让你更直观地理解怎么用，咱们模拟一个实际场景。某银行的COBOL程序在IBM主机上生成日报，运维人员把文件传到Linux服务器上，再通过Samba打印机共享打印。结果打印出来的数字后面多了“@”和“¤”。按照上面的步骤，先file查看，是“application/octet-stream”。用hexdump一看，有很多0x40。0x40是EBCDIC的空格，但按ASCII解释就是“@”。我们又发现文件换行用的是0x25，这在EBCDIC里是换行符，到了ASCII却被当成了“%”。结论是，文件没有经过EBCDIC到ASCII的转换。我们把IBM037转成ISO-8859-1后，“@”消失了，数字也对齐了。接着用sed去掉CR和换页符，再交给打印机，完美输出。整个过程里，COBOL程序本身没动过一个字母，问题出在了传输链路上的编码转换缺失。

六、这些坑你得提前踩个遍

有几个容易忽略的地方，必须提醒你。第一，别上来就在COBOL程序里改代码，先分析字节流，不然可能改了半天毫无起色。第二，转换编码时，别把原始文件直接覆盖，一定保留备份，否则转错了想回头都难。第三，测试时一定要用真实数据的一小段，别只拿“Hello World”测，真实数据里的控制符五花八门，不提前用真实数据试，上线了照样乱。第四，Shell脚本在Windows下用可能会因为换行符跑不起来，用dos2unix处理一下。第五，iconv不是万能的，遇到自定义代码页或是混合编码时，可能需要写个小程序做逐字节映射。

七、各种方案的优缺点对比

把编码转换放在COBOL程序内部，好处是输出文件从一开始就是干净的，方便中间环节处理；缺点是改动历史程序风险大，需要重新编译，而且很多老程序员已经不在了。放在中间层用Shell脚本处理，好处是灵活，不用碰老代码，随时能调整；缺点是增加了一次I/O，大批量报表可能拖慢速度。调整打印机代码页，好处是零成本；缺点是只能迁就打印机，如果打印机型号老旧或品牌混杂，管理起来很麻烦。改打印机控制符，比如把旧的ESC/P切换成PCL，好处是让老程序也能适配新设备，缺点是要吃透两套指令集，测试量不小。综合来看，除非历史包袱特别轻，否则我建议优先用中间层脚本，它的性价比最高。

八、文章总结

COBOL报表乱码说到底就是字符编码和设备控制符在链路各环节的不匹配。只要按照“先看文件编码，再做字节流分析，接着清控制字符，最后测打印机”这个顺序来，基本都能把问题钉死。不要一上来就翻COBOL源码，那会浪费大量时间。这篇文章里的命令和脚本，你可以直接拿去用，但务必先在测试环境对比一下输出。等哪天真遇到稀奇古怪的乱码，记得先深呼吸，然后看看字节流——那里面藏着所有答案。