1. 问题背景ERP物料档案为何会乱去年夏天我接手了一个ERP系统物料档案混乱的紧急修复项目。采购部同事反映他们连续三个月无法正常下单系统总是提示物料不存在或编码错误。最诡异的是——在ERP界面明明能看到这个物料但就是无法通过搜索找到也无法在下单时选择。经过初步排查我们发现问题的核心在于物料编码中混入了不可见字符。这些字符在界面上完全不显示但在系统底层却真实存在导致所有基于编码的查询、匹配操作全部失效。采购部每次都要手动复制粘贴编码才能完成操作效率直线下降。提示ERP系统中的物料编码就像身份证号必须是唯一且纯净的字符串。任何不可见字符的混入都会导致系统识别异常。2. 不可见字符的检测与定位2.1 肉眼不可见的幽灵字符我们首先用了一个简单的方法验证问题将物料编码复制到记事本中。正常情况下纯数字或字母组合在记事本中应该完全一致。但我们发现某些编码在记事本中会显示为方框或空白这就是典型的不可见字符特征。通过Hex编辑器进一步分析发现这些编码中混入了以下特殊字符零宽度空格Unicode U200B软连字符Unicode U00AD字节顺序标记BOMUFEFF2.2 问题根源追溯经过代码审查我们发现问题的产生有两个关键路径外部系统对接时FastJSON序列化未正确处理转义字符物料导入功能中C#读取Excel文件时未过滤等特殊符号特别是当采购员从1688等平台复制物料信息时平台自带的富文本格式会携带这些隐形字符。而我们的ERP系统接口没有做严格的输入过滤。3. 解决方案设计与实施3.1 临时应急方案我们先用SQL脚本对现有数据库进行清理UPDATE material SET code REPLACE( REPLACE( REPLACE(code, CHAR(0x200B), ), CHAR(0x00AD), ), CHAR(0xFEFF), ) WHERE code LIKE % CHAR(0x200B) % OR code LIKE % CHAR(0x00AD) % OR code LIKE % CHAR(0xFEFF) %同时为采购部提供了临时检查工具def has_invisible_chars(text): return any(ord(c) in (0x200B, 0x00AD, 0xFEFF) for c in text)3.2 永久修复方案我们在三个层面建立了防护网前端防护所有物料编码输入框增加正则校验/^[\w\-]$/.test(code) // 只允许字母、数字、下划线和连字符后端防护在Spring拦截器中添加字符过滤String sanitized code.replaceAll([\\u200B\\u00AD\\uFEFF], );数据库防护创建触发器检查新增/修改的记录CREATE TRIGGER check_material_code BEFORE INSERT OR UPDATE ON material FOR EACH ROW BEGIN IF NEW.code REGEXP [[:cntrl:]] THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT Invalid character in material code; END IF; END;4. 经验总结与避坑指南4.1 血泪教训不要相信界面显示我们最初浪费了两周时间因为所有检查都在ERP界面进行而界面自动过滤了这些字符。直到导出原始数据才发现问题。系统对接要加白名单与1688等平台对接时应该只允许明确需要的字符通过而不是试图过滤所有非法字符。日志要记录原始数据我们的审计日志存储的是处理后的数据导致无法追溯问题源头。4.2 推荐工具链检测工具Notepad显示所有字符View → Show Symbol → Show All CharactersHex Editor Neo直接查看二进制编码开发辅助// C#中检测不可见字符的方法 bool ContainsInvisibleChars(string input) { return input.Any(c char.IsControl(c) !char.IsWhiteSpace(c)); }监控方案在ELK日志系统中添加告警规则当出现异常字符时触发通知这次事故给我们的最大启示是ERP系统的数据纯洁性就像饮用水安全必须建立从源头到终端的全流程防护。一个肉眼看不见的字符足以让整个采购体系瘫痪三个月。现在我们在所有关键字段上都实施了三重过滤机制确保类似问题永远不会再现。
