跨系统插入 HTML 图片到 Word 出现乱码，根本原因不是图片本身，而是 HTML 中的中文路径、<img src> 的 URL 编码或 Base64 数据未被 Word 正确解析——尤其在 macOS/Linux 生成的 HTML 传到 Windows Word 或反之。直接拖拽、复制粘贴 HTML 片段时，Word 往往忽略原始编码声明，强行按本地默认编码（如 GBK 或 UTF-16LE）读取，导致路径里的中文变成 ???? 或插入失败。
确认 HTML 源文件实际编码与 meta 声明是否一致
很多乱码源于「嘴上说 UTF-8，身体很诚实」：HTML 文件物理保存为 GBK，但 <meta charset="UTF-8"> 写在头部。Word 会优先信 meta，再按 UTF-8 解析路径，结果字节错位。
- 用 VS Code 或 Notepad++ 打开 HTML，右下角看真实编码（如显示
GBK），再检查<meta>标签是否匹配 - 不一致时，统一改为 UTF-8：在编辑器中「另存为」→ 编码选
UTF-8 without BOM，同时把<meta charset="UTF-8">保留在<head>中 - 特别注意：Windows 记事本默认保存为
ANSI（即当前系统 locale 编码），务必不用它改 HTML
图片路径含中文时，必须 URL 编码而非直接写入
Word 的 HTML 导入器对未编码的中文路径支持极差，即使文件编码正确，<img src="图1.png"> 在跨系统时大概率报错或显示红叉。
- 路径中的中文、空格、括号等特殊字符，必须用
encodeURIComponent()处理（JavaScript）或urllib.parse.quote()（Python） - 例如：
"截图 2024-测试.png"→ 编码后为"%E6%88%AA%E5%9B%BE%202024-%E6%B5%8B%E8%AF%95.png" - 不要手动替换为
%uXXXX（这是旧 IE 的 Unicode 编码方式，Word 不认） - 如果用本地文件协议（
file:///），整个路径都要编码，包括盘符和目录分隔符（/不编码，\要先转成/再编码）
用 Base64 嵌入图片时，data URL 必须用 UTF-8 字节流生成
很多人用在线工具转图片为 Base64，但工具若按系统默认编码读取文件名或元数据，会导致 data URL 中的 MIME 类型或参数含非法字符，Word 解析失败。
立即学习“前端免费学习笔记（深入）”；
- 确保 Base64 字符串来自二进制读取（非文本读取），例如 Python 中用
open("a.png", "rb")，而非"r" - data URL 格式严格为：
<img src="data:image/png;base64,iVBORw0KGgo...">，开头不能有空格、换行或 BOM - 避免在 Base64 字符串前后加引号或换行；Word 对
src值的空白字符异常敏感 - macOS 上用
base64 -i a.png生成的字符串自带换行，需用tr -d '\n'清除
真正麻烦的不是编码本身，而是 Word 对 HTML 的解析逻辑不透明：它会静默丢弃无法识别的 src 值，也不报错，只留个空白框。所以每次改完，务必在目标系统上用 Word「打开」HTML 文件（不是复制粘贴），再检查图片是否可点开、路径是否显示正常——这才是唯一可信的验证方式。
