必须写charset声明，否则非ASCII字符会显示为问号或方块；推荐且须置于最前；文件编码、HTTP头、数据库连接等环节均需统一为UTF-8。
HTML里不写会乱码吗
会，而且大概率在中文、日文、俄文等非ASCII字符上直接显示成问号或小方块。浏览器没有明确指令时，会按历史遗留规则猜编码——比如IE可能用GBK，Chrome在某些本地文件场景下可能用ISO-8859-1，结果就是同一份HTML在不同环境表现不一致。
-
charset必须写在最前面，越靠后风险越高；浏览器解析到它之前已读入的字节可能已被错误解码，无法回退 - 只认这三种写法之一：
<meta charset="UTF-8">（推荐）、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（老式，冗余）、HTTP响应头里的Content-Type: text/html; charset=UTF-8（优先级最高，但前端不可控） - 不要写
charset=utf8—— 正确是UTF-8（带短横线），否则部分旧浏览器或校验工具会忽略
VS Code保存文件编码和不一致怎么办
两者必须一致，否则编辑器存的是UTF-8 BOM，HTML却声明UTF-8无BOM，或者反过来，都会导致解析错位。常见症状是页面开头出现空白、符号，或CSS/JS加载失败。
- 在VS Code右下角点击编码名称（如“UTF-8”或“GBK”），选
Save with Encoding→UTF-8（不带BOM） - 检查文件是否含BOM：用命令行
xxd yourfile.html | head，如果开头是ef bb bf就有BOM；现代HTML应避免BOM - 确认Web服务器没强制注入其他编码头，比如Nginx里误配了
charset GBK;
PHP/Node.js动态生成HTML时怎么保证编码不出错
服务端输出内容前，HTTP头和HTML内声明必须同步，且不能被中间层覆盖。最容易被忽略的是PHP的default_charset配置或Node.js里忘了设Content-Type头。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- PHP中，在输出HTML前加：
header('Content-Type: text/html; charset=UTF-8');，并确保ini_set('default_charset', 'UTF-8')已启用 - Node.js（Express）中用
res.set('Content-Type', 'text/html; charset=UTF-8')，而不是只靠模板引擎默认行为 - 数据库查询结果也要注意：MySQL连接需执行
SET NAMES utf8mb4，否则即使页面声明UTF-8，从库读出的汉字仍是乱码
为什么加了还是乱码
说明问题不在HTML声明本身，而是源头数据或传输链路被污染。这类问题往往查半天才发现是文件保存错了、代理改了头、或者CDN缓存了旧版本。
立即学习“前端免费学习笔记（深入）”；
- 打开浏览器开发者工具 → Network → 点开HTML请求 → 查看Response Headers里的
Content-Type，如果值是text/html; charset=GBK，那就完全被无视了 - 禁用CDN或本地代理重试，排除中间设备篡改响应头的可能
- 用
curl -I yourpage.html直接看原始响应头，比浏览器更可信
