尧图网站建设 
1. 从一次线上告警说起被“吃掉”的引号那天下午监控系统突然弹出一条告警提示某个核心服务的接口响应异常返回的JSON数据格式错误导致前端页面直接白屏。我立刻登录服务器查看日志发现错误信息非常典型com.alibaba.fastjson.JSONException: syntax error, expect {, actual string, pos 0。这通常意味着FastJson在解析一个期望是JSON对象以{开头的字符串时却遇到了一个普通字符串以开头。问题出在一个数据导出功能上。为了生成一份供下游系统消费的CSV格式数据文件我们先将一批包含复杂嵌套结构的Java对象列表用FastJson序列化成JSON字符串然后再对这个字符串进行一些处理比如替换分隔符。逻辑看起来很简单ListComplexData dataList fetchDataFromDB(); String jsonStr JSON.toJSONString(dataList); // 使用FastJson序列化 // 假设这里有一些针对jsonStr的字符串替换操作 String csvStr convertJsonToCustomFormat(jsonStr);然而正是这个JSON.toJSONString操作埋下了隐患。当ComplexData对象中某个字段的值本身就包含JSON格式的字符串时比如一个配置字段config的值为{\key\: \value\}注意这是一个字符串内容是一个JSON对象FastJson在序列化时会对这个字符串内部的引号进行转义。最终生成的jsonStr中这个字段的值会变成{\\key\\: \\value\\}。如果你再对这个字符串进行全局性的替换或二次处理很容易破坏这种转义结构导致最终字符串无法被正确解析。这其实就是标题中“两个转义”问题的冰山一角。在Java开发中尤其是使用FastJson这类高效但细节繁多的库时字符串转义是一个极易被忽视却又至关重要的话题。它不仅仅是多写一个反斜杠\那么简单而是涉及到字符在Java字符串字面量、JSON规范字符串以及序列化/反序列化过程这三个不同语境下的形态转换。理解不清就会在数据拼接、日志输出、接口传输等环节遭遇各种诡异的数据损坏或解析失败问题。2. 理解“两个转义”的本质三层语境下的字符旅行要彻底搞懂“两个转义”我们必须跳出代码从数据流动的视角来看。一个字符从被我们写入Java代码到最终成为网络传输或文件存储中的一个字节序列中间至少经历了三层语境每一层都有自己的转义规则。2.1 第一层Java字符串字面量中的转义当我们在Java源代码中写下String s {\name\: \Jack\};时这行代码首先要被Java编译器理解。在Java的语法里双引号是用来表示字符串开始的。为了在字符串内部表示一个真正的双引号字符而不是字符串的结束符我们必须使用反斜杠\进行转义写成\。所以对于Java编译器而言\被解析为一个双引号字符。\\被解析为一个反斜杠字符。\n被解析为一个换行符ASCII 10。\t被解析为一个制表符。在编译后这个字符串在JVM内存中的实际内容我们可以用s.toCharArray()或调试器查看就是{name: Jack}。注意内存里存的是一个个独立的字符\已经变成了一个双引号字符反斜杠\本身已经“消失”了。它只在源代码的语法层面起作用。2.2 第二层JSON规范中的字符串值转义JSON是一种独立于编程语言的数据交换格式。它的规范RFC 8259明确规定一个JSON字符串必须用双引号括起来例如Hello World。那么如果这个字符串内部包含双引号、反斜杠或控制字符怎么办JSON定义了自己的转义序列\表示双引号。\\表示反斜杠。\/表示正斜杠可转义也可不转义。\b表示退格。\f表示换页。\n表示换行。\r表示回车。\t表示制表。\uXXXX表示一个Unicode字符。所以一个合法的JSON文本例如{config: {\key\: \value\}}当它作为一个完整的文本文件或HTTP响应体存在时它里面的\是JSON语法的一部分用于表示字符串值内部的双引号。2.3 第三层序列化库FastJson的职责FastJson这样的库其核心工作就是在Java对象和符合JSON规范的文本之间进行转换。序列化toJSONString 输入是一个Java对象或Map、List等输出是一个符合JSON规范的字符串。如果对象某个字段是String类型且其值里包含JSON规范需要转义的字符如\ 换行符FastJson必须负责将这些字符转换成对应的JSON转义序列。反序列化parseObject 输入是一个符合JSON规范的字符串输出是一个Java对象。FastJson必须正确解析JSON转义序列将其还原为对应的Java字符。“两个转义”的冲突点就在这里 假设我们有一个Java对象class MyData { private String innerJson {\key\: \value\}; // Java字面量内存中为 {key: value} }当我们调用JSON.toJSONString(myData)时FastJson看到innerJson字段的值是一个字符串{key: value}。为了生成合法的JSON它需要将这个字符串作为值放入一个JSON字符串中。所以它必须对里面的双引号进行JSON转义。最终输出的JSON文本是{innerJson:{\key\: \value\}}注意看输出的文本里\出现了两次。这不是重复转义而是外层的\是JSON语法中键innerJson的值的开始和结束引号。内层的\是JSON语法中对字符串值{key: value}内部双引号的转义。如果此时我们错误地将这个JSON文本再次当作Java字符串字面量写回代码或者用字符串替换方法去操作它就很容易破坏这个结构。核心心法始终分清你当前操作的字符串处于哪一层语境。在Java代码中操作时关心的是Java转义将字符串作为JSON输出或解析时关心的是JSON转义。FastJson帮你处理了Java对象到JSON文本之间的转换但如果你手动拼接或修改了中间产物就必须自己维护转义的正确性。3. FastJson序列化中的转义行为深度剖析了解了三层语境我们再具体看FastJson在序列化时到底做了什么。这有助于我们预判结果避免踩坑。3.1 默认序列化JSON.toJSONString(Object object)这是最常用的方法。FastJson会遍历对象的所有属性通过getter方法或字段反射将它们转换为JSON对应的类型。对于String类型的字段值FastJson会将其内容视为一个普通的文本字符串并对其中的特殊字符进行JSON转义。public class EscapeDemo { public static void main(String[] args) { Data data new Data(); data.setNormalStr(Hello\nWorld); // 包含换行符 data.setJsonLikeStr({\name\: \Bob\}); // 类JSON字符串 data.setPathStr(C:\\Users\\test); // 包含反斜杠 String json JSON.toJSONString(data); System.out.println(json); // 输出 // {jsonLikeStr:{\name\: \Bob\},normalStr:Hello\nWorld,pathStr:C:\\Users\\test} } Data static class Data { private String normalStr; private String jsonLikeStr; private String pathStr; } }分析输出normalStr: Hello\nWorld- 输出为Hello\nWorld。FastJson将Java字符串中的换行符\n一个字符转换成了JSON转义序列\n两个字符反斜杠和n。jsonLikeStr: {\name\: \Bob\}- 输出为{\name\: \Bob\}。FastJson对字符串内部的每一个双引号都进行了JSON转义变成了\。pathStr: C:\\Users\\test- 输出为C:\\Users\\test。注意Java字面量中是\\表示一个反斜杠。FastJson对这一个反斜杠字符进行了JSON转义变成了\\。这个输出是一个合法的、标准的JSON文本。任何标准的JSON解析器都能正确解析它并将jsonLikeStr字段的值还原为字符串{name: Bob}。3.2 禁用转义SerializerFeature.WriteSlashAsSpecial的误区有时我们可能不希望FastJson对斜杠/进行转义虽然JSON规范中\/是合法的。FastJson提供了SerializerFeature.WriteSlashAsSpecial特性。但请注意这个特性名很容易误导它并不是“不转义斜杠”而是“将斜杠当作特殊字符处理”。在FastJson的默认行为中斜杠/是会被转义为\/的。设置这个特性后斜杠将不再被转义。String jsonWithSlash JSON.toJSONString(http://example.com); System.out.println(jsonWithSlash); // 输出http:\/\/example.com String jsonWithoutEscape JSON.toJSONString(http://example.com, SerializerFeature.WriteSlashAsSpecial); System.out.println(jsonWithoutEscape); // 输出http://example.com重要提示这个特性只针对斜杠。对于双引号、反斜杠\、控制字符等FastJson为了生成合法的JSON永远都会进行转义没有配置项可以全局关闭。这是由JSON规范决定的如果关闭产生的就不是合法JSON了。3.3 序列化“已经转义过的字符串”一个经典大坑这是“两个转义”问题最常引发故障的场景。考虑以下情况我们从某个外部接口或数据库拿到一个字符串这个字符串的内容已经是一个JSON格式的文本并且其中的特殊字符已经被转义过了。// 假设从外部获取的字符串其内容看起来像JSON且已转义 String externalJsonStr {\\\key\\\: \\\value\\\}; // 在Java内存中这个字符串实际上是{\key\: \value\} // 注意这里是三个反斜杠在Java字面量中\\\表示一个反斜杠字符 一个转义的双引号 MyWrapper wrapper new MyWrapper(); wrapper.setContent(externalJsonStr); String finalJson JSON.toJSONString(wrapper); System.out.println(finalJson);你期望的输出可能是{content:{\key\: \value\}}但实际的输出很可能是{content:{\\\key\\\: \\\value\\\}}或者更糟导致解析错误。为什么因为externalJsonStr在内存中已经是{\key\: \value\}。FastJson在序列化时看到这个字符串它忠实履行职责对字符串中的每一个反斜杠\和每一个双引号进行JSON转义。于是\被转义为\\被转义为\最终原本的\一个反斜杠一个双引号就变成了\\\两个反斜杠一个转义的双引号。这就造成了过度转义。避坑指南当你需要序列化的字符串内容本身可能就是JSON文本时务必先搞清楚这个字符串的“纯净度”。如果它已经是转义后的形式常见于经过多次序列化或字符串拼接的数据直接交给FastJson序列化会导致问题。一个安全的做法是在序列化前先尝试用JSON.parse()将它还原为Java对象如Map或JSONObject然后再序列化整个 wrapper 对象。这样FastJson会把它当作一个结构体来处理而不是一个需要二次转义的字符串。4. 反序列化如何正确还原被转义的数据序列化是把对象变成带转义的JSON字符串反序列化则是逆过程。FastJson在JSON.parseObject()时会自动处理JSON字符串中的转义序列将其还原为Java字符串中对应的字符。String jsonText {\path\:\C:\\\\Users\\\\test\, \message\:\Hello\\nWorld\}; MyData data JSON.parseObject(jsonText, MyData.class); System.out.println(data.getPath()); // 输出C:\Users\test System.out.println(data.getMessage()); // 输出Hello // World (换行)这个过程通常是透明且正确的。但问题往往出现在数据来源不可控时。例如前端传递过来的JSON字符串可能因为某些框架或浏览器的处理转义层数不对或者从文本文件读取的JSON其编码和转义可能有问题。4.1 处理非标准或损坏的JSON字符串有时你会遇到一些“脏数据”比如{data: {\name\: \test\}}这是标准的内层双引号被转义{data: {\name\: \test\}}这是错误的内层双引号只有一层转义但作为JSON字符串值它应该是\对于第二种情况直接使用JSON.parseObject()会抛出异常。你需要进行预处理。一个常见的方法是使用StringEscapeUtils来自Apache Commons Lang3库来统一处理转义import org.apache.commons.text.StringEscapeUtils; String dirtyJsonStr {\data\: \{\name\: \test\}\}; // 先尝试unescape去除一层JSON转义 String unescaped StringEscapeUtils.unescapeJson(dirtyJsonStr); // 此时 unescaped 可能是{data: {name: test}}这仍然不合法因为data的值内部还有未转义的双引号。 // 这说明数据本身已经损坏需要根据业务逻辑进行修复或丢弃。 // 更稳健的做法逐层解析 try { JSONObject root JSON.parseObject(dirtyJsonStr); String innerDataStr root.getString(data); // 尝试将 innerDataStr 作为JSON再次解析 JSONObject innerData JSON.parseObject(innerDataStr); // 成功则说明 innerDataStr 是合法的JSON字符串 } catch (Exception e) { // 解析失败进行清洗或记录错误 log.error(JSON解析失败原始字符串: {}, dirtyJsonStr, e); // 清洗逻辑例如用正则匹配并修复明显的转义错误风险高需谨慎 String cleaned dirtyJsonStr.replaceAll((?!\\\\)\, \\\\\); }注意正则修复是最后的手段极易引入新问题。最佳实践是在数据产生的源头确保JSON格式的正确性。4.2 针对“已转义字符串”字段的反序列化如果像第3.3节所述你序列化了一个“已经转义过的字符串”并得到了{content:{\\\key\\\: \\\value\\\}}这样的JSON。那么反序列化时FastJson会正确地将\\\还原为\一个反斜杠和一个双引号。所以getContent()得到的字符串在内存中会是{\key\: \value\}。如果你希望将它还原为原始的Map你需要对这个字符串再次进行JSON反序列化Wrapper wrapper JSON.parseObject(finalJson, Wrapper.class); String content wrapper.getContent(); // 内容为{\key\: \value\} // 这看起来像JSON但直接解析会失败因为双引号前有反斜杠 // 需要先理解这个字符串本身是“被转义过的JSON文本” Map map JSON.parseObject(content); // 错误会抛异常。 // 正确做法这个content字符串需要先被“解除转义” String unescapedContent StringEscapeUtils.unescapeJson(content); // 此时 unescapedContent 为{key: value} Map map JSON.parseObject(unescapedContent); // 成功这个过程清晰地展示了数据在不同形态间的循环Map - 转义JSON字符串 - 带双重转义的JSON字符串 - 转义JSON字符串 - Map。关键在于把握每个环节输入输出的数据形态。5. 实战场景与解决方案避开转义陷阱理论说再多不如看几个真实场景下的问题和解法。5.1 场景一日志输出中的JSON字符串在打印日志时我们经常想输出一个结构清晰的JSON。但如果直接打印FastJson序列化后的字符串在日志文件里看到的是转义后的字符不便于阅读。Data data ...; String json JSON.toJSONString(data); log.info(数据: {}, json); // 日志输出数据: {msg:Hello\nWorld,path:C:\\test} // \n 和 \\ 在日志文件里显示为原始字符不美观。 // 解决方案使用JSON.toJSONString的重载方法并指定格式化输出 String prettyJson JSON.toJSONString(data, SerializerFeature.PrettyFormat); log.info(数据:\n{}, prettyJson); // 日志输出 // 数据: // { // msg:Hello\nWorld, // path:C:\\test // } // 注意PrettyFormat只添加了缩进和换行字符串值内部的转义依然存在。 // 如果希望日志中显示真正的换行需要在序列化前就将字符串中的\n替换为换行符但这会破坏数据本身。更优方案对于日志调试可以考虑使用JSON.toJSONString(data, SerializerFeature.PrettyFormat, SerializerFeature.WriteSlashAsSpecial)来让路径看起来更顺眼同时接受字符串内部的\n在日志中显示为\n字符。或者直接使用Java对象toString()方法如果它格式清晰的话。5.2 场景二构建包含JSON字符串的复杂JSON有时我们需要构建一个JSON其某个字段的值是另一个JSON字符串。手动拼接极易出错。// 目标生成 {meta:{}, data:{\id\:1}} MapString, Object complex new HashMap(); complex.put(meta, new HashMap()); // 错误做法手动拼接字符串 String innerJsonWrong {\id\:1}; // Java内存中: {id:1} complex.put(data, innerJsonWrong); String resultWrong JSON.toJSONString(complex); System.out.println(resultWrong); // 输出{data:{\id\:1},meta:{}} 正确不这里data的值是字符串{id:1}不是转义后的。 // 仔细看输出是{data:{id:1},meta:{}} // 这根本不是合法JSON因为data的值内部的双引号没有被转义。 // 正确做法让FastJson来转义 // 方法1使用JSONObject JSONObject innerJsonObj new JSONObject(); innerJsonObj.put(id, 1); complex.put(data, innerJsonObj.toJSONString()); // 注意这里toJSONString()返回的是已转义的字符串{\id\:1} String result1 JSON.toJSONString(complex); System.out.println(result1); // 输出{data:{\id\:1},meta:{}} 正确 // 方法2先序列化内层对象得到的字符串就是已转义的 String innerJsonStr JSON.toJSONString(Collections.singletonMap(id, 1)); complex.put(data, innerJsonStr); String result2 JSON.toJSONString(complex); System.out.println(result2); // 输出同上正确。核心要点当需要将一个JSON结构作为另一个JSON的字符串值时必须确保这个内层JSON结构已经被序列化成字符串即完成了JSON转义然后再作为外层对象的字符串字段值。绝对不要将一个未转义的、类似{id:1}的字符串直接放进去。5.3 场景三与前端交互时的XSS过滤与转义这是一个安全相关的高频问题。为了防止跨站脚本攻击XSS后端接口返回的JSON数据中如果字符串值包含HTML特殊字符如,,有时会被自动转义为HTML实体如,,。// 假设一个用户输入了 scriptalert(xss)/script Data data new Data(); data.setContent(scriptalert(xss)/script); // 如果后端框架如Spring Boot配合某些安全模块开启了全局XSS过滤 // 直接返回这个对象响应的JSON可能变成 // {content:lt;scriptgt;alert(#39;xss#39;)lt;/scriptgt;} // 这是HTML实体的转义不是JSON转义。前端拿到这个数据如果直接使用JSON.parse()会得到一个包含HTML实体字符的字符串而不是原始字符。前端需要自己进行HTML解码。或者后端需要关闭对JSON响应的全局HTML转义改为在渲染到HTML页面时再对特定字段进行转义。解决方案明确责任边界JSON是数据交换格式其转义应遵循JSON规范。HTML/XML转义是展示层的事情。尽量不要在JSON层做HTML转义。检查Web框架配置例如在Spring Boot中检查是否有类似spring.http.encoding.force、spring.security.xss.enabled等配置或者自定义的HttpMessageConverter、Filter在干预响应内容。针对性处理如果确实需要在JSON中返回已转义HTML的内容请使用专门的工具库如org.springframework.web.util.HtmlUtils.htmlEscape进行转义并告知前端此字段需要特殊处理。5.4 场景四处理包含换行符、制表符的文本当JSON字符串值包含多行文本时比如用户提交的一段文章换行符\n会被FastJson正确转义。但问题在于某些下游系统如老旧的系统或某些特定格式解析器可能无法识别JSON转义序列\n它们要求字符串中是真实的换行符ASCII 10。// 需求生成一个JSON其text字段的值需要包含真实换行符以便另一个系统直接读取该字段值写入文本文件。 // 但直接序列化得到的JSON中是转义序列\n。 Data data new Data(); data.setText(Line1\nLine2); String json JSON.toJSONString(data); // {text:Line1\nLine2} // 如果另一个系统直接提取Line1\nLine2这个字符串包含反斜杠和n字符写入文件文件内容将是“Line1\nLine2”而不是两行。解决方案这本质上是一个协议约定问题。双方必须明确数据交换的格式。方案A推荐约定使用标准JSON下游系统在解析JSON后需要自行处理字符串中的JSON转义序列将其转换为真实字符。几乎所有现代JSON库都自动完成此步骤。方案B如果下游系统确实无法处理一个妥协的办法是在序列化前先将特殊字符替换为占位符传输后再由下游系统替换回来。但这破坏了标准性不推荐。// 不推荐的妥协方案示例 String rawText Line1\nLine2\tTab; String placeholderText rawText.replace(\n, [NEWLINE]).replace(\t, [TAB]); data.setText(placeholderText); // 下游系统拿到后再反向替换。6. 性能与内存转义带来的隐藏成本转义操作不是免费的。在序列化大量字符串数据尤其是字符串内容本身包含大量需要转义的字符如反斜杠、双引号时会带来额外的性能开销和内存占用。6.1 字符串创建与复制FastJson在序列化一个字符串时需要遍历其中的每个字符判断是否需要转义。如果需要它必须构建一个新的字符串StringBuilder或char[]来容纳转义后的结果。对于长字符串这个操作可能比较耗时。// 模拟一个极端情况字符串全是双引号 String quotes \\\\\\; // 6个双引号 // FastJson序列化时需要将其转换为\\\\\\长度变为12。在高压力的序列化场景下如日志采集、数据导出如果被序列化的对象中大量字符串字段都包含需要转义的字符累积的开销不容忽视。6.2 内存占用翻倍风险考虑第3.3节的过度转义场景一个已经转义过的JSON字符串{\key\: \value\}长度假设为L被再次序列化后可能变成{\\\key\\\: \\\value\\\}长度约为2L。如果这种数据在内存中缓存或在网络中传输会造成显著的资源浪费。优化建议审视数据设计如果一个字段的值总是一个JSON结构考虑将其设计为嵌套的对象或Map而不是一个字符串。让FastJson直接处理结构避免字符串形式的嵌套和重复转义。避免不必要的序列化只在需要将数据输出为文本如写入文件、发送网络请求时才进行序列化。在程序内部传递数据时尽量使用Java对象本身。使用更高效的序列化方式如果JSON字符串的生成是性能瓶颈可以考虑使用JSON.toJSONBytes()直接生成字节数组或者使用JSON.writeJSONString(Writer, ...)写入流避免创建巨大的中间字符串。关注toJSONString()的重载方法toJSONString(Object object, SerializerFeature... features)允许你传入特性来微调行为。例如对于不需要严格JSON兼容性的内部场景可以结合禁用斜杠转义等特性。但切记改变标准特性可能影响与其他系统的交互。7. 替代方案与最佳实践总结FastJson虽然快但因其历史漏洞和某些默认行为如自动类型推断在一些对安全性要求高的项目中逐渐被替换。了解其他库的转义行为也是有必要的。7.1 Jackson与Gson的转义行为Jackson(Spring Boot默认)行为与FastJson基本一致在生成JSON时会对字符串中的特殊字符进行转义。Jackson提供了JsonGenerator的FEATURE_ESCAPE_NON_ASCII等特性来控制转义范围。Gson行为类似。Gson在默认情况下也会进行JSON转义。它可以通过JsonWriter的setHtmlSafe等方法来影响转义行为如不对HTML字符进行额外转义。核心一致点所有主流的JSON库为了输出符合RFC标准的JSON都会对字符串值中的JSON特殊字符进行转义。这是库的基本职责没有商量的余地。7.2 贯穿开发流程的最佳实践清单设计阶段明确数据边界区分“作为数据的字符串”和“作为代码JSON/XML的字符串”。后者应尽量用对象结构表示。定义接口契约与上下游系统明确约定JSON格式标准避免出现非标准转义或混合转义的需求。编码阶段信任你的序列化库99%的情况下不要手动拼接JSON字符串。使用JSONObject/JSONArray或Map/List来构建结构然后交给库去序列化。谨慎处理“字符串的字符串”对于字段值可能是JSON字符串的情况在存储或传输前明确其状态是原始JSON文本还是已转义的JSON字符串。入库或发送前最好将其统一序列化一次。善用工具验证使用在线的JSON验证工具如 jsonlint.com或IDE插件经常验证你生成的JSON字符串是否合法。肉眼检查转义很容易出错。调试与排查阶段使用格式化输出调试时始终使用SerializerFeature.PrettyFormat来查看JSON结构这比压缩的一行字符串清晰得多。查看内存中的真实字符串在IDE调试器中使用“查看文本”或“复制值”功能获取变量在内存中的真实内容区分Java字符串和打印输出的表现。二分法定位当遇到JSON解析错误时尝试将出错的JSON字符串分段分别解析定位到具体是哪个字段的值导致了问题。安全与性能转义与安全各司其职JSON转义是为了语法正确HTML转义是为了防止XSS。不要在JSON层做HTML转义也不要在HTML层忽略JSON转义。关注序列化性能在性能敏感的场景对包含大量需要转义字符的大字符串进行序列化要进行性能测试和评估。回到文章开头那个线上问题最终的修复方案是在数据导出模块中我们不再将整个对象列表序列化成一个大JSON字符串后再处理。而是改为流式处理逐条将Java对象转换为目标格式CSV的字段直接写入输出流完全绕开了“JSON字符串嵌套并二次转义”这个陷阱。这再次印证了一个道理许多复杂问题的解决方案往往在于重新审视和简化整个流程而不是在复杂的细节里挣扎。理解“两个转义”就是为了在关键时刻能做出这样的简化设计。 FastJson转义机制解析：三层语境下的JSON序列化与反序列化
1. 从一次线上告警说起被“吃掉”的引号那天下午监控系统突然弹出一条告警提示某个核心服务的接口响应异常返回的JSON数据格式错误导致前端页面直接白屏。我立刻登录服务器查看日志发现错误信息非常典型com.alibaba.fastjson.JSONException: syntax error, expect {, actual string, pos 0。这通常意味着FastJson在解析一个期望是JSON对象以{开头的字符串时却遇到了一个普通字符串以开头。问题出在一个数据导出功能上。为了生成一份供下游系统消费的CSV格式数据文件我们先将一批包含复杂嵌套结构的Java对象列表用FastJson序列化成JSON字符串然后再对这个字符串进行一些处理比如替换分隔符。逻辑看起来很简单ListComplexData dataList fetchDataFromDB(); String jsonStr JSON.toJSONString(dataList); // 使用FastJson序列化 // 假设这里有一些针对jsonStr的字符串替换操作 String csvStr convertJsonToCustomFormat(jsonStr);然而正是这个JSON.toJSONString操作埋下了隐患。当ComplexData对象中某个字段的值本身就包含JSON格式的字符串时比如一个配置字段config的值为{\key\: \value\}注意这是一个字符串内容是一个JSON对象FastJson在序列化时会对这个字符串内部的引号进行转义。最终生成的jsonStr中这个字段的值会变成{\\key\\: \\value\\}。如果你再对这个字符串进行全局性的替换或二次处理很容易破坏这种转义结构导致最终字符串无法被正确解析。这其实就是标题中“两个转义”问题的冰山一角。在Java开发中尤其是使用FastJson这类高效但细节繁多的库时字符串转义是一个极易被忽视却又至关重要的话题。它不仅仅是多写一个反斜杠\那么简单而是涉及到字符在Java字符串字面量、JSON规范字符串以及序列化/反序列化过程这三个不同语境下的形态转换。理解不清就会在数据拼接、日志输出、接口传输等环节遭遇各种诡异的数据损坏或解析失败问题。2. 理解“两个转义”的本质三层语境下的字符旅行要彻底搞懂“两个转义”我们必须跳出代码从数据流动的视角来看。一个字符从被我们写入Java代码到最终成为网络传输或文件存储中的一个字节序列中间至少经历了三层语境每一层都有自己的转义规则。2.1 第一层Java字符串字面量中的转义当我们在Java源代码中写下String s {\name\: \Jack\};时这行代码首先要被Java编译器理解。在Java的语法里双引号是用来表示字符串开始的。为了在字符串内部表示一个真正的双引号字符而不是字符串的结束符我们必须使用反斜杠\进行转义写成\。所以对于Java编译器而言\被解析为一个双引号字符。\\被解析为一个反斜杠字符。\n被解析为一个换行符ASCII 10。\t被解析为一个制表符。在编译后这个字符串在JVM内存中的实际内容我们可以用s.toCharArray()或调试器查看就是{name: Jack}。注意内存里存的是一个个独立的字符\已经变成了一个双引号字符反斜杠\本身已经“消失”了。它只在源代码的语法层面起作用。2.2 第二层JSON规范中的字符串值转义JSON是一种独立于编程语言的数据交换格式。它的规范RFC 8259明确规定一个JSON字符串必须用双引号括起来例如Hello World。那么如果这个字符串内部包含双引号、反斜杠或控制字符怎么办JSON定义了自己的转义序列\表示双引号。\\表示反斜杠。\/表示正斜杠可转义也可不转义。\b表示退格。\f表示换页。\n表示换行。\r表示回车。\t表示制表。\uXXXX表示一个Unicode字符。所以一个合法的JSON文本例如{config: {\key\: \value\}}当它作为一个完整的文本文件或HTTP响应体存在时它里面的\是JSON语法的一部分用于表示字符串值内部的双引号。2.3 第三层序列化库FastJson的职责FastJson这样的库其核心工作就是在Java对象和符合JSON规范的文本之间进行转换。序列化toJSONString 输入是一个Java对象或Map、List等输出是一个符合JSON规范的字符串。如果对象某个字段是String类型且其值里包含JSON规范需要转义的字符如\ 换行符FastJson必须负责将这些字符转换成对应的JSON转义序列。反序列化parseObject 输入是一个符合JSON规范的字符串输出是一个Java对象。FastJson必须正确解析JSON转义序列将其还原为对应的Java字符。“两个转义”的冲突点就在这里 假设我们有一个Java对象class MyData { private String innerJson {\key\: \value\}; // Java字面量内存中为 {key: value} }当我们调用JSON.toJSONString(myData)时FastJson看到innerJson字段的值是一个字符串{key: value}。为了生成合法的JSON它需要将这个字符串作为值放入一个JSON字符串中。所以它必须对里面的双引号进行JSON转义。最终输出的JSON文本是{innerJson:{\key\: \value\}}注意看输出的文本里\出现了两次。这不是重复转义而是外层的\是JSON语法中键innerJson的值的开始和结束引号。内层的\是JSON语法中对字符串值{key: value}内部双引号的转义。如果此时我们错误地将这个JSON文本再次当作Java字符串字面量写回代码或者用字符串替换方法去操作它就很容易破坏这个结构。核心心法始终分清你当前操作的字符串处于哪一层语境。在Java代码中操作时关心的是Java转义将字符串作为JSON输出或解析时关心的是JSON转义。FastJson帮你处理了Java对象到JSON文本之间的转换但如果你手动拼接或修改了中间产物就必须自己维护转义的正确性。3. FastJson序列化中的转义行为深度剖析了解了三层语境我们再具体看FastJson在序列化时到底做了什么。这有助于我们预判结果避免踩坑。3.1 默认序列化JSON.toJSONString(Object object)这是最常用的方法。FastJson会遍历对象的所有属性通过getter方法或字段反射将它们转换为JSON对应的类型。对于String类型的字段值FastJson会将其内容视为一个普通的文本字符串并对其中的特殊字符进行JSON转义。public class EscapeDemo { public static void main(String[] args) { Data data new Data(); data.setNormalStr(Hello\nWorld); // 包含换行符 data.setJsonLikeStr({\name\: \Bob\}); // 类JSON字符串 data.setPathStr(C:\\Users\\test); // 包含反斜杠 String json JSON.toJSONString(data); System.out.println(json); // 输出 // {jsonLikeStr:{\name\: \Bob\},normalStr:Hello\nWorld,pathStr:C:\\Users\\test} } Data static class Data { private String normalStr; private String jsonLikeStr; private String pathStr; } }分析输出normalStr: Hello\nWorld- 输出为Hello\nWorld。FastJson将Java字符串中的换行符\n一个字符转换成了JSON转义序列\n两个字符反斜杠和n。jsonLikeStr: {\name\: \Bob\}- 输出为{\name\: \Bob\}。FastJson对字符串内部的每一个双引号都进行了JSON转义变成了\。pathStr: C:\\Users\\test- 输出为C:\\Users\\test。注意Java字面量中是\\表示一个反斜杠。FastJson对这一个反斜杠字符进行了JSON转义变成了\\。这个输出是一个合法的、标准的JSON文本。任何标准的JSON解析器都能正确解析它并将jsonLikeStr字段的值还原为字符串{name: Bob}。3.2 禁用转义SerializerFeature.WriteSlashAsSpecial的误区有时我们可能不希望FastJson对斜杠/进行转义虽然JSON规范中\/是合法的。FastJson提供了SerializerFeature.WriteSlashAsSpecial特性。但请注意这个特性名很容易误导它并不是“不转义斜杠”而是“将斜杠当作特殊字符处理”。在FastJson的默认行为中斜杠/是会被转义为\/的。设置这个特性后斜杠将不再被转义。String jsonWithSlash JSON.toJSONString(http://example.com); System.out.println(jsonWithSlash); // 输出http:\/\/example.com String jsonWithoutEscape JSON.toJSONString(http://example.com, SerializerFeature.WriteSlashAsSpecial); System.out.println(jsonWithoutEscape); // 输出http://example.com重要提示这个特性只针对斜杠。对于双引号、反斜杠\、控制字符等FastJson为了生成合法的JSON永远都会进行转义没有配置项可以全局关闭。这是由JSON规范决定的如果关闭产生的就不是合法JSON了。3.3 序列化“已经转义过的字符串”一个经典大坑这是“两个转义”问题最常引发故障的场景。考虑以下情况我们从某个外部接口或数据库拿到一个字符串这个字符串的内容已经是一个JSON格式的文本并且其中的特殊字符已经被转义过了。// 假设从外部获取的字符串其内容看起来像JSON且已转义 String externalJsonStr {\\\key\\\: \\\value\\\}; // 在Java内存中这个字符串实际上是{\key\: \value\} // 注意这里是三个反斜杠在Java字面量中\\\表示一个反斜杠字符 一个转义的双引号 MyWrapper wrapper new MyWrapper(); wrapper.setContent(externalJsonStr); String finalJson JSON.toJSONString(wrapper); System.out.println(finalJson);你期望的输出可能是{content:{\key\: \value\}}但实际的输出很可能是{content:{\\\key\\\: \\\value\\\}}或者更糟导致解析错误。为什么因为externalJsonStr在内存中已经是{\key\: \value\}。FastJson在序列化时看到这个字符串它忠实履行职责对字符串中的每一个反斜杠\和每一个双引号进行JSON转义。于是\被转义为\\被转义为\最终原本的\一个反斜杠一个双引号就变成了\\\两个反斜杠一个转义的双引号。这就造成了过度转义。避坑指南当你需要序列化的字符串内容本身可能就是JSON文本时务必先搞清楚这个字符串的“纯净度”。如果它已经是转义后的形式常见于经过多次序列化或字符串拼接的数据直接交给FastJson序列化会导致问题。一个安全的做法是在序列化前先尝试用JSON.parse()将它还原为Java对象如Map或JSONObject然后再序列化整个 wrapper 对象。这样FastJson会把它当作一个结构体来处理而不是一个需要二次转义的字符串。4. 反序列化如何正确还原被转义的数据序列化是把对象变成带转义的JSON字符串反序列化则是逆过程。FastJson在JSON.parseObject()时会自动处理JSON字符串中的转义序列将其还原为Java字符串中对应的字符。String jsonText {\path\:\C:\\\\Users\\\\test\, \message\:\Hello\\nWorld\}; MyData data JSON.parseObject(jsonText, MyData.class); System.out.println(data.getPath()); // 输出C:\Users\test System.out.println(data.getMessage()); // 输出Hello // World (换行)这个过程通常是透明且正确的。但问题往往出现在数据来源不可控时。例如前端传递过来的JSON字符串可能因为某些框架或浏览器的处理转义层数不对或者从文本文件读取的JSON其编码和转义可能有问题。4.1 处理非标准或损坏的JSON字符串有时你会遇到一些“脏数据”比如{data: {\name\: \test\}}这是标准的内层双引号被转义{data: {\name\: \test\}}这是错误的内层双引号只有一层转义但作为JSON字符串值它应该是\对于第二种情况直接使用JSON.parseObject()会抛出异常。你需要进行预处理。一个常见的方法是使用StringEscapeUtils来自Apache Commons Lang3库来统一处理转义import org.apache.commons.text.StringEscapeUtils; String dirtyJsonStr {\data\: \{\name\: \test\}\}; // 先尝试unescape去除一层JSON转义 String unescaped StringEscapeUtils.unescapeJson(dirtyJsonStr); // 此时 unescaped 可能是{data: {name: test}}这仍然不合法因为data的值内部还有未转义的双引号。 // 这说明数据本身已经损坏需要根据业务逻辑进行修复或丢弃。 // 更稳健的做法逐层解析 try { JSONObject root JSON.parseObject(dirtyJsonStr); String innerDataStr root.getString(data); // 尝试将 innerDataStr 作为JSON再次解析 JSONObject innerData JSON.parseObject(innerDataStr); // 成功则说明 innerDataStr 是合法的JSON字符串 } catch (Exception e) { // 解析失败进行清洗或记录错误 log.error(JSON解析失败原始字符串: {}, dirtyJsonStr, e); // 清洗逻辑例如用正则匹配并修复明显的转义错误风险高需谨慎 String cleaned dirtyJsonStr.replaceAll((?!\\\\)\, \\\\\); }注意正则修复是最后的手段极易引入新问题。最佳实践是在数据产生的源头确保JSON格式的正确性。4.2 针对“已转义字符串”字段的反序列化如果像第3.3节所述你序列化了一个“已经转义过的字符串”并得到了{content:{\\\key\\\: \\\value\\\}}这样的JSON。那么反序列化时FastJson会正确地将\\\还原为\一个反斜杠和一个双引号。所以getContent()得到的字符串在内存中会是{\key\: \value\}。如果你希望将它还原为原始的Map你需要对这个字符串再次进行JSON反序列化Wrapper wrapper JSON.parseObject(finalJson, Wrapper.class); String content wrapper.getContent(); // 内容为{\key\: \value\} // 这看起来像JSON但直接解析会失败因为双引号前有反斜杠 // 需要先理解这个字符串本身是“被转义过的JSON文本” Map map JSON.parseObject(content); // 错误会抛异常。 // 正确做法这个content字符串需要先被“解除转义” String unescapedContent StringEscapeUtils.unescapeJson(content); // 此时 unescapedContent 为{key: value} Map map JSON.parseObject(unescapedContent); // 成功这个过程清晰地展示了数据在不同形态间的循环Map - 转义JSON字符串 - 带双重转义的JSON字符串 - 转义JSON字符串 - Map。关键在于把握每个环节输入输出的数据形态。5. 实战场景与解决方案避开转义陷阱理论说再多不如看几个真实场景下的问题和解法。5.1 场景一日志输出中的JSON字符串在打印日志时我们经常想输出一个结构清晰的JSON。但如果直接打印FastJson序列化后的字符串在日志文件里看到的是转义后的字符不便于阅读。Data data ...; String json JSON.toJSONString(data); log.info(数据: {}, json); // 日志输出数据: {msg:Hello\nWorld,path:C:\\test} // \n 和 \\ 在日志文件里显示为原始字符不美观。 // 解决方案使用JSON.toJSONString的重载方法并指定格式化输出 String prettyJson JSON.toJSONString(data, SerializerFeature.PrettyFormat); log.info(数据:\n{}, prettyJson); // 日志输出 // 数据: // { // msg:Hello\nWorld, // path:C:\\test // } // 注意PrettyFormat只添加了缩进和换行字符串值内部的转义依然存在。 // 如果希望日志中显示真正的换行需要在序列化前就将字符串中的\n替换为换行符但这会破坏数据本身。更优方案对于日志调试可以考虑使用JSON.toJSONString(data, SerializerFeature.PrettyFormat, SerializerFeature.WriteSlashAsSpecial)来让路径看起来更顺眼同时接受字符串内部的\n在日志中显示为\n字符。或者直接使用Java对象toString()方法如果它格式清晰的话。5.2 场景二构建包含JSON字符串的复杂JSON有时我们需要构建一个JSON其某个字段的值是另一个JSON字符串。手动拼接极易出错。// 目标生成 {meta:{}, data:{\id\:1}} MapString, Object complex new HashMap(); complex.put(meta, new HashMap()); // 错误做法手动拼接字符串 String innerJsonWrong {\id\:1}; // Java内存中: {id:1} complex.put(data, innerJsonWrong); String resultWrong JSON.toJSONString(complex); System.out.println(resultWrong); // 输出{data:{\id\:1},meta:{}} 正确不这里data的值是字符串{id:1}不是转义后的。 // 仔细看输出是{data:{id:1},meta:{}} // 这根本不是合法JSON因为data的值内部的双引号没有被转义。 // 正确做法让FastJson来转义 // 方法1使用JSONObject JSONObject innerJsonObj new JSONObject(); innerJsonObj.put(id, 1); complex.put(data, innerJsonObj.toJSONString()); // 注意这里toJSONString()返回的是已转义的字符串{\id\:1} String result1 JSON.toJSONString(complex); System.out.println(result1); // 输出{data:{\id\:1},meta:{}} 正确 // 方法2先序列化内层对象得到的字符串就是已转义的 String innerJsonStr JSON.toJSONString(Collections.singletonMap(id, 1)); complex.put(data, innerJsonStr); String result2 JSON.toJSONString(complex); System.out.println(result2); // 输出同上正确。核心要点当需要将一个JSON结构作为另一个JSON的字符串值时必须确保这个内层JSON结构已经被序列化成字符串即完成了JSON转义然后再作为外层对象的字符串字段值。绝对不要将一个未转义的、类似{id:1}的字符串直接放进去。5.3 场景三与前端交互时的XSS过滤与转义这是一个安全相关的高频问题。为了防止跨站脚本攻击XSS后端接口返回的JSON数据中如果字符串值包含HTML特殊字符如,,有时会被自动转义为HTML实体如,,。// 假设一个用户输入了 scriptalert(xss)/script Data data new Data(); data.setContent(scriptalert(xss)/script); // 如果后端框架如Spring Boot配合某些安全模块开启了全局XSS过滤 // 直接返回这个对象响应的JSON可能变成 // {content:lt;scriptgt;alert(#39;xss#39;)lt;/scriptgt;} // 这是HTML实体的转义不是JSON转义。前端拿到这个数据如果直接使用JSON.parse()会得到一个包含HTML实体字符的字符串而不是原始字符。前端需要自己进行HTML解码。或者后端需要关闭对JSON响应的全局HTML转义改为在渲染到HTML页面时再对特定字段进行转义。解决方案明确责任边界JSON是数据交换格式其转义应遵循JSON规范。HTML/XML转义是展示层的事情。尽量不要在JSON层做HTML转义。检查Web框架配置例如在Spring Boot中检查是否有类似spring.http.encoding.force、spring.security.xss.enabled等配置或者自定义的HttpMessageConverter、Filter在干预响应内容。针对性处理如果确实需要在JSON中返回已转义HTML的内容请使用专门的工具库如org.springframework.web.util.HtmlUtils.htmlEscape进行转义并告知前端此字段需要特殊处理。5.4 场景四处理包含换行符、制表符的文本当JSON字符串值包含多行文本时比如用户提交的一段文章换行符\n会被FastJson正确转义。但问题在于某些下游系统如老旧的系统或某些特定格式解析器可能无法识别JSON转义序列\n它们要求字符串中是真实的换行符ASCII 10。// 需求生成一个JSON其text字段的值需要包含真实换行符以便另一个系统直接读取该字段值写入文本文件。 // 但直接序列化得到的JSON中是转义序列\n。 Data data new Data(); data.setText(Line1\nLine2); String json JSON.toJSONString(data); // {text:Line1\nLine2} // 如果另一个系统直接提取Line1\nLine2这个字符串包含反斜杠和n字符写入文件文件内容将是“Line1\nLine2”而不是两行。解决方案这本质上是一个协议约定问题。双方必须明确数据交换的格式。方案A推荐约定使用标准JSON下游系统在解析JSON后需要自行处理字符串中的JSON转义序列将其转换为真实字符。几乎所有现代JSON库都自动完成此步骤。方案B如果下游系统确实无法处理一个妥协的办法是在序列化前先将特殊字符替换为占位符传输后再由下游系统替换回来。但这破坏了标准性不推荐。// 不推荐的妥协方案示例 String rawText Line1\nLine2\tTab; String placeholderText rawText.replace(\n, [NEWLINE]).replace(\t, [TAB]); data.setText(placeholderText); // 下游系统拿到后再反向替换。6. 性能与内存转义带来的隐藏成本转义操作不是免费的。在序列化大量字符串数据尤其是字符串内容本身包含大量需要转义的字符如反斜杠、双引号时会带来额外的性能开销和内存占用。6.1 字符串创建与复制FastJson在序列化一个字符串时需要遍历其中的每个字符判断是否需要转义。如果需要它必须构建一个新的字符串StringBuilder或char[]来容纳转义后的结果。对于长字符串这个操作可能比较耗时。// 模拟一个极端情况字符串全是双引号 String quotes \\\\\\; // 6个双引号 // FastJson序列化时需要将其转换为\\\\\\长度变为12。在高压力的序列化场景下如日志采集、数据导出如果被序列化的对象中大量字符串字段都包含需要转义的字符累积的开销不容忽视。6.2 内存占用翻倍风险考虑第3.3节的过度转义场景一个已经转义过的JSON字符串{\key\: \value\}长度假设为L被再次序列化后可能变成{\\\key\\\: \\\value\\\}长度约为2L。如果这种数据在内存中缓存或在网络中传输会造成显著的资源浪费。优化建议审视数据设计如果一个字段的值总是一个JSON结构考虑将其设计为嵌套的对象或Map而不是一个字符串。让FastJson直接处理结构避免字符串形式的嵌套和重复转义。避免不必要的序列化只在需要将数据输出为文本如写入文件、发送网络请求时才进行序列化。在程序内部传递数据时尽量使用Java对象本身。使用更高效的序列化方式如果JSON字符串的生成是性能瓶颈可以考虑使用JSON.toJSONBytes()直接生成字节数组或者使用JSON.writeJSONString(Writer, ...)写入流避免创建巨大的中间字符串。关注toJSONString()的重载方法toJSONString(Object object, SerializerFeature... features)允许你传入特性来微调行为。例如对于不需要严格JSON兼容性的内部场景可以结合禁用斜杠转义等特性。但切记改变标准特性可能影响与其他系统的交互。7. 替代方案与最佳实践总结FastJson虽然快但因其历史漏洞和某些默认行为如自动类型推断在一些对安全性要求高的项目中逐渐被替换。了解其他库的转义行为也是有必要的。7.1 Jackson与Gson的转义行为Jackson(Spring Boot默认)行为与FastJson基本一致在生成JSON时会对字符串中的特殊字符进行转义。Jackson提供了JsonGenerator的FEATURE_ESCAPE_NON_ASCII等特性来控制转义范围。Gson行为类似。Gson在默认情况下也会进行JSON转义。它可以通过JsonWriter的setHtmlSafe等方法来影响转义行为如不对HTML字符进行额外转义。核心一致点所有主流的JSON库为了输出符合RFC标准的JSON都会对字符串值中的JSON特殊字符进行转义。这是库的基本职责没有商量的余地。7.2 贯穿开发流程的最佳实践清单设计阶段明确数据边界区分“作为数据的字符串”和“作为代码JSON/XML的字符串”。后者应尽量用对象结构表示。定义接口契约与上下游系统明确约定JSON格式标准避免出现非标准转义或混合转义的需求。编码阶段信任你的序列化库99%的情况下不要手动拼接JSON字符串。使用JSONObject/JSONArray或Map/List来构建结构然后交给库去序列化。谨慎处理“字符串的字符串”对于字段值可能是JSON字符串的情况在存储或传输前明确其状态是原始JSON文本还是已转义的JSON字符串。入库或发送前最好将其统一序列化一次。善用工具验证使用在线的JSON验证工具如 jsonlint.com或IDE插件经常验证你生成的JSON字符串是否合法。肉眼检查转义很容易出错。调试与排查阶段使用格式化输出调试时始终使用SerializerFeature.PrettyFormat来查看JSON结构这比压缩的一行字符串清晰得多。查看内存中的真实字符串在IDE调试器中使用“查看文本”或“复制值”功能获取变量在内存中的真实内容区分Java字符串和打印输出的表现。二分法定位当遇到JSON解析错误时尝试将出错的JSON字符串分段分别解析定位到具体是哪个字段的值导致了问题。安全与性能转义与安全各司其职JSON转义是为了语法正确HTML转义是为了防止XSS。不要在JSON层做HTML转义也不要在HTML层忽略JSON转义。关注序列化性能在性能敏感的场景对包含大量需要转义字符的大字符串进行序列化要进行性能测试和评估。回到文章开头那个线上问题最终的修复方案是在数据导出模块中我们不再将整个对象列表序列化成一个大JSON字符串后再处理。而是改为流式处理逐条将Java对象转换为目标格式CSV的字段直接写入输出流完全绕开了“JSON字符串嵌套并二次转义”这个陷阱。这再次印证了一个道理许多复杂问题的解决方案往往在于重新审视和简化整个流程而不是在复杂的细节里挣扎。理解“两个转义”就是为了在关键时刻能做出这样的简化设计。