如何编码原始字节？Data Matrix条码触发Chrome下载问题排查

我们有一个2D Data Matrix条码，扫描输出为12002052（值后带CR+LF），在Chrome中扫描会触发下载菜单，已知是CR+LF导致的。为排查问题，我们用在线生成器生成了内容为12002052的新条码，该条码在Chrome中扫描正常，但在显示所有字符的Notepad++中，输出与原问题条码完全一致。

将两个条码的图片上传至zxing解码网站后，发现二者的**raw bytes（原始字节）**最后一位数值不同：

问题条码解码信息 #

Raw text                12002052
Raw bytes               8e 82 96 b6 81 
Barcode format          DATA_MATRIX
Parsed Result Type      TEXT
Parsed Result           12002052

正常条码解码信息 #

Raw text                12002052
Raw bytes               8e 82 96 b6 0b
Barcode format          DATA_MATRIX
Parsed Result Type      TEXT
Parsed Result           12002052

现咨询：

1. 「raw bytes（原始字节）」具体指什么？
2. 如何对其进行编码，以反向排查两个条码的差异？

1. 「raw bytes（原始字节）」的定义 #

Data Matrix条码的核心是存储二进制字节流，raw bytes就是条码内部实际存储的、未经任何解析转换的原始二进制数据。解码工具会按照预设的字符编码规则（如ASCII、UTF-8）将这些字节转换为可读文本（即解码结果里的Raw text和Parsed Result）。

你遇到的情况中，两个条码解析出的文本完全一致，但raw bytes存在差异，说明它们存储的二进制数据不同，只是在文本解析阶段被处理成了相同的输出——差异出现在控制类字节上，这类字节在常规文本显示中可能被隐藏，但会被扫描器特殊解析。

2. 编码反向排查差异的方法 #

解析单个字节的含义 #

先明确两个条码最后一位字节对应的ASCII控制字符：

• 问题条码最后字节0x81：属于ISO-8859-1扩展字符集的设备控制1（DC1），部分扫描器会将其解析为CR+LF组合，这就是Chrome触发下载菜单的直接原因。
• 正常条码最后字节0x0b：对应ASCII标准的垂直制表符（VT），该字符不会被扫描器解析为CR+LF，因此不会触发Chrome的下载行为。

生成对应字节的条码验证 #

使用支持直接输入二进制字节的Data Matrix生成工具，分别输入两组完整raw bytes：

• 问题条码字节序列：0x8e 0x82 0x96 0xb6 0x81
• 正常条码字节序列：0x8e 0x82 0x96 0xb6 0x0b

生成条码后扫描测试，即可复现原问题条码的CR+LF输出和正常条码的表现，直接验证字节差异的影响。

对比生成时的编码规则 #

检查两个条码的生成逻辑：问题条码大概率是在生成时使用了非标准编码，给文本12002052附加了控制字节0x81；而正常条码使用标准编码方案，仅存储了对应文本的字节，最后一位0x0b可能是生成工具自动添加的结束标记，但不会触发扫描器的CR+LF解析。

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