Nginx统一控制静态资源字符集的核心是通过http或server块中配置charset utf-8;配合charset_types指定text/html、text/css等MIME类型，确保响应头Content-Type正确携带charset=utf-8，且文件本身须为UTF-8无BOM编码。
直接在 Nginx 配置中统一控制静态资源的字符集，核心是让 HTTP 响应头中的 Content-Type 正确携带 charset=utf-8，而不是依赖 HTML 文件内的 <meta charset>。后者仅在浏览器解析 HTML 时起作用，且可能被响应头覆盖或冲突。
全局设置 charset 指令
在 http 或 server 块中添加：
-
charset utf-8;—— 声明默认字符集为 UTF-8 - 该指令本身不会自动生效，必须配合
charset_types明确指定哪些 MIME 类型需要加 charset
精准控制 MIME 类型的编码声明
使用 charset_types 列出需强制附加 charset=utf-8 的类型：
- 常见必须项：
text/html text/css application/javascript text/plain application/json text/xml application/xml - 注意：
text/html是关键，它确保所有 .html 文件响应头含Content-Type: text/html; charset=utf-8 - 若遗漏
text/html，即使写了charset utf-8，HTML 文件也不会带 charset 参数
确认文件本身是 UTF-8 编码
Nginx 不转码文件内容，只负责声明编码方式：
- .html、.css、.js 等文本文件必须用 UTF-8（无 BOM）保存，否则声明了 UTF-8 仍会乱码
- 可用命令检查：
file -i filename.html或编辑器查看编码格式 - 避免在文件中重复写
<meta charset="gbk">，否则与响应头冲突，浏览器可能按 meta 解析导致错乱
反向代理场景下的注意事项
如果 Nginx 作为反向代理（如 proxy_pass），行为不同：
- 后端已返回
Content-Type: text/html; charset=utf-8时，Nginx 默认不覆盖或重复添加 - 此时
charset指令对代理响应无效；如需强制重写，需用sub_filter或第三方模块，但易引发兼容问题，一般不建议 - 静态文件直出（非 proxy）才真正受
charset+charset_types控制
