必须转义的字符只有&、<、>、"、'这5个，因其在HTML中具特殊语法含义，不转义会导致解析错误或XSS漏洞；其他字符如©属显示需求，非安全必需。
哪些字符必须转义才能生成安全的 HTML 实体
HTML 中只有 &、<、>、"、' 这 5 个字符是**必须转义**的（W3C 规范要求，且浏览器解析最严格）。其他如 、© 属于语义或显示需求，不属于安全转义范畴。忽略这点容易过度编码，导致输出冗长或破坏可读性。
常见错误是照搬 XML 或 URL 编码逻辑，对所有非 ASCII 字符做 HHHH; 形式编码——这不必要，也不符合常规 HTML 实体转义目的（防 XSS 和解析错误）。
用 std::string 手动遍历替换最可靠
C++ 标准库没有内置 HTML 实体编码函数，std::regex_replace 看似方便，但正则引擎在处理 & 时极易引发二次编码（比如把已有的 又变成 <code>），所以推荐手动遍历 + 前向扫描。
- 先处理
&→&（必须第一步，否则干扰后续） - 再处理
<→ - 再处理
>→> - 再处理
"→" - 最后处理
'→'（注意：IE8- 不支持'，若需兼容旧 IE，可跳过或改用'）
示例片段：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
std::string html_escape(const std::string& s) {
std::string out;
out.reserve(s.size() * 1.5); // 预分配避免多次 realloc
for (char c : s) {
switch (c) {
case '&': out += "&"; break;
case '<': out += "<"; break;
case '>': out += ">"; break;
case '"': out += """; break;
case '\'': out += "'"; break;
default: out += c; break;
}
}
return out;
}要不要处理 Unicode 字符？看场景
纯 ASCII 范围内的转义已满足绝大多数 XSS 防护需求。如果你明确要支持多语言内容展示（比如用户输入含中文、日文），又不想依赖 UTF-8 页面声明，可补充对非 ASCII 字符做十进制数字实体编码（〹），但注意：... 十六进制形式需确保浏览器环境支持（现代浏览器都 OK，但某些嵌入式 HTML 渲染器可能只认十进制）。
不建议无条件对所有非 ASCII 字符编码——它会让 HTML 可读性归零，且增加体积。更合理的方式是：只在 Content-Type 缺失或声明为 ISO-8859-1 的老系统中启用该逻辑。
第三方库（如 libxml2）能省事但有代价
libxml2 的 xmlEncodeEntitiesReentrant 可直接复用，但它默认编码所有非 ASCII 字符为 ...，且会把 & 当作普通字符漏处理（需手动前置替换）。另外，libxml2 是 C 接口，需手动管理 xmlChar* 生命周期，引入额外依赖和编译复杂度。
轻量级替代方案：用 ctemplate（Google 开源）的 EscapeForHtml，或自己封装一个头文件-only 的小工具类——只要逻辑清晰、边界明确，比强塞重型库更可控。
真正容易被忽略的是：转义后字符串是否还会被后续流程（如模板引擎、JSON 序列化）再次处理。例如，把已转义的 再喂给 <code>jsoncpp 的 JSONValue::toStyledString()，可能因引号处理不当导致双转义。务必确认整个数据流中 HTML 转义只发生一次，且处于最终输出前的最后一个环节。
