记事本保存HTML中文乱码，根本原因是文件实际编码（ANSI/GBK）与声明不一致；必须在“另存为”中手动选“UTF-8”（无BOM）、保存类型选“所有文件”，并确保位于最前且无BOM。
保存 HTML 源码时，乱码问题几乎全是编码没对齐导致的——文件实际存储编码、<meta charset="UTF-8"> 声明、HTTP 响应头三者必须严格一致，且都不能带 BOM。
为什么记事本保存后中文全变方块？
Windows 记事本默认用 ANSI（实为系统 locale 编码，通常是 GBK）保存，哪怕你写了 <meta charset="UTF-8">，浏览器读到的是 GBK 字节流，直接按 UTF-8 解码，必然错位成乱码。
- 在记事本「另存为」对话框里，务必手动点开「编码」下拉菜单，选
UTF-8（不是UTF-8-BOM，也不是ANSI） - 「保存类型」必须选
所有文件 (.)，否则会强制加.txt后缀，变成index.html.txt - 右键文件 → 「属性」→ 确认「名称」栏显示的是
index.html，不是index.html.txt；若看到 .txt，先在文件夹「查看」中勾选「文件扩展名」再重命名删掉
VS Code 保存后还是乱码？
VS Code 右下角状态栏显示 UTF-8 ≠ 文件真实编码。它可能正以 GBK 打开一个旧文件，你改完再保存，还是存成 GBK。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 打开疑似乱码的文件，按
Ctrl+Shift+P→ 输入Change File Encoding→ 选Save with Encoding→ 明确选UTF-8（注意不是UTF-8 with BOM） - Linux/macOS 下用命令验证：
file -i index.html应返回charset=utf-8；若为charset=us-ascii或charset=iso-8859-1，说明根本没存成 UTF-8 - PowerShell 验证是否有 BOM：
Get-Content index.html -Encoding Byte | Select -First 3，输出239 187 191表示有 BOM，需重存为无 BOM 版本
为什么 <meta charset="UTF-8"> 有时不生效？
这个标签只在没有 HTTP 响应头 Content-Type: text/html; charset=utf-8 时才起作用。用 file:// 协议双击打开本地 HTML 文件，就没有响应头，此时 <meta> 是唯一依据——但它必须放在 最前面，且不能写错大小写或空格。
立即学习“前端免费学习笔记（深入）”；
-
<meta charset="utf-8">和<meta charset="UTF-8">都合法，但<meta http-equiv="Content-Type" content="text/html; charset=utf-8">在 file:// 下更可靠 - 该标签必须是
内第一个子元素，前面不能有注释、空行或任何字符（包括 BOM） - 如果服务器部署了页面，优先让 Nginx/Apache/Express 返回正确的
Content-Type头，比依赖<meta>更底层、更稳定
真正容易被忽略的是：BOM 不仅影响解析，还会让某些构建工具（如 Webpack、Vite）报错，或让 fetch() 读取本地 JSON 时失败。保存 HTML 时，宁可手动删掉 BOM，也不要依赖编辑器“自动处理”。
