Unicode编码绕过生效的根本原因是解码时机错位，即WAF或过滤器在原始字节流上匹配，而业务代码在多次解码后的语义字符串上执行，导致同一输入在不同环节呈现不同形态，从而绕过检测。

Unicode编码绕过为什么能生效

不是因为Unicode本身危险，而是因为解码时机错位。用户输入可能被多次编码：前端URL编码、JSON字符串转义、后端又做了一次HTML实体还原——request.getParameter("q")拿到的常常是已部分解码的中间态字节，而过滤器却在原始字节流上做正则匹配。比如输入%u0027（Unicode转义），Tomcat默认不处理它；但若后端用new String(bytes, "GBK")强行解码，就可能把%u0027误当成'拼进SQL。

必须统一解码后再过滤，不能依赖原始request参数

所有输入入口点（GET/POST/JSON/Header）都要先还原为语义清晰的字符串，再交给SQL安全检查逻辑。否则input.contains("union")会漏掉unu0069on这类Unicode混写。

• Java Servlet中，不要直接对request.getParameter("q")做关键字扫描；先调用URLDecoder.decode(input, "UTF-8")，再对结果做StringEscapeUtils.escapeSql()
• Spring Boot接收JSON时，需在@RequestBody反序列化后，对每个字符串字段单独调用String.valueOf(field).replace("u0027", "'")等归一化操作
• Node.js Express中，禁用body-parser的extended: false模式，确保req.body是完整解析后的对象，而非原始query string

MySQL连接层字符集声明比建表CHARSET更重要

即使表用utf8mb4，如果JDBC连接没显式指定characterEncoding=UTF-8，MySQL仍可能按latin1解析客户端发来的字节——这时u00bfu0027（即0xbf27）在GBK下会被当单引号，而在UTF-8下只是两个普通字符。连接层不一致，等于给宽字节注入开了后门。

• JDBC连接串必须含?useUnicode=true&characterEncoding=UTF-8
• PHP PDO需同时设置PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"和charset=utf8mb4
• Go database/sql的DSN里不能只写charset=utf8，得用charset=utf8mb4，否则emoji和补充平面字符会截断

日志输出是最容易被忽略的泄漏点

哪怕SQL用了#{}参数化，只要logger.info("raw input: {}", userInput)打印了未归一化的原始值，攻击者就能从日志里反推出绕过路径——比如看到%u0027or%u00201%3D1，就知道系统没做Unicode预解码。

• 所有日志写入前必须调用StringEscapeUtils.escapeEcmaScript()或至少input.replace("'", "''").replace("\", "\\")
• 禁止在调试代码里用System.out.println(request.getQueryString())，这种原始输出会把编码混淆全暴露出来
• ELK或Splunk采集日志时，配置grok filter强制对message字段做UTF-8校验，丢弃非法字节序列