HTML 不支持局部编码设置，因为 <meta charset> 是文档级声明，浏览器仅在解析前1024字节内读取一次并全局生效，无法为 <div>、<iframe> 等嵌套结构单独指定编码。
HTML 嵌套页面本身无法“单独设置局部编码”——charset 是文档级元信息，浏览器只在解析整个 HTML 文档开头时读取一次 <meta charset="UTF-8">，不支持对某个 <div>、<iframe> 或加载的片段单独指定编码。
为什么不能给嵌套结构设局部编码
浏览器解析 HTML 时，编码声明必须出现在前 1024 字节内，且全局生效。即使你写：<div data-charset="GBK">...，这个属性对解码毫无作用——它只是自定义属性，不会触发重新解码逻辑。所有子内容（包括 JS 动态插入的 HTML 片段、<iframe> 加载的内容）都继承父文档的编码设定。
常见误判场景：
- 用
fetch()加载一个含中文的/partials/header.html，但服务端返回时没设Content-Type: text/html; charset=GBK，而主页面是UTF-8→ 中文变乱码，这不是“局部编码没设好”，是服务端响应头缺失或不一致 - 在
<iframe src="legacy-page.htm">里看到乱码，试图在 iframe 外部加<meta charset="GB2312">→ 无效，iframe 内容按它自身文档的<meta charset>或响应头解析
iframe 是唯一能“隔离编码”的嵌套方式
<iframe> 加载的是独立文档上下文，它的编码由自身 HTML 的 <meta charset> 或 HTTP 响应头决定，与父页无关。这是 HTML 原生支持的唯一编码隔离机制。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
实操要点：
- 确保被嵌入页面（如
legacy-form.html）顶部有正确的<meta charset="GBK">，且服务器返回的Content-Type头未覆盖它（例如不要返回charset=UTF-8） - 避免用
srcdoc属性写内联 HTML 并指望它用不同编码——srcdoc内容直接继承父文档编码，无法切换 - 若需动态控制，只能换 iframe 的
src地址，指向不同编码的静态文件，不能 runtime 修改其内部编码
JS 动态加载片段时的编码处理
用 fetch() 或 XMLHttpRequest 加载 HTML 片段，编码问题本质是 HTTP 响应头和字符集声明是否匹配。
关键动作：
- 服务端必须为
/partials/xxx.html返回明确的Content-Type: text/html; charset=XXX（如GBK），不能依赖客户端猜测 - 前端 fetch 不需要手动指定编码，但可检查响应头：
response.headers.get('content-type')确认是否含charset - 若后端无法改响应头，唯一补救是让服务端返回 UTF-8 编码内容（统一源头），避免混用
注意：response.text() 解码结果完全由响应头或 BOM 决定，JS 无法在拿到字符串后再“重解码”。所谓“转码”需后端完成或用 TextDecoder 手动处理 ArrayBuffer（极少见且易出错）。
容易被忽略的兼容性坑
某些老旧系统生成的 HTML 片段自带 BOM（如 UTF-8 BOM EF BB BF），而部分 Node.js 模板引擎或构建工具会 strip BOM，导致实际传输无 BOM 但声明了 UTF-8，浏览器可能 fallback 到 ISO-8859-1 解析——这种问题不会报错，只会静默乱码。排查时务必用 curl -I 看响应头，再用 xxd 或 VS Code 十六进制视图确认文件开头字节。
