网站开发中，字符编码乱码和注入攻击是两个最常见也最容易被忽视的安全与体验问题。框架过滤器（Filter）是解决这两个问题的核心手段——通过在请求进入业务逻辑之前统一拦截、转换编码、过滤危险字符，既能保证页面正常显示中文等多字节字符，又能有效阻断SQL注入、XSS跨站脚本等攻击。具体做法是：在框架层面配置编码过滤器（如Java的CharacterEncodingFilter、Spring的HttpPutFormContentFilter），统一设置UTF-8编码；同时配合XSS过滤器、SQL注入过滤器，对用户输入进行转义和白名单校验。下面我会从原理到实操，把这套方案讲透。

一、为什么字符编码会乱码：问题根源在哪里

乱码的本质是"编码和解码不一致"。用户浏览器发送请求时用的是一种编码（比如GBK），服务器接收时用另一种编码（比如ISO-8859-1）去解析，结果中文字符就变成了一堆看不懂的符号。在早期的Java Web开发中，Tomcat默认用ISO-8859-1解析请求体，而中国用户的表单提交几乎都是GBK或UTF-8，这就直接导致了乱码。现在虽然大部分项目都迁移到了UTF-8，但在老项目维护、第三方接口对接、文件上传等场景中，编码混乱依然频发。

更麻烦的是，乱码不仅仅是显示问题。如果编码处理不当，攻击者可以利用编码差异绕过过滤器的检测。比如某些过滤器只检查UTF-8编码下的危险字符，而攻击者用GBK编码构造payload，就可能绕过检测直接执行注入。所以编码统一不是小事，它是整个安全链的基础。

二、框架过滤器处理编码的核心方案

主流Web框架都提供了编码过滤器，核心思路就是在请求到达Controller之前，强制统一编码。以Java Spring Boot为例，最常用的是CharacterEncodingFilter，配置非常简单：

@Bean
public FilterRegistrationBean<CharacterEncodingFilter> encodingFilter() {
    FilterRegistrationBean<CharacterEncodingFilter> registration = new FilterRegistrationBean<>();
    CharacterEncodingFilter filter = new CharacterEncodingFilter();
    filter.setEncoding("UTF-8");
    filter.setForceEncoding(true);
    registration.setFilter(filter);
    registration.addUrlPatterns("/*");
    registration.setOrder(1);
    return registration;
}

这里有几个关键点：setForceEncoding(true)表示强制使用UTF-8，不管请求头里声明的是什么编码；addUrlPatterns("/*")表示拦截所有请求；setOrder(1)保证它在其他过滤器之前执行。在传统的web.xml配置中，写法类似：

<filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

除了请求编码，响应编码同样重要。需要在框架中设置响应头Content-Type为text/html;charset=UTF-8，Spring Boot默认已经做了，但如果你用了自定义的ResponseBodyAdvice或者直接写HttpServletResponse，就需要手动设置。

三、注入攻击的类型和过滤器防御策略

注入攻击主要分三大类：SQL注入、XSS跨站脚本注入、命令注入。它们的共同点是攻击者把恶意代码混在用户输入里提交给服务器，服务器没有正确过滤就直接执行了。框架过滤器的作用就是在数据进入业务逻辑之前，把这些危险内容清洗掉。

SQL注入的防御核心是参数化查询，但过滤器可以做第一道防线——检测请求参数中是否包含SQL关键字和特殊符号。一个简单的SQL注入过滤器示例：

public class SqlInjectionFilter implements Filter {
    private static final List<String> SQL_KEYWORDS = Arrays.asList(
        "SELECT", "INSERT", "UPDATE", "DELETE", "DROP", "UNION",
        "ALTER", "CREATE", "EXEC", "EXECUTE", "--", ";", "'", "\"",
        "OR", "AND", "=", "<", ">"
    );

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        Map<String, String[]> params = httpRequest.getParameterMap();
        for (Map.Entry<String, String[]> entry : params.entrySet()) {
            for (String value : entry.getValue()) {
                String upperValue = value.toUpperCase();
                for (String keyword : SQL_KEYWORDS) {
                    if (upperValue.contains(keyword)) {
                        HttpServletResponse httpResponse = (HttpServletResponse) response;
                        httpResponse.sendError(HttpServletResponse.SC_BAD_REQUEST, "Invalid input detected");
                        return;
                    }
                }
            }
        }
        chain.doFilter(request, response);
    }
}

需要注意的是，这种基于黑名单的过滤有局限性，因为攻击者可以用编码变形、大小写混合、注释符拆分等方式绕过。所以过滤器只能作为辅助手段，真正的防线必须是参数化查询（PreparedStatement）和ORM框架的自动转义。

四、XSS过滤器的实现与最佳实践

XSS攻击比SQL注入更隐蔽，因为它不需要直接操作数据库，只要把恶意脚本注入到页面中，其他用户访问时就会执行。防御XSS的过滤器核心是对用户输入进行HTML实体转义。下面是一个通用的XSS过滤器实现：

public class XssFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;
        
        XssHttpServletRequestWrapper wrappedRequest = new XssHttpServletRequestWrapper(httpRequest);
        chain.doFilter(wrappedRequest, response);
    }
}

public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper {
    public XssHttpServletRequestWrapper(HttpServletRequest request) {
        super(request);
    }

    @Override
    public String getParameter(String name) {
        String value = super.getParameter(name);
        return cleanXss(value);
    }

    @Override
    public String[] getParameterValues(String name) {
        String[] values = super.getParameterValues(name);
        if (values == null) return null;
        String[] cleanValues = new String[values.length];
        for (int i = 0; i < values.length; i++) {
            cleanValues[i] = cleanXss(values[i]);
        }
        return cleanValues;
    }

    private String cleanXss(String value) {
        if (value == null) return null;
        value = value.replaceAll("<", "&lt;")
                     .replaceAll(">", "&gt;")
                     .replaceAll("\\(", "&#40;")
                     .replaceAll("\\)", "&#41;")
                     .replaceAll("'", "&#39;")
                     .replaceAll("\"", "&quot;")
                     .replaceAll("&", "&amp;");
        return value;
    }
}

这个实现把所有的尖括号、括号、引号都转成了HTML实体，这样即使攻击者输入了<script>alert(1)</script>，页面上也只会显示文本而不会执行。但要注意，这种全局转义会影响富文本编辑器等需要保留HTML标签的场景，所以实际项目中通常需要配合白名单机制，对特定字段放行。

五、过滤器链的顺序设计：为什么顺序很重要

很多开发者把过滤器写好就完事了，却忽略了执行顺序。正确的过滤器链顺序应该是：编码过滤器 → XSS/注入过滤器 → 认证授权过滤器 → 业务逻辑。原因很简单：编码必须最先统一，否则后面的过滤器检测到的字符可能是乱码状态下的，检测结果不可靠；注入过滤要在认证之前，因为未认证的请求更可能是攻击请求；业务逻辑放最后，确保进入的数据已经是干净的。

在Spring Boot中，可以通过@Order注解或者FilterRegistrationBean的setOrder方法精确控制顺序。一般建议编码过滤器Order设为1，安全过滤器设为2-5，业务相关过滤器设为更高的值。

六、不同框架的具体配置对比

除了Spring Boot，其他主流框架也有各自的编码和安全过滤器方案。在Django中，中间件（Middleware）承担了过滤器的角色，Django默认使用UTF-8编码，但需要在settings.py中确保DEFAULT_CHARSET为'utf-8'，同时配置SecurityMiddleware来防范XSS。在ASP.NET Core中，可以通过中间件管道添加编码处理和请求验证中间件，利用RequestDelegate实现类似Filter的功能。在Node.js的Express框架中，可以使用body-parser配合helmet中间件来处理编码和安全头。

不管哪个框架，核心逻辑都是一样的：统一编码在前，过滤危险字符在中，参数化查询和输出转义在后。框架只是提供了不同的实现方式，原理不变。

七、容易踩的坑和进阶建议

第一，不要只依赖过滤器。过滤器是第一道防线，但不是唯一防线。SQL注入的根本解决方案是参数化查询，XSS的根本解决方案是输出编码（Output Encoding），命令注入的根本解决方案是白名单校验。过滤器只是降低风险，不能替代代码层面的安全措施。

第二，注意文件上传场景的编码问题。上传的文件名、文件内容都可能包含特殊编码，需要单独处理。建议对文件名进行ASCII化处理，对文件内容根据类型指定编码读取。

第三，定期更新过滤器规则。攻击者的绕过技术在不断进化，黑名单规则需要持续维护。更推荐的做法是使用成熟的安全库，比如Java的OWASP Java Encoder、Apache Commons Text的StringEscapeUtils，这些库经过了大量安全测试，比自己写的过滤器可靠得多。

第四，做好日志记录。过滤器拦截到的异常请求一定要记录下来，包括请求IP、参数内容、时间戳等信息，方便后续分析攻击模式和优化规则。

总结一下，网站开发框架过滤器处理字符编码和防止注入，本质上就是"统一编码+过滤清洗+纵深防御"三板斧。编码统一解决乱码问题，也为后续安全检测提供可靠基础；过滤器清洗解决大部分常见攻击；参数化查询和输出转义作为最后一道防线确保万无一失。把这套组合拳打好，你的网站在编码和安全层面就能挡住绝大多数问题。