简介RTF 规范 v1.9 官方技术文档面向需要实现或解析富文本格式的开发者、编辑器与办公软件研发人员用于解决跨平台文本交换中格式控制、元素嵌入与排版兼容等实际问题。资源包共 1 个文件为 1 份 PDF 文档整体约 1.76MB即微软 2008 年发布的 RTF Specification 1.9.1 全文共 278 页适合作为案头参考手册随查随用。已有 741 人学习下载说明其在中文开发者社区中具备一定参考价值。文档系统覆盖 RTF 的历史沿革、文件头与信息头结构、控制字与组语法、Unicode 5.0 编码支持以及字体、颜色、表格、图片、超链接等格式控制与嵌入细节并说明相较旧版本新增的格式元素。读者可据此理解 RTF 的语法规则与实现要点为编写解析器、生成器或排查格式兼容问题提供权威依据。1. 一份 278 页的“说明书”RTF 到底是什么你有没有遇到过这种场景同事发来一个文档你打开后排版全乱了字体变了、表格错位、图片跑到了页脚。对方说“我存成 RTF 了呀应该通用才对”。这时候你心里冒出的第一个疑问往往是RTF 不是号称“富文本通用格式”吗怎么还会翻车RTF全称 Rich Text Format中文叫富文本格式是微软在 1987 年推出的一种文本文件格式用来描述文字长什么样、段落怎么排、图片表格往哪儿放。你可以把它理解成一份“给排版看的菜谱”正文是食材那些反斜杠开头的控制词是调料和火候说明读菜谱的软件照着做就能把一份带格式的文档还原出来。它最值得搞懂的地方在于——它是纯文本的却要表达富文本这个矛盾本身就决定了它所有的优点和毛病。搞懂 RTF你就搞懂了“格式描述”这件事的底层逻辑也就能明白为什么有些文档换个软件就面目全非。2. 为什么纯文本能装下富文本控制词与组的游戏2.1 用反斜杠当“暗号”的设计RTF 最反直觉的一点是它是一份纯 ASCII 文本文件你用记事本打开就能看到内容但里面全是\b、\par、\fonttbl这类反斜杠开头的“暗号”。这些暗号在规范里叫控制词Control Word每一个都对应一个排版指令。比如\b表示从这里开始加粗\b0表示取消加粗\par表示一个段落结束。打个比方这就像给排版工人写便条便条本身是普通文字但你在文字里夹了“从这里开始用黑体”“这里换行”的批注工人照着批注干活。RTF 的正文和控制词混在一起读文件的软件一边读一边执行批注最后渲染出带格式的文档。这种设计的好处是文件可以被任何文本工具打开、传输、甚至手工修改坏处是控制词一多人眼几乎没法读。规范里把 RTF 的基本构成拆成几类实体控制词、控制符号、组、目标Destination、单位。控制词是字母序列控制符号是单个非字母字符比如\\表示一个反斜杠本身组用花括号{}把一段内容包起来目标则是那些“只给特定读者看”的内容块比如字体表、颜色表。理解这几个实体你就理解了 RTF 的“语法骨架”。2.2 花括号就是作用域RTF 里花括号{}的地位相当于编程语言里的大括号它划定一个作用域。组内的格式设置只在这个组内生效出了组就恢复原样。这个机制让 RTF 能表达嵌套的格式比如“整段是宋体但其中某几个字是加粗的红色”。举个最小例子下面这段 RTF 片段描述“普通文字 加粗的‘重点’ 普通文字”{\rtf1\ansi\deff0 普通文字 {\b 重点} 普通文字 }第一行的\rtf1声明这是 RTF 版本 1\ansi声明字符集\deff0指定默认字体是字体表里第 0 号。第二行里{\b 重点}这个组把“重点”两个字包起来\b只在组内生效出了右花括号加粗就自动取消。这就是组作为作用域的直接体现——不需要写“取消加粗”作用域结束即失效。提示手工写 RTF 时花括号必须严格配对。少一个右括号后面的所有格式都会“泄漏”到文档末尾这是最常见的翻车点之一。2.3 头部、正文、尾部一份 RTF 的三段式一份完整的 RTF 文件在结构上分三块头部、文档区、结尾。头部里装着 RTF 版本号、字符集声明、字体表\fonttbl、颜色表\colortbl、样式表\stylesheet这些“全局配置”文档区是真正的正文内容夹杂着段落格式、字符格式、图片、表格、域代码结尾就是一个右花括号收尾。这个结构和 HTML 有点像头部像head里的样式定义文档区像body。区别在于 RTF 的头部信息是“编号引用制”——字体表里按顺序列出字体正文里用\f0、\f1这样的编号去引用而不是直接写字体名。颜色表同理\colortbl里按顺序定义颜色正文用\cf1引用第 1 号颜色。这种“先建表、后引用”的设计是为了让同一份文件里重复出现的字体和颜色只描述一次减小体积——虽然 RTF 的体积问题后来还是没解决。3. 版本 1.9 到底新在哪从字符集到数学公式的演进3.1 Unicode 支持是分水岭RTF 诞生于 1987 年那时候字符编码还是各家各户的代码页一份中文文档拿到英文系统上就是乱码。规范演进到 1.9 版本2008 年发布对应 Office 2007 时代一个关键变化是对 Unicode 的支持更加完整规范里专门有“Unicode RTF”一节用\uN这样的控制词把字符以 Unicode 码位写进文件同时保留一个 ASCII 回退字符让不认识 Unicode 的老阅读器至少能显示个占位符。这个设计的巧妙之处在于“向前兼容”新软件读到\uN就渲染正确字符老软件读到就跳过、用后面的回退字符顶上。通俗地说就像一份文件同时写了“正式版”和“简写版”谁认识哪个就用哪个。这也是 RTF 能横跨 Windows 和 Macintosh 两种平台、跨越二十多年还能被读取的根本原因。3.2 表格、图片、域代码富文本的“重装备”规范正文里花了大量篇幅描述表格定义Table Definitions、图片Pictures、域Fields、绘图对象Drawing Objects这些复杂元素的编码方式。以表格为例RTF 用\trowd开始一行表格定义用\cellx指定每个单元格的右边界位置用\cell标记单元格结束用\row标记行结束。一整套控制词组合下来才能描述一张带边框、带合并单元格的表格。图片则是以十六进制数据的形式嵌在文件里用\pict开头后面跟图片格式声明如\pngblip、\jpegblip和一大串十六进制字符。这就是 RTF 文件体积偏大的直接原因一张图片被转成十六进制文本后体积大约膨胀一倍。规范里还描述了 Word 97 到 Word 2007 时代的绘图对象Shapes格式包含基本格式、绘图对象属性等大段内容这部分是 RTF 复杂度的“重灾区”。3.3 数学公式与自定义 XML规范后期的扩展规范后半部分出现了数学Mathematics章节用一套专门的语法描述公式对象、公式参数和数学控制词还有自定义 XML 标签Custom XML Tags、智能标记数据SmartTag Data这些内容。这些扩展说明 RTF 并不是一个“冻结”的格式它一直在跟着办公软件的功能演进而加码。但加码的代价是规范越来越厚——这份文档本身就有 278 页。对普通用户来说这意味着“RTF 通用”这句话要打个折扣越复杂的元素不同软件之间的兼容性越难保证。一份带复杂表格和公式的 RTF在 A 软件里排版正常到 B 软件里就可能错位这不是格式本身坏了而是两边对规范里那些“可选实现”的理解不一致。4. 易混概念辨析RTF 不是你想的那样4.1 易混点一RTF 和纯文本TXT很多人以为“RTF 是纯文本文件所以它和 TXT 差不多”。混淆的原因在于两者用记事本都能打开看起来都是字符。但区别是本质性的TXT 只存字符本身不存任何格式信息RTF 存的是“字符 排版指令”那些反斜杠控制词就是格式。怎么区分看用途——你要传一段不带格式的代码或日志用 TXT你要传一份带加粗、颜色、表格的文档且希望对方不装特定软件也能打开才考虑 RTF。4.2 易混点二RTF 和 DOC/DOCX这是最常见的混淆。三者都是微软系的文档格式但定位不同DOC/DOCX 是 Word 的原生格式能存最完整的编辑信息RTF 是“交换格式”目标是跨软件、跨平台可读所以它刻意只描述“渲染结果”不描述 Word 的私有编辑状态。打个比方DOCX 是“施工图”连脚手架怎么搭都画了RTF 是“效果图”只告诉你成品长什么样。所以用 Word 打开 RTF 再另存可能丢失一些原生格式特性这是设计使然不是 bug。4.3 易混点三RTF 和 HTML/Markdown三者都是“用纯文本描述富文本”的思路容易让人以为可以互相替代。区别在于服务对象HTML 面向浏览器渲染标签语义偏“结构”这是标题、这是列表Markdown 面向人写人读语法极简RTF 面向办公文档排版控制词偏“视觉指令”这里加粗、这里字号 12。所以 RTF 里没有“语义化标题”的概念只有“这段文字用什么字体多大字号”。你要做网页别用 RTF你要写技术文档Markdown 更顺手你要生成一份能在老式办公软件里打开的带格式文档RTF 才是对的工具。4.4 易混点四RTF 规范和 RTF 阅读器规范是“菜谱”阅读器是“厨师”。很多人读规范时以为照着文档就能写出完美解析器实际不然规范里大量描述是“参考性”的不同软件对同一控制词的处理有差异尤其是表格、绘图对象这些复杂部分。混淆点在于把“规范写了”等同于“所有软件都这么实现”。怎么区分记住一句话规范定义的是“应该怎么编码”兼容性取决于“对方怎么解码”。做跨软件交换时永远要用目标软件实测别只信规范。4.5 易混点五RTF 的“富”和“重”最后一个误区是把“功能多”当成“好用”。RTF 支持图片、表格、公式看起来什么都能装但每装一样文件体积和解析复杂度都往上走。一份几十页带图的 RTF 可能比同内容的 DOCX 还大打开还更慢。所以“RTF 能做什么”和“RTF 适合做什么”是两回事——它的强项是“轻量交换”不是“重度排版”。5. 什么时候该用 RTF什么时候别碰判断标准其实就一条你要的是“让对方能打开并看到大致正确的排版”还是“让对方看到和我屏幕上一模一样的排版”。前者选 RTF后者别选。具体来说适合用 RTF 的场景有这么几类。一是跨软件交换你不确定对方用什么办公软件甚至可能是老版本RTF 的兼容面最广。二是程序生成带格式文档很多报表系统、邮件系统用 RTF 作为输出格式因为它是纯文本程序拼接字符串就能生成不需要引入复杂的文档库。三是需要“人肉可检查”的场合RTF 是纯文本出问题时可以用文本工具打开看控制词排查比二进制格式容易得多——这一点在调试自动生成的文档时是血泪经验。不适合的场景同样明确。第一需要精确还原复杂排版时别用多栏布局、复杂表格合并、精细图形RTF 的描述能力有限跨软件必然有偏差。第二文件体积敏感时别用嵌图片的 RTF 体积膨胀明显传输和存储都不划算。第三需要保留编辑历史、批注、修订等协作信息时别用这些是原生格式的强项RTF 只能表达渲染结果。第四纯数据交换别用传结构化数据用 JSON、CSVRTF 是给人看的不是给程序读的。下面这张表可以帮你快速对照场景选 RTF选其他不确定对方软件环境是—程序拼接生成带格式文档是—需要精确还原复杂排版—原生格式文件体积敏感含大图—压缩格式纯结构化数据传输—JSON/CSV需要修订、批注协作—原生格式我自己的习惯是凡是程序自动生成、要发给外部、又不确定对方环境的文档一律先出 RTF再用两三种不同软件各打开一遍做“兼容性冒烟测试”。有一次偷懒跳过这步结果一份带表格的报表在对方的老版本软件里整个错位返工重发。从那以后我每次生成 RTF 都强制走一遍多软件打开检查宁可多花五分钟也不赌兼容性。这份 278 页的规范值得放在手边当参考手册——不是从头读到尾而是在遇到具体控制词、具体元素时去查对应章节配合实测才能真正把 RTF 用明白。希望帮到你。本文还有配套的精品资源点击获取