Remark42 Webhook通知中的JSON格式问题解析与解决方案

问题背景

在Remark42评论系统的1.13.0版本中，当配置管理员通知Webhook时，系统会在发送的JSON数据中意外添加未转义的换行符(\n)，导致接收端解析JSON时出现格式错误。这个问题在Linux环境下尤为明显，特别是当使用Rails或Go等语言的标准JSON解析库时，会直接导致解析失败。

问题现象

当用户提交一个简单的评论如"testme"时，Remark42发送给Webhook的原始数据如下：

"{\"text\": \"<p>testme</p>\n\"}"

注意末尾的未转义换行符\n，这使得JSON格式变得不规范。在接收端，无论是Rails的JSON.parse方法还是Go的json.Decoder都会报错，提示"invalid character '\n' in string literal"。

技术分析

问题根源

1. HTML内容处理：Remark42在发送通知前会将评论内容转换为HTML格式，自动添加

   标签

2. 换行符处理：HTML转换过程中，系统会在段落末尾添加换行符，但这些换行符没有经过JSON规范的转义处理
3. 模板拼接：最终的JSON字符串是通过模板拼接而成，没有经过严格的JSON序列化过程

影响范围

这个问题会影响所有使用Webhook通知的场景，特别是：

• 管理员通知
• 评论审核通知
• 系统告警通知

解决方案

临时解决方案

在接收端可以采取以下临时措施：

1. 对接收到的原始字符串进行预处理，移除或转义非法字符
2. 使用更宽松的JSON解析器，允许某些非标准格式

根本解决方案

从Remark42系统层面，应该：

1. 对所有发送到Webhook的内容进行严格的JSON序列化
2. 确保HTML内容中的特殊字符都经过正确转义
3. 在模板渲染阶段加入内容净化处理

最佳实践

1. 内容转义：在构建JSON响应时，使用标准库的JSON编码功能而非字符串拼接
2. 测试验证：实现自动化测试来验证Webhook发送的数据格式
3. 接收端防御：即使发送端修复了问题，接收端也应做好错误处理

总结

JSON格式的严格性要求所有特殊字符都必须正确转义。Remark42中的这个问题提醒我们，在构建Webhook系统时，必须注意数据序列化的每个环节，特别是当内容经过多层处理(如HTML转换)时。开发者应当使用标准库而非手动拼接来生成JSON，以避免此类格式问题。