JavaScript中非标准字符串输入处理策略与最佳实践

先说结论：处理非标准字符串输入时，核心策略并非“一刀切地过滤”，而是要清楚数据来源与去向，再有针对性地进行清洗或转义。JavaScript 中常见的坑包括不可见字符、编码混搭、BOM 头、多余空白、HTML 实体以及转义序列——这些问题会导致字符串解析报错、比较失败，甚至埋下安全漏洞。下面逐一拆解。

识别并剥离 BOM 与控制字符

UTF-8 文件开头有时会携带 BOM（uFEFF），某些编辑器或后端响应可能悄悄将它塞入数据。而 ASCII 控制字符（如 u0000 到 u001F，不包括空格、制表符、换行符）常被用来隐藏注入内容或干扰正常解析。

• 用正则剔除常见控制字符（保留空格、换行、制表符）：str.replace(/[u0000-u0008u000Bu000Cu000E-u001Fu007F-u009F]/g, '')
• 检测并移除 BOM：str = str.replace(/^uFEFF/, '')，建议在接收到字符串后第一时间处理
• 注意：不要盲目使用 trim() 替代——它只去除首尾空白，对中间的零宽字符（比如 u200B）完全无效

统一编码与 Unicode 规范化

用户粘贴、跨平台复制或旧系统导出的数据中，经常出现视觉相同但码点不同的字符——全角数字 １ 与半角 1 就是典型例子。Unicode 标准化可以显著提升数据一致性。

• 优先使用 str.normalize('NFC')（兼容组合形式），适用于大多数显示与比较场景
• 如需彻底扁平化（例如搜索、用户名校验），可结合替换：str.normalize('NFD').replace(/[u0300-u036f]/g, '') 去除变音符号
• 避免直接用 escape 或 encodeURI 处理原始字符串——它们专为 URL 场景设计，会破坏可读性

安全处理 HTML 实体与转义序列

从富文本编辑器、API 返回或用户输入获取的字符串，可能包含 &、< 或 é 这类实体。是否需要解码，完全取决于后续用途。

• 若用于 DOM 渲染（如 textContent），无需手动解码——浏览器会自动处理，且更安全
• 如果需要还原为原始字符（比如日志分析、数据清洗），可用临时 DOM 元素解码：new DOMParser().parseFromString(`

  ${str}

  `, 'text/html').documentElement.textContent
• 务必警惕 eval、Function 或 innerHTML 直接执行未清洗的字符串——即使已解码，仍可能暗含恶意脚本

按用途选择清洗策略

不存在“万能清洗函数”。同一个字符串，在表单验证、URL 构造、JSON 序列化、正则匹配中使用时，要求千差万别。

• 用于正则匹配前：先执行 normalize()，再确保特殊字符被正确转义（例如 str.replace(/[.*+?^${}()|[]\\]/g, '\\$&')）
• 构造 URL 参数：使用 encodeURIComponent()，而非 encodeURI() 或手动替换
• 存入数据库或发送 API 请求体：通常保持原始语义，由后端负责校验；前端只需确保 JSON 序列化不报错（JSON.stringify 会自动处理绝大多数边界情况）