ASP中文乱码主因是响应头、文件编码、HTML声明三者不一致；需统一UTF-8（CodePage=65001、Charset="utf-8"、文件存为UTF-8无BOM、meta charset="utf-8"置head最前），避免混用GBK与UTF-8。
ASP 生成 HTML5 页面出现中文乱码，90% 是响应头、文件保存编码、HTML 声明三者不一致导致的，不是“字体”问题，而是字符编码链断裂。
确认 Response.Charset 和 Response.CodePage 是否匹配
ASP 默认用 CodePage=936（GBK），但 HTML5 推荐 UTF-8。若页面含中文又设了 Response.Charset = "utf-8"，但没同步改 CodePage，IIS 会按 GBK 编码字符串再以 UTF-8 发出，必然乱码。
- 统一用 UTF-8：在 ASP 文件顶部加
Response.CodePage = 65001+Response.Charset = "utf-8" - 若必须用 GBK（如旧系统集成），则 HTML 中
<meta charset="gb2312">或<meta http-equiv="Content-Type" content="text/html; charset=gb2312">，且文件本身保存为 ANSI（即 GBK） - 避免混用：
CodePage=936配charset=utf-8是典型错误组合
检查 .asp 文件本身的磁盘编码格式
即使 ASP 脚本设置了 UTF-8，如果文件用记事本另存为“UTF-8 带 BOM”，IIS 7+ 可能将 BOM 当作输出内容前置，导致 <!DOCTYPE> 前多出乱码字符，浏览器解析失败。
- 用 VS Code 或 Notepad++ 打开 .asp 文件 → “编码”菜单 → 选“UTF-8 无 BOM”并保存
- 不要依赖 Windows 记事本的“UTF-8”选项（它默认带 BOM）
- 若用 GBK，保存为“ANSI”，而非“UTF-8”或“Unicode”
验证 HTML5 的 <meta charset> 是否生效且位置正确
HTML5 要求 <meta charset> 必须在 <head> 最前面（前 1024 字节内），否则浏览器可能已按默认编码（如 ISO-8859-1）解析了部分 HTML，造成错位乱码。
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
立即学习“前端免费学习笔记（深入）”；
- 确保该标签是
<head>中第一个元素，前面不能有空格、注释或Response.Write输出 - 写成
<meta charset="utf-8">，不要用http-equiv形式（HTML5 不推荐） - 用浏览器开发者工具 → “网络”选项卡 → 点开 HTML 请求 → 查看“响应标头”中的
Content-Type，确认含charset=utf-8
避开 Response.Write 拼接时的隐式编码陷阱
当用 Response.Write 输出变量时，若变量来自数据库或表单提交，其编码可能与当前 ASP 页面不一致。例如从 UTF-8 数据库读出的字符串，在 CodePage=936 环境下直接输出，会二次转码。
- 数据库连接字符串中显式指定编码，如 SQL Server 加
;Charset=utf-8（需驱动支持），或 MySQL 加;characterSet=utf8 - 对不确定来源的字符串，用
Server.HTMLEncode()前先做编码转换（需自定义函数或 ADODB.Stream 中转） - 更稳妥做法：全程统一 UTF-8（
CodePage=65001+ DB 连接 UTF-8 + 文件无 BOM + meta utf-8），减少转换环节
真正难调的不是某一行代码，而是这四层——文件磁盘编码、ASP 运行时编码、HTTP 响应头、HTML 文档声明——只要有一环脱节，乱码就藏得极深。尤其注意 IIS 版本差异：IIS 6 默认忽略 Response.Charset，而 IIS 10 对 BOM 更敏感。
