古籍数字化中ruby标签必须严格遵循字—音一对一、显式rb+rt结构，禁止合并rt或错序；rt仅含可朗读拟音，反切等训诂信息存data-*属性；异体字需字体与编码双重保障；校勘记不得嵌套ruby。
ruby 标签在古籍数字化中不是“能用就行”，而是必须严格按字—音一对一、显式 rb+rt 结构来写，否则 OCR 后的注音会错位、校勘标记无法绑定、屏幕阅读器读不出声调——尤其对带反切、直音、读若等多重注音的文本，结构断裂等于语义丢失。
古籍注音必须拆到单字，不能合并拼音或共用 rt
古籍常见「一音多字」（如「讀若某」）或「一字多音」（如反切上字、下字），但 ruby 不支持跨字映射。浏览器只认紧邻关系：rb 和它后紧跟的 rt 绑定，中间不能有空格、换行、span 或其他标签。
- 错误写法：
<ruby>天<rt>tiān</rt><rb>地</rb><rt>dì</rt></ruby>（rb与rt顺序错乱，Safari 直接忽略第二组） - 正确写法：
<ruby><rb>天</rb><rt>tiān</rt></ruby><ruby><rb>地</rb><rt>dì</rt></ruby> - 遇到「讀若東」这类直音，需人工判断是否注音对象是「東」而非「讀」：只给「東」套
ruby，「讀若」二字不包裹
反切、读若、叶音等需用 data-* 辅助，不能塞进 rt
rt 只承载可朗读的语音内容（如 Unicode 拼音或注音符号），反切上字「德」下字「紅」这类非发音文本，硬塞进去会导致屏幕阅读器误读为「dé hóng」，破坏训诂逻辑。
- 把反切信息存进
data-qie="德紅"或data-zhiyin="東"，供 JS 提取、工具链校验或后台标注 -
rt内只放最终拟音结果，例如「東」对应反切「德紅」，则<rt>dōng</rt>，而非<rt>德紅</rt> - 叶音（临时改读）需额外加
class="ye"或data-yeyin="shì"，避免和本音混淆
繁体、异体、俗字注音必须逐字验证字体与编码
古籍含大量「臺」「峯」「衆」等异体字，ruby 能渲染的前提是系统字体支持这些字形 + 对应的注音符号（如「ㄊㄞ」）。Windows 默认新细明体缺「ㄖ」「ㄥ」等注音部件，导致 rt 显示为方框或空白。
- CSS 中强制指定后备字体链：
font-family: "PMingLiU", "KaiTi", "Noto Serif CJK TC", serif; - 禁用图片或 SVG 替代
rt—— 屏幕阅读器无法朗读，OCR 工具无法提取注音文本 - 对「亙」「昇」等 Unicode 扩展 B 区汉字，需确认服务器与浏览器均启用 UTF-8 且未被 CMS 自动转义
校勘记、小注与 ruby 的嵌套冲突必须规避
古籍页面常有双行小注（夹注）、旁批、脚注，若用 ruby 套小注文字，会触发浏览器对 rt 的默认上标缩放，导致小注字号失控、行高塌陷，甚至被裁切。
-
ruby只用于正文主字的语音标注，校勘记统一用aside+data-correction，不混入ruby流 - 禁止在
rt内嵌sup、small或span—— Safari 17+ 会丢弃样式，NVDA 会跳过整个rt - 若需在注音旁加「出處：《廣韻》」，应放在
ruby外部右侧，用aria-label关联，而非塞进rt
最易被忽略的是：古籍数字化不是把纸面排版“像素级还原”，而是重建可检索、可朗读、可校验的语义结构。ruby 的价值不在视觉效果，而在让「字—音—训」三者通过 DOM 节点精确锚定；一旦为图省事合并 rt 或跳过 rb，后续所有 NLP 分析、语音合成、跨库比对都会失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
