前阵子帮某跨平台系统处理历史数据迁移碰到一个非常典型的问题Java解析RTF文件中文全部乱码。现象有两种一种是正文变成一堆\u21647?\u24494?之类的数字加问号另一种更惨直接就是不可读的乱码串。折腾了两三天把RTF的编码机制、JVM字符集、现成解析库的坑都过了一遍这篇文章把完整的排查思路和解法写清楚。先说结论RTF本身不背锅中文乱码几乎都是“编码识别顺序”出了问题——要么读文件时用错了字符集要么读对了但没处理RTF内部的Unicode转义要么处理了但没清掉转义后面跟的替代字符。下面从原理到代码一步步拆。1. 先搞明白RTF里的中文到底是怎么存的1.1 RTF本质是带控制字的文本不是二进制很多人以为RTF是某种私有二进制格式其实不是。RTFRich Text Format本质上是纯文本文件只是里面有大量以反斜杠开头的控制字比如\rtf1、\ansi、\par这些。控制字负责描述格式正文内容就混在这些控制字中间。因为它是文本所以“中文怎么存”完全取决于文件的字符编码和内部转义策略这两者一旦和Java读取方式对不上乱码就是必然的。实际处理过的RTF文件里中文主要有三种存在形态这个必须先分清楚因为不同形态对应完全不同的解析策略。第一种形态Unicode转义形式最标准也最常见长这样{\rtf1\ansi\ansicpg936\deflang1028 {\fonttbl{\f0\fnil\fcharset134 SimSun;}} \fs24\f0 欢迎\u26469?到\u27494?汉}注意\u26469?和\u27494?这里的\u后面跟的是中文字符的Unicode码点十进制值后面那个?是RTF规范里规定必须跟随的“替代字符”alternate character。替代字符的作用是如果阅读这个RTF的程序不理解\uN转义就直接显示这个替代字符不至于整行空白。所以\u26469?实际上表示的是“来”字?是留给不兼容阅读器的占位符。第二种形态代码页直写形式国产办公软件常见文件头部声明了\ansicpg936意思是“本文件内部的ANSI字符请按代码页936GBK来解释”。在这种文件里正文中的中文不再用\uN转义而是直接把GBK编码的字节写进文件。你用十六进制工具看能看到类似BB B6 D3 AD这样的连续字节它们就是“欢迎”两个字的GBK编码。这种文件如果直接用UTF-8去解码百分之百乱码。第三种形态混合形式标题部分用了代码页直写正文部分用了Unicode转义或者反过来。常见于多个编辑器接力编辑过的RTF或者程序自动生成时没有统一编码策略。这种最烦人因为你得同时处理两种逻辑。1.2 Java乱码的三个层次很多文章把RTF乱码归结为一个原因但实际操作中我遇到的乱码其实是三个不同层次的问题排查方式完全不同。第一层读文件字节流时用错了字符集Java读取文本文件时如果你不显式指定字符集就用JVM默认字符集。在Windows中文环境通常默认是GBK在Linux服务器通常默认是UTF-8。同一份RTF文件在Windows上读是好的部署到Linux上就乱码问题基本都出在这一层。这种情况表现是整个文档的汉字全是乱码但ASCII字符正常。第二层没处理RTF内部的\uN转义文件读对了但RTF里的中文是以\u26469?这种转义形式存在的你得先把这些转义序列翻译成真正的汉字。如果没做这一步你得到的就是一堆\u数字?的文本看起来像密码而不是乱码。第三层\uN转义处理了但没清掉替代字符正则替换时只把\u26469换成“来”后面的那个?残留下来了。结果导出的文本变成“欢?迎?来?到?武?汉”每隔一个字夹一个问号。这个坑特别隐蔽因为一眼看过去不是乱码但有规律的杂字符很容易被当成数据源问题。这三层问题可以叠加存在也可以单独出现。排查时建议按“字节解码 → 转义解析 → 替代字符清理”三步走每做完一步就输出中间结果看一眼就能定位问题出在哪一层。我最早就是跳着排查浪费了不少时间。2. 动手前先花30秒定位RTF文件的真实编码2.1 头部声明能告诉你什么任何RTF文件的第一行基本都是这样的结构{\rtf1\ansi\ansicpg936\deflang1028\deflangfe2052这里有几个关键控制字需要读明白\ansi说明文件是基于ANSI码页的\ansicpg936声明ANSI代码页是936也就是简体中文GBK\ansicpg1252声明代码页是1252也就是英文/西欧系统常见的Windows Latin-1\ansicpg950繁体中文BIG5如果头部是\ansicpg936那文件内部凡是“直写”形式的字符都按GBK处理。如果看到\ansicpg1252但文件里又有中文那中文大概率是以\uN转义形式存在的因为1252码页本身没有中文字符。有一点要特别提醒头部声明是“建议”不是“绝对”。很多程序生成RTF时头部写的是\ansicpg936但实际正文里的中文却以Unicode转义形式存储这两种信息并不冲突\ansicpg管的是“直写字节的解释方式”\uN管的是“显式编码的字符”。所以头部声明能帮你确定直写字节用什么解码但不能帮你决定要不要解析\uN。2.2 用十六进制视角验证不要只看文本编辑器文本编辑器会自动猜测编码并解码容易误导你。看RTF编码最靠谱的方式是看原始字节。用任意十六进制查看工具打开RTF文件重点看三处第一处文件开头有没有BOMEF BB BF开头UTF-8带BOM这种RTF在Java里应该按UTF-8读FF FE开头UTF-16 LE带BOM少见但存在没有BOM继续往下看第二处{\rtf1后面跟的是什么正常情况下是\ansi或\macMac编码如果看到\ansi再往后找\ansicpg后面的数字基本就能确定代码页。第三处正文中文区域的字节分布用十六进制工具定位到文件中段找一个中文较多的位置看字节特征如果中文区域的字节都是\u开头后面跟数字说明整个中文区是ASCII可见字符组成的转义序列这种情况文件里的任何字节都不超过0x7F如果中文区域的字节表现为两个连续的高位字节都大于0x7F比如BB B6、D3 AD说明是GBK直写如果字节表现为三字节连续且第一字节在0xE0-0xEF范围大概率是UTF-8直写这种情况偶尔在一些非标准工具生成的RTF里能见到把这三处看完基本能确定文件的真实编码形态再决定Java用什么字符集去解码。2.3 一句话记忆法先看头部再验字节后写代码我给自己总结的口诀先看头部声明定代码页再看字节特征定文件编码最后才写解析代码。不要试图用一个“万能解析方案”同时处理所有情况。正确的思路是写一个识别函数输入RTF文件字节流输出一个判断结果——是GBK直写、UTF-8直写、还是纯Unicode转义。然后再分流处理。识别逻辑并不复杂判断BOM、判断头部ansicpg值、扫描正文是否出现\u模式三步就能完成。3. 手写一套可控的RTF中文提取方案3.1 第一步用对字符集读取字节流Java里最容易出问题的就是FileReader这个东西它内部用的是平台默认字符集且无法指定。解析RTF必须绕开它用Files.readAllBytes拿到原始字节再显式指定字符集转字符串。import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.charset.StandardCharsets; public class RtfReader { public static String readRtfAsString(Path path, String charsetName) throws Exception { byte[] bytes Files.readAllBytes(path); // 关键显式指定字符集绝不要用平台默认 return new String(bytes, charsetName); } }这里的charsetName按第二章的检测结果来。文件编码是GBK直写型就传GBK是UTF-8直写型就传UTF-8如果文件里所有中文字节都不超过0x7F纯Unicode转义形态那么传什么字符集都无所谓因为转义序列本身就是ASCII字符但建议还是按照头部声明传更稳。3.2 第二步解析\uN转义处理负数与替代字符这是整个方案的核心也是最容易踩坑的地方。RTF规范里\uN后面的N是一个带符号的16位十进制整数取值范围是-32768到32767。对于Unicode码点大于32767的字符比如很多CJK扩展区的汉字、生僻字生成器可能直接写出负数表示“这个字符的码点减去65536”。所以解析时遇到负数必须加65536还原成真正的Unicode码点。替代字符怎么处理\uN后面紧跟的那个字符是给不兼容阅读器看的占位符我们既然能正确解析\uN这个占位符就必须删掉。正则要连这个占位符一起匹配掉。但这里有个细节占位符不一定是?有些生成器输出空格有些输出_。好在规范规定占位符是单个7位ASCII字符我们可以用一个相对稳健的写法把\u数字和紧跟其后的一位非换行字符一起替换成目标汉字。import java.util.regex.Matcher; import java.util.regex.Pattern; public class RtfUnicodeDecoder { private static final Pattern RTF_UNICODE_PATTERN Pattern.compile(\\\\u(-?\\d).?); public static String decode(String rtf) { Matcher matcher RTF_UNICODE_PATTERN.matcher(rtf); StringBuffer sb new StringBuffer(); while (matcher.find()) { int codePoint Integer.parseInt(matcher.group(1)); if (codePoint 0) { codePoint 65536; } // 只处理有效Unicode范围 if (codePoint 0 codePoint 0x10FFFF) { matcher.appendReplacement(sb, Matcher.quoteReplacement(new String(Character.toChars(codePoint)))); } } matcher.appendTail(sb); return sb.toString(); } }注意appendReplacement的第二个参数里的$和\会被特殊处理所以需要Matcher.quoteReplacement包一层否则遇到替换文本里的$会抛异常这个细节是我在批量处理时踩出来的。这里正则里的.?匹配的是\u数字后面的那个占位符.?最多匹配一个字符但不匹配换行。实测下来这个写法的成功率比我之前用的\s?高得多因为有的RTF生成器会在占位符位置放一个普通字符而不是空白。3.3 第三步清理控制字提取纯文本\uN转义处理完之后RTF里剩下的就是控制字和分组符号比如\par段落结束、\line换行、\tab制表符、\fs24字体大小、\f0字体索引、{和}分组。要从里面提取纯文本需要做一轮清理。完整的RTF状态机解析非常复杂要考虑嵌套分组、控制字参数、十六进制转义\xx等各种情况。大多数业务场景用不到那么重我通常是做一个“工程够用版”的清理器public class RtfTextCleaner { public static String clean(String decodedRtf) { String text decodedRtf; // 1. 段落与换行控制字转成换行符 text text.replaceAll(\\\\par\\b, \n); text text.replaceAll(\\\\line\\b, \n); // 2. 制表符控制字转成制表符 text text.replaceAll(\\\\tab\\b, \t); // 3. 十六进制字节转义这里简化为直接丢弃 // 如果你确认文件是GBK直写型且需要还原这些字节需要另行处理两个连续\xx text text.replaceAll(\\\\[0-9a-fA-F]{2}, ); // 4. 去掉普通控制字及其参数例如 \fs24 \cf1 \b0 等 text text.replaceAll(\\\\[a-zA-Z]-?\\d* ?, ); // 5. 特殊符号的转义形式例如 \{ \} \\ \~ 等 text text.replaceAll(\\\\\\{, \uFF5B); text text.replaceAll(\\\\\\}, \uFF5D); text text.replaceAll(\\\\\\\\, \u005C); text text.replaceAll(\\\\~, \u00A0); text text.replaceAll(\\\\-, \u00AD); // 6. 去掉分组符号 text text.replaceAll([{}], ); // 7. 清理多余空白行 text text.replaceAll(\\n\\s\\n, \n); return text.trim(); } }这个清理器并不完美比如\b这个控制字在正则里会被当成单词边界而不是字面字符实际使用时要注意转义。另外对于\xx这种十六进制转义如果文件是GBK直写且转义恰好在汉字中间丢弃会丢信息。完整的做法是检测连续两个\xx把两个十六进制字节按代码页拼成一个汉字。但这种情况在实际业务文件里很少见多数时候\xx是用来表示标点或ASCII特殊字符丢弃影响不大。3.4 完整工具类把三步串起来把上面三步合成一个完整的工具类直接可以拿去做批量文件提取import java.nio.charset.Charset; import java.nio.file.Files; import java.nio.file.Path; import java.util.regex.Matcher; import java.util.regex.Pattern; public class RtfPlainTextExtractor { private static final Pattern RTF_UNICODE_PATTERN Pattern.compile(\\\\u(-?\\d).?); public static String extract(Path rtfFile, Charset charset) throws Exception { byte[] bytes Files.readAllBytes(rtfFile); String rtfContent new String(bytes, charset); String noUnicode decodeUnicode(rtfContent); return cleanControlWords(noUnicode); } private static String decodeUnicode(String rtf) { Matcher matcher RTF_UNICODE_PATTERN.matcher(rtf); StringBuffer sb new StringBuffer(); while (matcher.find()) { int codePoint Integer.parseInt(matcher.group(1)); if (codePoint 0) { codePoint 65536; } if (codePoint 0 codePoint 0x10FFFF) { matcher.appendReplacement(sb, Matcher.quoteReplacement(new String(Character.toChars(codePoint)))); } } matcher.appendTail(sb); return sb.toString(); } private static String cleanControlWords(String text) { text text.replaceAll(\\\\par\\b, \n); text text.replaceAll(\\\\line\\b, \n); text text.replaceAll(\\\\tab\\b, \t); text text.replaceAll(\\\\[0-9a-fA-F]{2}, ); text text.replaceAll(\\\\[a-zA-Z]-?\\d* ?, ); text text.replaceAll(\\\\\\{, \uFF5B); text text.replaceAll(\\\\\\}, \uFF5D); text text.replaceAll(\\\\\\\\, \u005C); text text.replaceAll([{}], ); text text.replaceAll(\\n\\s\\n, \n); return text.trim(); } }使用示例Path file Path.of(sample.rtf); // 文件确定为GBK直写型时就传GBK纯Unicode转义型时传UTF-8或其他均可 String plainText RtfPlainTextExtractor.extract(file, Charset.forName(GBK)); System.out.println(plainText);这个方案的优点是无第三方依赖、逻辑可控、出了问题能快速定位。缺点是对异常RTF的容错不如成熟解析库。如果项目里解析量大、文件来源杂我更推荐直接用现成库。4. 不想造轮子两个现成库实测对比4.1 Apache Tika的RTFParser适合批量流水线Java生态里解析RTF最省心的路子是Apache Tika。它把一个RTF文件解析成纯文本只需要几行代码而且内部处理了\uN转义、控制字清理、编码探测这些脏活累活。先加依赖以Maven为例dependency groupIdorg.apache.tika/groupId artifactIdtika-parsers-standard-package/artifactId version2.9.0/version /dependency解析代码import org.apache.tika.parser.rtf.RTFParser; import org.apache.tika.sax.BodyContentHandler; import org.apache.tika.metadata.Metadata; import org.apache.tika.parser.ParseContext; import java.io.InputStream; import java.nio.file.Files; import java.nio.file.Path; public class TikaRtfExtractor { public static String extract(Path rtfFile) throws Exception { RTFParser parser new RTFParser(); BodyContentHandler handler new BodyContentHandler(-1); Metadata metadata new Metadata(); ParseContext context new ParseContext(); try (InputStream in Files.newInputStream(rtfFile)) { parser.parse(in, handler, metadata, context); return handler.toString(); } } }注意new BodyContentHandler(-1)这个构造参数-1表示不限制输出字符数。Tika默认对输出长度有限制解析大文件时如果不设这个参数会截断内容这是我实际踩过的坑。Tika的RTF解析对绝大多数正常来源的RTF都能正确处理包括混合编码、嵌套分组、复杂表格。批量处理大批历史文件时Tika的稳定性和容错能力明显优于手写方案。4.2 Swing自带的RTFEditorKit适合快速原型如果你不想引入任何第三方依赖JDK自带的Swing组件里藏着一个RTFEditorKit能直接读RTF并提取文本。它本来是给富文本编辑器用的但拿来解析RTF也够用。import javax.swing.text.Document; import javax.swing.text.rtf.RTFEditorKit; import java.io.FileInputStream; import java.io.InputStream; public class SwingRtfExtractor { public static String extract(String rtfFilePath) throws Exception { RTFEditorKit kit new RTFEditorKit(); Document doc kit.createDefaultDocument(); try (InputStream in new FileInputStream(rtfFilePath)) { kit.read(in, doc, 0); return doc.getText(0, doc.getLength()); } } }这个方案写起来最简洁但有一个致命的坑RTFEditorKit.read接受的是InputStream它内部对字节流的解码依赖系统默认字符集具体来说就是读文件时用的是平台默认编码。在Windows中文系统上跑没问题部署到UTF-8的Linux服务器上同样的代码可能直接乱码或者解析失败。这个坑在小规模工具里可能不暴露但放到生产环境就是定时炸弹。4.3 三个方案怎么选方案依赖编码可控性容错能力性能表现适合场景手写解码器无完全可控低依赖文件规范程度高几十行正则即可单文件、小批量、需要精确控制Apache Tika引入tika-parsers内部自动处理高兼容多源生成文件中有一定启动开销大量文件、流水线处理、混合来源Swing RTFEditorKitJDK自带低依赖系统默认编码中高轻量桌面工具快速原型、Windows环境个人建议是如果只是偶尔解析一个RTF手写方案完全够如果数据量上千且来源复杂直接上Tika别在这方面省依赖。Swing那个方案我建议除非是纯Windows桌面工具否则不要用于生产环境编码问题不可控。5. 实战里的三个典型坑和排查实录5.1 两个来源的文件同一套代码一个正常一个乱码某次迁移任务里一部分RTF文件来自某主流办公软件另一部分来自某国产办公软件用相同代码解析结果前一批正常后一批全乱。当时我先入为主认为是所有RTF都带\uN转义写代码时只处理了转义、没管直写字节而国产办公软件保存的RTF文件恰恰是把GBK字节直接写进文件的直写形态。头部声明虽然都是\ansicpg936但正文存储策略完全不同。解决方法是写一个前置识别函数扫描前几KB内容如果检测到\u-?\d模式频率较高走转义解析流程如果中文区域字节大量超过0x7F按声明的ansicpg值对应字符集整体解码。核心判断逻辑就一条转义序列是纯ASCII可见字符直写字节必然包含高位字节。5.2 同一份RTFWindows正常、Linux乱码这可能是Java解析RTF乱码中最常见的一种。本地开发环境是Windows中文版JVM默认字符集file.encoding通常是GBK代码里又用了new String(bytes)或者FileReader这种隐式字符集所以本地测试一切正常。部署到Linux服务器后服务器默认字符集是UTF-8同样的代码读取GBK直写型RTF文件每个中文字符都变成了?或乱码。排查这种问题最快的办法在服务器上执行java -XshowSettings:properties -version看输出的file.encoding和sun.jnu.encoding值。如果是非UTF-8且代码没有显式指定字符集就是问题源头。根治方式是所有字符串和字节流的转换都显式传字符集同时部署时加上JVM参数-Dfile.encodingUTF-8。5.3 提取出来的文本里夹着零星问号这是替代字符残留。手写解析时正则写的是\\\\u(-?\\d)匹配到的内容只包括数字替换成汉字后原位置后面的?没有动导致结果出现有规律的杂字符。解决方式就是3.2节里写的那样匹配时把\u数字后面的一个字符一并吃掉。我最初没意识到RTF规范里要求必须跟一个替代字符走了不少弯路。如果你用的是Tika一般不会遇到这个问题它内部处理了如果是自己解析这个替代字符必须处理。5.4 排查速查表现象可能原因检查方法解决方案所有中文乱码ASCII正常解字节流时字符集用错查文件头部ansicpg用十六进制工具看中文区域字节显式按GBK或UTF-8解码文本里全是\u数字?未处理RTF内部Unicode转义搜索文本是否含\u序列用正则解析\uN转义提取结果夹杂单个?字符替代字符未删除观察问号是否有规律地间隔出现匹配\uN时连带处理其后字符Windows正常Linux乱码JVM默认字符集不一致执行java -XshowSettings:properties -version显式指定字符集加-Dfile.encodingUTF-8Tika解析被截断未设置输出长度限制检查输出文本长度是否固定值用new BodyContentHandler(-1)表格数据错位丢失RTF中表格结构复杂查看是否含\cell、\row控制字改用Tika解析或先转HTML再提取5.5 批量场景的两个性能建议批量解析几百上千个RTF时有两个容易忽略的性能点。第一正则Pattern一定要定义成静态常量不要在方法里重复compilePattern.compile的开销比大多数人以为的大得多大量文件时会把解析时间拖长好几倍。第二大文件不要一次性把整个文件读成字符串再正则替换RTF解析本身字符串操作多内存占用大可以考虑用BufferedInputStream分块读但RTF结构有跨块控制字分块处理实现复杂所以我的建议是单文件超过10MB的RTF少见过真遇到大文件优先考虑Tika它对输入流做了更合理的处理。我在实际跑批时发现手写方案解析1000个平均50KB的RTF总耗时大约4秒Tika跑同样一批耗时大约9秒。但Tika处理格式怪异的文件基本不报错手写方案遇到一个不规范文件就可能抛异常中断整个批次。所以性能不是选型的第一指标稳定性才是。最后分享一个排查技巧如果你面对一个已经乱码的RTF别急着写代码先在十六进制工具里看几屏内容。乱码有规律——GBK字节被UTF-8解码显示成两个或三个奇怪的字符UTF-8被GBK解码显示成中文字符夹着大量个别生僻字。这两种有明显特征。记住一个判断技巧文本里出现“锟斤拷”这种毫无意义的中字组合基本可以断定UTF-8字节流被GBK解码了文本里出现大量\u数字但没有汉字说明转义层没处理。根据规律反推原始编码比瞎猜高效得多。这个内容后续还可以这样扩展解析RTF提取纯文本只是第一步如果再往里走还需要处理RTF转HTML、保留样式信息的结构化解析以及处理表格、嵌入图片等复杂元素。不同需求对“解析”的要求完全不同先搞清楚你到底是只要文本还是要保格式再决定用多重的方案。 
长河君 · 2026/10/14 12:24:49 · 阅读 1.2k Java解析RTF文件中文乱码排查指南：字符集与Unicode转义详解
前阵子帮某跨平台系统处理历史数据迁移碰到一个非常典型的问题Java解析RTF文件中文全部乱码。现象有两种一种是正文变成一堆\u21647?\u24494?之类的数字加问号另一种更惨直接就是不可读的乱码串。折腾了两三天把RTF的编码机制、JVM字符集、现成解析库的坑都过了一遍这篇文章把完整的排查思路和解法写清楚。先说结论RTF本身不背锅中文乱码几乎都是“编码识别顺序”出了问题——要么读文件时用错了字符集要么读对了但没处理RTF内部的Unicode转义要么处理了但没清掉转义后面跟的替代字符。下面从原理到代码一步步拆。1. 先搞明白RTF里的中文到底是怎么存的1.1 RTF本质是带控制字的文本不是二进制很多人以为RTF是某种私有二进制格式其实不是。RTFRich Text Format本质上是纯文本文件只是里面有大量以反斜杠开头的控制字比如\rtf1、\ansi、\par这些。控制字负责描述格式正文内容就混在这些控制字中间。因为它是文本所以“中文怎么存”完全取决于文件的字符编码和内部转义策略这两者一旦和Java读取方式对不上乱码就是必然的。实际处理过的RTF文件里中文主要有三种存在形态这个必须先分清楚因为不同形态对应完全不同的解析策略。第一种形态Unicode转义形式最标准也最常见长这样{\rtf1\ansi\ansicpg936\deflang1028 {\fonttbl{\f0\fnil\fcharset134 SimSun;}} \fs24\f0 欢迎\u26469?到\u27494?汉}注意\u26469?和\u27494?这里的\u后面跟的是中文字符的Unicode码点十进制值后面那个?是RTF规范里规定必须跟随的“替代字符”alternate character。替代字符的作用是如果阅读这个RTF的程序不理解\uN转义就直接显示这个替代字符不至于整行空白。所以\u26469?实际上表示的是“来”字?是留给不兼容阅读器的占位符。第二种形态代码页直写形式国产办公软件常见文件头部声明了\ansicpg936意思是“本文件内部的ANSI字符请按代码页936GBK来解释”。在这种文件里正文中的中文不再用\uN转义而是直接把GBK编码的字节写进文件。你用十六进制工具看能看到类似BB B6 D3 AD这样的连续字节它们就是“欢迎”两个字的GBK编码。这种文件如果直接用UTF-8去解码百分之百乱码。第三种形态混合形式标题部分用了代码页直写正文部分用了Unicode转义或者反过来。常见于多个编辑器接力编辑过的RTF或者程序自动生成时没有统一编码策略。这种最烦人因为你得同时处理两种逻辑。1.2 Java乱码的三个层次很多文章把RTF乱码归结为一个原因但实际操作中我遇到的乱码其实是三个不同层次的问题排查方式完全不同。第一层读文件字节流时用错了字符集Java读取文本文件时如果你不显式指定字符集就用JVM默认字符集。在Windows中文环境通常默认是GBK在Linux服务器通常默认是UTF-8。同一份RTF文件在Windows上读是好的部署到Linux上就乱码问题基本都出在这一层。这种情况表现是整个文档的汉字全是乱码但ASCII字符正常。第二层没处理RTF内部的\uN转义文件读对了但RTF里的中文是以\u26469?这种转义形式存在的你得先把这些转义序列翻译成真正的汉字。如果没做这一步你得到的就是一堆\u数字?的文本看起来像密码而不是乱码。第三层\uN转义处理了但没清掉替代字符正则替换时只把\u26469换成“来”后面的那个?残留下来了。结果导出的文本变成“欢?迎?来?到?武?汉”每隔一个字夹一个问号。这个坑特别隐蔽因为一眼看过去不是乱码但有规律的杂字符很容易被当成数据源问题。这三层问题可以叠加存在也可以单独出现。排查时建议按“字节解码 → 转义解析 → 替代字符清理”三步走每做完一步就输出中间结果看一眼就能定位问题出在哪一层。我最早就是跳着排查浪费了不少时间。2. 动手前先花30秒定位RTF文件的真实编码2.1 头部声明能告诉你什么任何RTF文件的第一行基本都是这样的结构{\rtf1\ansi\ansicpg936\deflang1028\deflangfe2052这里有几个关键控制字需要读明白\ansi说明文件是基于ANSI码页的\ansicpg936声明ANSI代码页是936也就是简体中文GBK\ansicpg1252声明代码页是1252也就是英文/西欧系统常见的Windows Latin-1\ansicpg950繁体中文BIG5如果头部是\ansicpg936那文件内部凡是“直写”形式的字符都按GBK处理。如果看到\ansicpg1252但文件里又有中文那中文大概率是以\uN转义形式存在的因为1252码页本身没有中文字符。有一点要特别提醒头部声明是“建议”不是“绝对”。很多程序生成RTF时头部写的是\ansicpg936但实际正文里的中文却以Unicode转义形式存储这两种信息并不冲突\ansicpg管的是“直写字节的解释方式”\uN管的是“显式编码的字符”。所以头部声明能帮你确定直写字节用什么解码但不能帮你决定要不要解析\uN。2.2 用十六进制视角验证不要只看文本编辑器文本编辑器会自动猜测编码并解码容易误导你。看RTF编码最靠谱的方式是看原始字节。用任意十六进制查看工具打开RTF文件重点看三处第一处文件开头有没有BOMEF BB BF开头UTF-8带BOM这种RTF在Java里应该按UTF-8读FF FE开头UTF-16 LE带BOM少见但存在没有BOM继续往下看第二处{\rtf1后面跟的是什么正常情况下是\ansi或\macMac编码如果看到\ansi再往后找\ansicpg后面的数字基本就能确定代码页。第三处正文中文区域的字节分布用十六进制工具定位到文件中段找一个中文较多的位置看字节特征如果中文区域的字节都是\u开头后面跟数字说明整个中文区是ASCII可见字符组成的转义序列这种情况文件里的任何字节都不超过0x7F如果中文区域的字节表现为两个连续的高位字节都大于0x7F比如BB B6、D3 AD说明是GBK直写如果字节表现为三字节连续且第一字节在0xE0-0xEF范围大概率是UTF-8直写这种情况偶尔在一些非标准工具生成的RTF里能见到把这三处看完基本能确定文件的真实编码形态再决定Java用什么字符集去解码。2.3 一句话记忆法先看头部再验字节后写代码我给自己总结的口诀先看头部声明定代码页再看字节特征定文件编码最后才写解析代码。不要试图用一个“万能解析方案”同时处理所有情况。正确的思路是写一个识别函数输入RTF文件字节流输出一个判断结果——是GBK直写、UTF-8直写、还是纯Unicode转义。然后再分流处理。识别逻辑并不复杂判断BOM、判断头部ansicpg值、扫描正文是否出现\u模式三步就能完成。3. 手写一套可控的RTF中文提取方案3.1 第一步用对字符集读取字节流Java里最容易出问题的就是FileReader这个东西它内部用的是平台默认字符集且无法指定。解析RTF必须绕开它用Files.readAllBytes拿到原始字节再显式指定字符集转字符串。import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.charset.StandardCharsets; public class RtfReader { public static String readRtfAsString(Path path, String charsetName) throws Exception { byte[] bytes Files.readAllBytes(path); // 关键显式指定字符集绝不要用平台默认 return new String(bytes, charsetName); } }这里的charsetName按第二章的检测结果来。文件编码是GBK直写型就传GBK是UTF-8直写型就传UTF-8如果文件里所有中文字节都不超过0x7F纯Unicode转义形态那么传什么字符集都无所谓因为转义序列本身就是ASCII字符但建议还是按照头部声明传更稳。3.2 第二步解析\uN转义处理负数与替代字符这是整个方案的核心也是最容易踩坑的地方。RTF规范里\uN后面的N是一个带符号的16位十进制整数取值范围是-32768到32767。对于Unicode码点大于32767的字符比如很多CJK扩展区的汉字、生僻字生成器可能直接写出负数表示“这个字符的码点减去65536”。所以解析时遇到负数必须加65536还原成真正的Unicode码点。替代字符怎么处理\uN后面紧跟的那个字符是给不兼容阅读器看的占位符我们既然能正确解析\uN这个占位符就必须删掉。正则要连这个占位符一起匹配掉。但这里有个细节占位符不一定是?有些生成器输出空格有些输出_。好在规范规定占位符是单个7位ASCII字符我们可以用一个相对稳健的写法把\u数字和紧跟其后的一位非换行字符一起替换成目标汉字。import java.util.regex.Matcher; import java.util.regex.Pattern; public class RtfUnicodeDecoder { private static final Pattern RTF_UNICODE_PATTERN Pattern.compile(\\\\u(-?\\d).?); public static String decode(String rtf) { Matcher matcher RTF_UNICODE_PATTERN.matcher(rtf); StringBuffer sb new StringBuffer(); while (matcher.find()) { int codePoint Integer.parseInt(matcher.group(1)); if (codePoint 0) { codePoint 65536; } // 只处理有效Unicode范围 if (codePoint 0 codePoint 0x10FFFF) { matcher.appendReplacement(sb, Matcher.quoteReplacement(new String(Character.toChars(codePoint)))); } } matcher.appendTail(sb); return sb.toString(); } }注意appendReplacement的第二个参数里的$和\会被特殊处理所以需要Matcher.quoteReplacement包一层否则遇到替换文本里的$会抛异常这个细节是我在批量处理时踩出来的。这里正则里的.?匹配的是\u数字后面的那个占位符.?最多匹配一个字符但不匹配换行。实测下来这个写法的成功率比我之前用的\s?高得多因为有的RTF生成器会在占位符位置放一个普通字符而不是空白。3.3 第三步清理控制字提取纯文本\uN转义处理完之后RTF里剩下的就是控制字和分组符号比如\par段落结束、\line换行、\tab制表符、\fs24字体大小、\f0字体索引、{和}分组。要从里面提取纯文本需要做一轮清理。完整的RTF状态机解析非常复杂要考虑嵌套分组、控制字参数、十六进制转义\xx等各种情况。大多数业务场景用不到那么重我通常是做一个“工程够用版”的清理器public class RtfTextCleaner { public static String clean(String decodedRtf) { String text decodedRtf; // 1. 段落与换行控制字转成换行符 text text.replaceAll(\\\\par\\b, \n); text text.replaceAll(\\\\line\\b, \n); // 2. 制表符控制字转成制表符 text text.replaceAll(\\\\tab\\b, \t); // 3. 十六进制字节转义这里简化为直接丢弃 // 如果你确认文件是GBK直写型且需要还原这些字节需要另行处理两个连续\xx text text.replaceAll(\\\\[0-9a-fA-F]{2}, ); // 4. 去掉普通控制字及其参数例如 \fs24 \cf1 \b0 等 text text.replaceAll(\\\\[a-zA-Z]-?\\d* ?, ); // 5. 特殊符号的转义形式例如 \{ \} \\ \~ 等 text text.replaceAll(\\\\\\{, \uFF5B); text text.replaceAll(\\\\\\}, \uFF5D); text text.replaceAll(\\\\\\\\, \u005C); text text.replaceAll(\\\\~, \u00A0); text text.replaceAll(\\\\-, \u00AD); // 6. 去掉分组符号 text text.replaceAll([{}], ); // 7. 清理多余空白行 text text.replaceAll(\\n\\s\\n, \n); return text.trim(); } }这个清理器并不完美比如\b这个控制字在正则里会被当成单词边界而不是字面字符实际使用时要注意转义。另外对于\xx这种十六进制转义如果文件是GBK直写且转义恰好在汉字中间丢弃会丢信息。完整的做法是检测连续两个\xx把两个十六进制字节按代码页拼成一个汉字。但这种情况在实际业务文件里很少见多数时候\xx是用来表示标点或ASCII特殊字符丢弃影响不大。3.4 完整工具类把三步串起来把上面三步合成一个完整的工具类直接可以拿去做批量文件提取import java.nio.charset.Charset; import java.nio.file.Files; import java.nio.file.Path; import java.util.regex.Matcher; import java.util.regex.Pattern; public class RtfPlainTextExtractor { private static final Pattern RTF_UNICODE_PATTERN Pattern.compile(\\\\u(-?\\d).?); public static String extract(Path rtfFile, Charset charset) throws Exception { byte[] bytes Files.readAllBytes(rtfFile); String rtfContent new String(bytes, charset); String noUnicode decodeUnicode(rtfContent); return cleanControlWords(noUnicode); } private static String decodeUnicode(String rtf) { Matcher matcher RTF_UNICODE_PATTERN.matcher(rtf); StringBuffer sb new StringBuffer(); while (matcher.find()) { int codePoint Integer.parseInt(matcher.group(1)); if (codePoint 0) { codePoint 65536; } if (codePoint 0 codePoint 0x10FFFF) { matcher.appendReplacement(sb, Matcher.quoteReplacement(new String(Character.toChars(codePoint)))); } } matcher.appendTail(sb); return sb.toString(); } private static String cleanControlWords(String text) { text text.replaceAll(\\\\par\\b, \n); text text.replaceAll(\\\\line\\b, \n); text text.replaceAll(\\\\tab\\b, \t); text text.replaceAll(\\\\[0-9a-fA-F]{2}, ); text text.replaceAll(\\\\[a-zA-Z]-?\\d* ?, ); text text.replaceAll(\\\\\\{, \uFF5B); text text.replaceAll(\\\\\\}, \uFF5D); text text.replaceAll(\\\\\\\\, \u005C); text text.replaceAll([{}], ); text text.replaceAll(\\n\\s\\n, \n); return text.trim(); } }使用示例Path file Path.of(sample.rtf); // 文件确定为GBK直写型时就传GBK纯Unicode转义型时传UTF-8或其他均可 String plainText RtfPlainTextExtractor.extract(file, Charset.forName(GBK)); System.out.println(plainText);这个方案的优点是无第三方依赖、逻辑可控、出了问题能快速定位。缺点是对异常RTF的容错不如成熟解析库。如果项目里解析量大、文件来源杂我更推荐直接用现成库。4. 不想造轮子两个现成库实测对比4.1 Apache Tika的RTFParser适合批量流水线Java生态里解析RTF最省心的路子是Apache Tika。它把一个RTF文件解析成纯文本只需要几行代码而且内部处理了\uN转义、控制字清理、编码探测这些脏活累活。先加依赖以Maven为例dependency groupIdorg.apache.tika/groupId artifactIdtika-parsers-standard-package/artifactId version2.9.0/version /dependency解析代码import org.apache.tika.parser.rtf.RTFParser; import org.apache.tika.sax.BodyContentHandler; import org.apache.tika.metadata.Metadata; import org.apache.tika.parser.ParseContext; import java.io.InputStream; import java.nio.file.Files; import java.nio.file.Path; public class TikaRtfExtractor { public static String extract(Path rtfFile) throws Exception { RTFParser parser new RTFParser(); BodyContentHandler handler new BodyContentHandler(-1); Metadata metadata new Metadata(); ParseContext context new ParseContext(); try (InputStream in Files.newInputStream(rtfFile)) { parser.parse(in, handler, metadata, context); return handler.toString(); } } }注意new BodyContentHandler(-1)这个构造参数-1表示不限制输出字符数。Tika默认对输出长度有限制解析大文件时如果不设这个参数会截断内容这是我实际踩过的坑。Tika的RTF解析对绝大多数正常来源的RTF都能正确处理包括混合编码、嵌套分组、复杂表格。批量处理大批历史文件时Tika的稳定性和容错能力明显优于手写方案。4.2 Swing自带的RTFEditorKit适合快速原型如果你不想引入任何第三方依赖JDK自带的Swing组件里藏着一个RTFEditorKit能直接读RTF并提取文本。它本来是给富文本编辑器用的但拿来解析RTF也够用。import javax.swing.text.Document; import javax.swing.text.rtf.RTFEditorKit; import java.io.FileInputStream; import java.io.InputStream; public class SwingRtfExtractor { public static String extract(String rtfFilePath) throws Exception { RTFEditorKit kit new RTFEditorKit(); Document doc kit.createDefaultDocument(); try (InputStream in new FileInputStream(rtfFilePath)) { kit.read(in, doc, 0); return doc.getText(0, doc.getLength()); } } }这个方案写起来最简洁但有一个致命的坑RTFEditorKit.read接受的是InputStream它内部对字节流的解码依赖系统默认字符集具体来说就是读文件时用的是平台默认编码。在Windows中文系统上跑没问题部署到UTF-8的Linux服务器上同样的代码可能直接乱码或者解析失败。这个坑在小规模工具里可能不暴露但放到生产环境就是定时炸弹。4.3 三个方案怎么选方案依赖编码可控性容错能力性能表现适合场景手写解码器无完全可控低依赖文件规范程度高几十行正则即可单文件、小批量、需要精确控制Apache Tika引入tika-parsers内部自动处理高兼容多源生成文件中有一定启动开销大量文件、流水线处理、混合来源Swing RTFEditorKitJDK自带低依赖系统默认编码中高轻量桌面工具快速原型、Windows环境个人建议是如果只是偶尔解析一个RTF手写方案完全够如果数据量上千且来源复杂直接上Tika别在这方面省依赖。Swing那个方案我建议除非是纯Windows桌面工具否则不要用于生产环境编码问题不可控。5. 实战里的三个典型坑和排查实录5.1 两个来源的文件同一套代码一个正常一个乱码某次迁移任务里一部分RTF文件来自某主流办公软件另一部分来自某国产办公软件用相同代码解析结果前一批正常后一批全乱。当时我先入为主认为是所有RTF都带\uN转义写代码时只处理了转义、没管直写字节而国产办公软件保存的RTF文件恰恰是把GBK字节直接写进文件的直写形态。头部声明虽然都是\ansicpg936但正文存储策略完全不同。解决方法是写一个前置识别函数扫描前几KB内容如果检测到\u-?\d模式频率较高走转义解析流程如果中文区域字节大量超过0x7F按声明的ansicpg值对应字符集整体解码。核心判断逻辑就一条转义序列是纯ASCII可见字符直写字节必然包含高位字节。5.2 同一份RTFWindows正常、Linux乱码这可能是Java解析RTF乱码中最常见的一种。本地开发环境是Windows中文版JVM默认字符集file.encoding通常是GBK代码里又用了new String(bytes)或者FileReader这种隐式字符集所以本地测试一切正常。部署到Linux服务器后服务器默认字符集是UTF-8同样的代码读取GBK直写型RTF文件每个中文字符都变成了?或乱码。排查这种问题最快的办法在服务器上执行java -XshowSettings:properties -version看输出的file.encoding和sun.jnu.encoding值。如果是非UTF-8且代码没有显式指定字符集就是问题源头。根治方式是所有字符串和字节流的转换都显式传字符集同时部署时加上JVM参数-Dfile.encodingUTF-8。5.3 提取出来的文本里夹着零星问号这是替代字符残留。手写解析时正则写的是\\\\u(-?\\d)匹配到的内容只包括数字替换成汉字后原位置后面的?没有动导致结果出现有规律的杂字符。解决方式就是3.2节里写的那样匹配时把\u数字后面的一个字符一并吃掉。我最初没意识到RTF规范里要求必须跟一个替代字符走了不少弯路。如果你用的是Tika一般不会遇到这个问题它内部处理了如果是自己解析这个替代字符必须处理。5.4 排查速查表现象可能原因检查方法解决方案所有中文乱码ASCII正常解字节流时字符集用错查文件头部ansicpg用十六进制工具看中文区域字节显式按GBK或UTF-8解码文本里全是\u数字?未处理RTF内部Unicode转义搜索文本是否含\u序列用正则解析\uN转义提取结果夹杂单个?字符替代字符未删除观察问号是否有规律地间隔出现匹配\uN时连带处理其后字符Windows正常Linux乱码JVM默认字符集不一致执行java -XshowSettings:properties -version显式指定字符集加-Dfile.encodingUTF-8Tika解析被截断未设置输出长度限制检查输出文本长度是否固定值用new BodyContentHandler(-1)表格数据错位丢失RTF中表格结构复杂查看是否含\cell、\row控制字改用Tika解析或先转HTML再提取5.5 批量场景的两个性能建议批量解析几百上千个RTF时有两个容易忽略的性能点。第一正则Pattern一定要定义成静态常量不要在方法里重复compilePattern.compile的开销比大多数人以为的大得多大量文件时会把解析时间拖长好几倍。第二大文件不要一次性把整个文件读成字符串再正则替换RTF解析本身字符串操作多内存占用大可以考虑用BufferedInputStream分块读但RTF结构有跨块控制字分块处理实现复杂所以我的建议是单文件超过10MB的RTF少见过真遇到大文件优先考虑Tika它对输入流做了更合理的处理。我在实际跑批时发现手写方案解析1000个平均50KB的RTF总耗时大约4秒Tika跑同样一批耗时大约9秒。但Tika处理格式怪异的文件基本不报错手写方案遇到一个不规范文件就可能抛异常中断整个批次。所以性能不是选型的第一指标稳定性才是。最后分享一个排查技巧如果你面对一个已经乱码的RTF别急着写代码先在十六进制工具里看几屏内容。乱码有规律——GBK字节被UTF-8解码显示成两个或三个奇怪的字符UTF-8被GBK解码显示成中文字符夹着大量个别生僻字。这两种有明显特征。记住一个判断技巧文本里出现“锟斤拷”这种毫无意义的中字组合基本可以断定UTF-8字节流被GBK解码了文本里出现大量\u数字但没有汉字说明转义层没处理。根据规律反推原始编码比瞎猜高效得多。这个内容后续还可以这样扩展解析RTF提取纯文本只是第一步如果再往里走还需要处理RTF转HTML、保留样式信息的结构化解析以及处理表格、嵌入图片等复杂元素。不同需求对“解析”的要求完全不同先搞清楚你到底是只要文本还是要保格式再决定用多重的方案。