浏览器在html解析阶段就将

浏览器如何解析 这类实体

HTML 实体不是“渲染后才生效”的东西，而是在 HTML 解析阶段就被转换为对应字符。当你写 ，浏览器的 HTML 解析器在构建 DOM 前就把它替换成 ASCII 字符 <code>（U+003C），后续所有处理（CSS、JS、文本布局）面对的都是这个真实字符，不是字符串 <code>。

这意味着：

• 如果用 textContent 读取元素内容，得到的是 ，不是 <code>
• 用 innerHTML 读取，则可能返回原始写法（取决于浏览器和是否被重写过），但首次解析时已转义完成
• DOM 操作中传入 字符串，会被再次解析——比如 <code>el.innerHTML = "<div>"，结果是插入一个真实 <code><div> 标签，而不是显示文字 <h3> <code>  为什么能撑开空白，而普通空格不行

  HTML 默认会把连续多个空格、换行、制表符压缩成单个空格，并忽略首尾空白。这是规范行为，不是 bug。

    是 Unicode 中的 U+00A0 NO-BREAK SPACE，它被浏览器视为“不可折叠”“不可换行”的字符：

  

  Doc To HTML

  使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

  下载
  • 不会被空格合并规则吞掉，所以 Hello   World 显示三个空格宽度
  • 相邻单词用   连接时（如 Mr. Smith），不会在中间断行
  • 注意：  不等于 CSS 的 white-space: pre，后者影响整块文本；  是逐字符控制

  实体名称 vs 实体编号：什么时候必须用 而不是 <code>

  绝大多数常用实体（、<code>>、&、"、'）用名称完全安全，但以下场景建议优先用编号：

  • 输出由模板引擎或 CMS 自动生成的内容时，某些老系统会错误地把 当作未闭合实体（尤其当后面紧跟字母，如 <code><script>）</script>
  • 需要确保兼容 IE8 或更旧环境（' 在 IE 不被支持，必须用 '）
  • 处理非 ASCII 字符且不确定命名实体是否存在时，比如 😀（?）比 😀 更直观，也比查不到的命名实体可靠
  • 避免大小写陷阱：< 或 （小写 L）是无效的，而 <code> 不受大小写影响

  UTF-8 直接输入和实体混用时的常见坑

  现代页面声明 <meta charset="utf-8"> 后，可直接输入 © € α 等字符——但这不意味着可以随意混用：

  • 文件保存编码必须是 UTF-8 无 BOM，否则 © 可能变成乱码或触发解析错误
  • 服务器响应头 Content-Type: text/html; charset=utf-8 必须与 meta 标签一致，否则浏览器可能按 ISO-8859-1 解析
  • 不要在一个页面里一半用 © 一半用 ©：虽然效果一样，但给后续维护、正则匹配、SEO 提取带来不确定性
  • JS 字符串中写 "©" 没问题，但若从服务端注入 HTML 片段（如 document.write("©")），仍需确保该片段本身被正确转义，否则可能 XSS

  最稳妥的做法是：静态内容优先用命名实体（易读+可控），动态内容交由后端做 HTML 转义（如 PHP 的 htmlspecialchars()、Node 的 he.escape()），而非依赖前端拼接。