UTF-8是唯一推荐且必须统一的编码方案，因其确保ruby标签中基字、拼音及rt内容被浏览器正确解析；GBK等其他编码会导致注音失效、错位或乱码，且现代浏览器对非UTF-8的ruby解析极不稳定。
ruby 标签本身不依赖字符集，但它的渲染结果是否正常，完全取决于基字、拼音、rt 内容的编码是否被浏览器正确识别和解析。UTF-8 是唯一推荐且必须统一的编码方案，其他编码（如 GBK、ISO-8859-1）会导致 ruby 注音直接失效或错位。
为什么 UTF-8 是硬性前提，而非可选项
浏览器在解析 ruby 时，会先按声明的编码读取整个 HTML 文件字节流，再按 DOM 规则匹配 ruby 和 rt 的嵌套结构。若文件实际是 GBK 编码却声明 meta charset="UTF-8"，那么“汉”字对应的两个 GBK 字节会被错误解释为两个非法 UTF-8 序列，导致：
-
ruby节点可能被截断或跳过（尤其当乱码出现在<rt></rt>开始前） - 拼音内容如
hàn若含重音符号（à），在 GBK 环境下根本不存在对应字节，直接变成 或空字符串 - Chrome DevTools 的 Elements 面板中能看到
ruby标签，但rt子节点为空或显示为乱码文本
GBK 页面里强行用 ruby 会发生什么
即使你绕过编码声明问题（比如用 Content-Type: text/html; charset=GBK 响应头 + 不写 meta），ruby 仍大概率不工作：
- 现代 Chrome/Safari 对非 UTF-8 的
ruby解析极不稳定——同一段<ruby>重<rt>chóng</rt></ruby>在 GBK 下可能只渲染“重”，拼音消失 - 拼音里的连字符、空格、声调符号（如
zhòng中的 `ò`）在 GBK 中无映射，浏览器会静默丢弃或替换为 - 服务端模板若从 UTF-8 数据库读取拼音字段再插入 GBK HTML，极易触发
Encoding::UndefinedConversionError（Ruby 环境）或 JSInvalid or unexpected token（前端内联脚本中混入未转义的 UTF-8 字节）
多语言混排时，编码 + lang + bdi 必须三者协同
例如阿拉伯文页面中嵌入中文注音：<p lang="ar">أحمد <bdi><ruby>李<rt>lǐ</rt></ruby></bdi></p> —— 这里出问题的根源往往不是 ruby 本身，而是编码与语义标签脱节：
立即学习“前端免费学习笔记（深入）”；
- 若 HTML 文件是 UTF-8，但服务器响应头漏了
charset=UTF-8，iOS Safari 可能 fallback 到 ISO-8859-1，把lǐ解成乱码，rt内容变空 - 若没写
lang="zh-Hans"，屏幕阅读器可能用阿拉伯语音引擎读lǐ，发音完全错误 - 若没包
bdi，RTL 上下文会把rt的括号或位置拖到文字右侧，甚至覆盖基字
真正卡住人的地方不在 ruby 语法本身，而在整个字符流从文件存储、HTTP 传输、DOM 解析到辅助技术消费的每个环节——只要其中一环编码失配，rt 就不会出现。别试图兼容 GBK 页面里的 ruby，重构为 UTF-8 是唯一可行路径。
