乱码根源是浏览器未获知utf-8编码，因txt无meta且响应头缺charset；解决需服务端加content-type: text/plain; charset=utf-8或前端fetch+blob转码。
直接结论：乱码不是 iframe 的问题，而是浏览器没拿到 charset=utf-8 —— 既不在 HTTP 响应头里，也不在 TXT 文件内容中（TXT 没法写 <meta>），所以必须从服务端或加载方式上补上。
为什么 iframe 加载本地 txt 会乱码
浏览器对 text/plain 类型资源不默认用 UTF-8 解码。当响应头只有 Content-Type: text/plain、缺 charset=utf-8 时，Chrome 可能猜 GBK，Safari 可能 fallback 到系统编码，结果就是同一份 UTF-8 编码的 txt，在不同环境显示不同乱码。
关键点：
- TXT 文件本身不含编码声明，<meta charset> 对它完全无效
- file:// 协议下，HTTP 响应头根本不存在，浏览器只能靠文件 BOM 或启发式检测，极不可靠
- 你双击打开 txt 没乱码，是因为系统记事本/编辑器读到了 BOM 或按系统默认编码强行匹配了
后端响应头必须加 charset=utf-8
如果你是通过 Web 服务器（如 Nginx / Express / Spring Boot）提供 txt 资源，这是最可靠、最推荐的修复点。
- Nginx 配置里加：
charset utf-8;（放在location或server块中） - Apache 的
.htaccess加：AddDefaultCharset UTF-8 - Express 中静态托管时显式设置：
res.set('Content-Type', 'text/plain; charset=utf-8') - Spring Boot 的
application.properties加：spring.http.encoding.charset=UTF-8（仅对 controller 生效，静态资源需额外配WebMvcConfigurer）
验证是否生效：打开浏览器 DevTools → Network → 找到那个 txt 请求 → 查看 Response Headers → 确认有 Content-Type: text/plain; charset=utf-8。没有就白搭。
前端绕过响应头：用 fetch + Blob 构造 UTF-8 URL
当无法修改服务端（比如纯静态站点、CDN 托管、或调用第三方 API 返回无 charset 的 txt），就得前端自己“补编码”。
核心思路：不用 iframe.src = url 直接加载，而是先 fetch 下来，明确告诉 JS 这是 UTF-8，再转成 Blob，生成本地 URL.createObjectURL() 给 iframe。
async function loadTxtAsUtf8(iframe, txtUrl) {
try {
const res = await fetch(txtUrl);
const text = await res.text(); // fetch 默认按 UTF-8 解码
const blob = new Blob([text], { type: 'text/plain;charset=utf-8' });
const url = URL.createObjectURL(blob);
iframe.src = url;
} catch (err) {
console.error('txt 加载失败:', err);
}
}
// 调用
loadTxtAsUtf8(document.getElementById('myIframe'), '/api/stream.txt');
注意：
- 不要用 response.arrayBuffer() + TextDecoder 再绕一圈，response.text() 已足够且更简洁
- Blob 的 type 字符串里写 charset=utf-8 是为了保险，实际浏览器主要认内容解码逻辑
- 记得在页面销毁前调用 URL.revokeObjectURL(url) 避免内存泄漏（尤其频繁切换时）
别踩这些坑
以下操作看似合理，但实际无效或副作用明显：
- 给 iframe 加
charset="UTF-8"属性 ——<iframe charset="UTF-8"></iframe>是废标签，HTML5 已废弃，所有现代浏览器都忽略 - 在 txt 文件开头手动加
<meta charset="UTF-8">—— TXT 不是 HTML，浏览器不会解析这行，反而把它当普通文本显示出来 - 用
document.write把 txt 内容写进 iframe 的 document —— 跨域限制、执行时机难控、且依然不解决原始编码判定问题 - 依赖文件 BOM —— 很多编辑器保存 UTF-8 时默认不带 BOM；Windows 记事本带 BOM，但 VS Code 默认不带；BOM 不是银弹
真正起作用的只有两个支点：服务端的 Content-Type 响应头，或者前端用 fetch.text() 显式接管解码过程。其他都是障眼法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
