Mule 3 DW1.0应用中未转义HTML作为JSON属性值使用时触发<字符格式异常

核心异常根因 #

你碰到的<字符格式报错，根本不是输出环节的转义问题，是类型声明和实际内容不匹配导致的入参解析环节直接失败：

• Parse Template组件本身的输出是模板渲染后的纯文本，但你把它的输出MIME类型设成了application/json，Mule消息管线会按照声明的类型，自动对流转的内容做反序列化处理
• 纯HTML内容没有JSON要求的键值对结构，JSON解析器碰到内容首字符是<的时候，会直接判定为非法JSON格式抛错，整个流程直接中断——你在Transform Message组件里写的强制转字符串、结构转换的逻辑根本没机会执行，这也是你之前试了好几种字符串转换方案都没用的核心原因。

可落地实现路径 #

方案1：从根源修正Parse Template配置（最优解） #

• 打开Parse Template组件的配置面板，把输出MIME类型从application/json改成text/plain
• 改完之后，组件渲染出来的HTML内容会被直接作为纯字符串传递，完全绕开JSON解析器的格式校验，不会再触发<字符的报错
• 此时你原来写的那段DataWeave逻辑可以直接正常运行：

  %dw 1.0
  %output application/json
  ---
  {
     "body": payload
  }
  

• 注意：DataWeave输出application/json格式时，会自动按JSON规范对HTML里的特殊字符（<、>、双引号等）做转义，完全不需要手动处理转义逻辑。

方案2：没法修改Parse Template配置时的绕开方法 #

如果因为全局配置限制，动不了Parse Template的输出类型，就在Parse Template和目标Transform Message中间加一个Set Payload组件，强制绕过自动JSON反序列化：

• Set Payload的表达式直接写：#[org.apache.commons.io.IOUtils.toString(payload, "UTF-8")]
• 同时把这个Set Payload的输出MIME类型显式设成text/plain
• 这一步的作用是直接把渲染好的HTML原始字节读成字符串，完全跳过之前因为application/json类型声明触发的自动解析流程，从根上避开格式校验报错
• 进了Transform Message之后，原来的DataWeave逻辑就可以正常处理了，不需要额外的类型转换。

常见排查点 #

• 先看异常栈的抛出位置：如果报错是在Parse Template下游、还没进Transform Message组件的时候抛的，100%是MIME类型不匹配导致的自动解析失败，优先调整组件间的类型配置
• 别在DataWeave里试图救已经触发解析异常的payload：当入参类型不匹配时，解析阶段就会直接终止流程，后面写的as :string、反序列化再转字符串的逻辑根本不会执行，这就是你之前那几个尝试失效的原因。

内容的提问来源于stack exchange，提问作者ajs117