古汉语文摘必须逐字用ruby标注，每个字独立套ruby结构，虚词通假破读需人工校对；rt内注音须用UTF-8原生字符，禁用HTML实体；竖排时优先用writing-mode控制；邮件兼容必须成对使用rp括号。
古汉语文摘里用 ruby 必须逐字拆，不能按词或句包
古汉语单字多义、多音、训读复杂，ruby 不会自动识别语境——你写什么音，就标什么音。常见错误是把整句《论语》摘录塞进一个 ruby，比如 <ruby>学而时习之<rt>xué ér shí xí zhī</rt></ruby>，结果拼音全堆在“学”字上方，其余字无注音，屏幕阅读器也只朗读第一个字加整串拼音。
必须严格按字粒度拆解，每个字独立套一层结构：
<ruby><rb>学</rb><rt>xué</rt></ruby><ruby><rb>而</rb><rt>ér</rt></ruby><ruby><rb>时</rb><rt>shí</rt></ruby>- ……依此类推
尤其注意虚词（之、乎、者、也）、通假字（蚤→早）、破读字（“王天下”的“王”读 wàng），这些都得人工校对后单独标注，ruby 不提供任何语音推理能力。
训读、反切、直音混用时，rt 内容要统一编码，别混 HTML 实体
古籍网页常需同时呈现反切（如“德，多则切”）、直音（如“音得”）、现代拼音（如“dé”）甚至日文训读（如「とく」）。但 rt 只接受纯文本内容，不能嵌套 sup、small 或 HTML 实体（如 多）——否则 Safari 会忽略整个 rt，Chrome 可能错位渲染。
立即学习“前端免费学习笔记（深入）”；
正确做法是：所有注音内容用 UTF-8 原生字符书写，确保字体支持：
- 反切：
<rt>多则切</rt>（不用“多 则 切”） - 直音：
<rt>音得</rt> - 拼音：
<rt>dé</rt>（带声调符号，非 “de4”） - 训读：
<rt>とく</rt>（需字体含平假名，如 Noto Sans CJK JP）
若页面需兼容 Windows 旧系统，CSS 中指定后备字体：font-family: "Noto Sans CJK SC", "Microsoft YaHei", sans-serif;
古籍排版要求竖排时，ruby-position: under 不可靠，优先用 writing-mode
《诗经》《楚辞》类网页常设 writing-mode: vertical-rl，此时默认 ruby-position: over 会让拼音跑到字左侧（即“上”变成“左”），而 ruby-position: under 在 Safari ≤ 16.3 和多数安卓 WebView 中完全不生效。
更稳妥的方案是放弃依赖 ruby-position，改用 CSS 控制流向：
- 给
ruby加writing-mode: horizontal-tb，强制拼音横排在字顶 - 或整体容器设
text-orientation: upright+ruby { ruby-position: over; }，部分新版 Safari 支持 - 禁用
rt { transform: rotate(90deg) }——这会让屏幕阅读器误读为装饰性内容
真实测试发现：iOS Safari 17+ 对竖排 ruby 支持仍不稳定，建议古籍项目上线前用 VoiceOver 实测朗读顺序是否为「先字、后音」。
老浏览器和邮件客户端降级时，rp 括号不是可选项，是必选项
很多古籍网站需通过邮件推送节选（如《昭明文选》每日一章），而 Outlook Desktop、Thunderbird 等客户端完全不解析 ruby 标签。此时若没 rp，用户看到的是「学xué而ér时shí……」连在一起，无法分辨哪段是音哪段是文。
必须为每个字配完整 rp 包裹：
<ruby> <rb>学</rb> <rp>(</rp> <rt>xué</rt> <rp>)</rp> </ruby>
注意：rp 必须成对、紧贴 rt、内容只能是 ( 或 )，不能加空格或换行；否则 Outlook 会直接丢弃整个 rt 块。
真正容易被忽略的是：服务端模板（如 Nunjucks、EJS）若动态拼接 ruby，漏掉一对 rp 就会导致整页古文在邮件中失去可读性——这不是样式问题，是语义断裂。
