Code128编号里的空格会保留吗？先分中间空格和首尾空格

同事给来一串带空格的仓库编号，生成 Code128 后能扫码，就能认定原样保留了吗？不能。生成前的输入整理，可能已经改变了字符串；这一步与条码能否识别是不同问题。

先把不可见边界显示出来

为解释规则，下面使用人工构造的字符串，不代表真实工单编号：

输入 " ABC " → 当前规范化结果 "ABC"
输入 "A B"   → 当前规范化结果 "A B"

当前图叮条码处理会先对输入执行 trim()。首尾空白被清除，而中间的普通 ASCII 空格仍属于 Code128 当前允许的可打印字符范围。

因此，“允许空格”不能被理解为“所有位置的空格都会原样进入编码”。本文只说明当前工具处理链，不能据此说 Code128 标准禁止首尾空格。

输入原文与实际编码值各留一份

排查编号变化时，建议把两个值都用带引号的表达记录：

• 原始输入：让开头、结尾和连续空格可见；
• 规范化后的值：确认实际送入编码器的字符串。

对于测试数据，可以用 JSON.stringify() 看字符串边界；但它显示一段文本，不代表图片已经成功生成或解码。真实业务编号仍要按自己的隐私要求保存在受控记录中。

当前工具也不是任意字符都收下。Code128 路径只接受可打印 ASCII，并有 80 字符保护。含中文或不可打印控制字符的编号，不应靠替换成看起来相似的字来“修到能生成”；那会改变业务身份。

首尾空白有业务意义时，先停下来

如果业务系统明确把首尾空白算作标识的一部分，就不能直接依赖当前会去空白的流程实现原样编码。先与消费方确认字段规则，再选择满足该规则的编码路径。

如果空白只是复制时带来的多余分隔，清理之后也要让批准的编号同步更新，不要一端按原文存、一端按整理后的值比对，却把差异归给扫码器。

最后核对下载文件的解码结果

用图叮二维码与条形码工具生成后，应对最终下载文件进行识别，把解码文本与批准值逐字符比较。空格位置、字符大小写和长度都可能属于标识的一部分。

格式选择和基本字符范围可先参考EAN-13 与 Code128 的差别。生成成功证明的是这次编码流程完成，不会替你证明编号没有在输入整理阶段改变。