如何使用Python 2正确实现EBCDIC文件到ASCII的转换

你现在遇到的转码失败本质是两个认知偏差：

1. EBCDIC不是单一编码，而是IBM主机体系下几十种不同代码页的统称，不同地区、不同系统版本、不同业务场景使用的EBCDIC代码页完全不同，cp500只是通用国际EBCDIC代码页，和你文件实际使用的代码页不匹配，自然会出现字符映射错位。
2. 你手里的文件根本不是纯文本EBCDIC文件。标准EBCDIC编码中大写字母'P'的固定码值是0xD7，所有标准EBCDIC文本代码页中0x50都对应'&'，和你观察到的“0x50位置实际应为'P'”的现象完全矛盾，结合你提到的文件开头存在NUL字节、特定位置内嵌图片数据的特征，这是典型的包含结构化字段的主机导出文件：文件里混合了二进制控制头、压缩数值、纯二进制资源、EBCDIC文本段等不同类型的内容，根本不存在整文件统一转ASCII的可能。

不要上来就对整个文件做转码操作，按以下步骤处理：

• 第一步：先确认文件结构
  这类混合结构文件基本都是COBOL程序导出的定长记录文件，所有字段的偏移位置、长度、数据类型都在对应的copybook定义里写死了，优先找文件提供方索要结构说明，明确区分哪些偏移段是EBCDIC文本、哪些是纯二进制内容（数值、图片等）。
• 第二步：匹配文本段对应的正确EBCDIC代码页
  定位到纯文本段后，根据文件来源匹配对应代码页，不要默认用cp500：
  • 北美z/OS系统常用cp037
  • z/OS UNIX开放环境常用cp1047
  • 德语区常用cp273，法语区常用cp297，简体中文主机环境常用cp1388
    提取一小段已知内容的文本字节，逐个测试上述代码页，直到解码结果和预期字符完全匹配即可。
• 第三步：分段处理内容，二进制字段绝对不能转码
  必须用二进制模式('rb')读取整个文件，按照结构定义拆分字段：
  • 二进制头、压缩数值、内嵌图片这类非文本字段，直接保留原始字节，任何编码转换都会损坏这部分数据
  • 仅对EBCDIC文本段，用匹配到的正确代码页解码为Unicode，再根据需要编码为ASCII，非ASCII字符可以指定errors='replace'做替换避免报错。

Python2环境下的参考实现：

# 示例结构定义：前3字节为二进制头，3-20字节为EBCDIC文本段，20字节之后为二进制图片数据
with open(target_path, 'rb') as input_f:
    raw_bytes = input_f.read()

# 按结构拆分字段
bin_header = raw_bytes[0:3]  # 二进制头保留原始字节
ebcdic_text_part = raw_bytes[3:20]
bin_img_data = raw_bytes[20:]  # 图片数据保留原始字节

# 仅转码文本段
unicode_text = ebcdic_text_part.decode('cp037')  # 替换为你实际匹配到的代码页
# 转ASCII时对无法映射的字符做替换，避免抛出异常
ascii_text = unicode_text.encode('ascii', errors='replace')

• 整文件用cp500/codecs/io指定编码读取：一方面代码页可能不匹配，另一方面把二进制字段当文本解码，必然出现乱码、字符错位，还会损坏二进制资源。
• 整文件用utf8解码：EBCDIC字符和二进制字节不符合UTF-8编码规则，抛出解码错误是正常现象。
• 用latin1打开和Notepad++显示一致：latin1是单字节透明编码，每个0x00-0xFF的字节会直接映射到对应Unicode码点，相当于原封不动展示原始字节，根本没有做任何转码，自然不会报错，但也完全没有实现转换目的。
• 自定义全局映射表的方案完全不可行：EBCDIC和ASCII的码位不存在一一对应关系，全局映射不仅会出现你提到的码位冲突，还会直接破坏文件里的二进制字段内容，后续根本没法提取图片等资源。

内容的提问来源于stack exchange，提问作者Ramandeep Mehmi