<meta charset="UTF-8">必须位于<head>最开头且文件实际编码为UTF-8，二者缺一不可；否则浏览器扫描前1024字节未命中该标签，将fallback至系统默认编码（如GBK或ISO-8859-1），导致中文、emoji乱码或JS语法错误。
meta charset 必须放在 <head> 最开头，且文件本身必须是 UTF-8 编码 —— 二者缺一不可，否则中文、emoji 或用户输入内容大概率直接乱码或报错。
为什么 meta charset="UTF-8" 放在 <title> 后面就失效
浏览器解析 HTML 时，只扫描前 1024 字节来确定编码。一旦遇到非 ASCII 字符（比如中文标题、emoji、注释里的汉字），而此时还没读到 <meta charset="UTF-8">，就会 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），后续再声明也无效。
-
<head><title>你好</title><meta charset="UTF-8"></head>：乱码，<title>已触发 fallback -
<head><meta charset="UTF-8"><title>你好</title></head>：正常 -
<head><!-- 注释里有中文 --><meta charset="UTF-8"></head>：仍乱码，注释内容也被扫描
文件实际编码和 meta charset 值不一致的典型后果
即使写了 <meta charset="UTF-8">，如果文件保存时用的是 GBK，浏览器会用 UTF-8 解码 GBK 字节流，结果就是一堆 符号，或者 JS 报 Invalid or unexpected token。
- VS Code 打开一个旧 GBK 文件，未手动选 “Save with Encoding → UTF-8”，直接写
meta标签没用 - Notepad++ 保存时要选 “转为 UTF-8-BOM” 而非 “UTF-8” —— 某些旧版 IE 对无 BOM 的 UTF-8 识别不稳定
-
utf8、utf_8、unicode都不是 IANA 注册值，部分 WebView 或构建工具（如 html-webpack-plugin）会忽略
HTTP 响应头比 meta 更优先，但本地打开时它不存在
当页面通过 HTTP 加载时，Content-Type: text/html; charset=UTF-8 响应头权重高于 meta；但用 file:// 直接双击打开 HTML，响应头为空，此时完全依赖 meta 和文件实际编码。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- Apache 配置：
AddDefaultCharset UTF-8或Header set Content-Type "text/html; charset=UTF-8" - Nginx 配置：
charset utf-8;放在server或location块内 - 验证方式：DevTools → Network → 点开 HTML 请求 → 查看 Response Headers 中的
Content-Type
怎么快速验证三者是否真正一致
不是只看标签写了没，而是确认三件事同时成立：文件磁盘编码 = meta charset 值 = HTTP 响应头 charset。
- 查文件编码：VS Code 右下角编码显示，点开可切换；或终端执行
file -i index.html（macOS/Linux）、Get-Content index.html -Encoding Byte | Select -First 3（PowerShell）看是否为239, 187, 191（BOM） - 查运行时编码：浏览器控制台执行
document.characterSet，返回必须是"UTF-8" - 查响应头：Network 面板中 HTML 请求的
Content-Type字段，不能是charset=GBK或缺失
最容易被跳过的其实是文件保存动作 —— 写完 <meta charset="UTF-8"> 后，必须显式保存为 UTF-8（带或不带 BOM，视兼容需求），否则所有声明都是纸上谈兵。
