在调用诸如JSON.toJSONString(ue, SerializerFeature.WriteClassName)以串行化数据时，若存在long属性（参见LongCodec），可能会被附加L字符，结果如“{a:0L}”。
对此，我有一些疑问：
1、这是否因为要遵循JSON标准，或者这么做的背景是什么呢？
2、其他JSON库（包括JavaScript的JSON）似乎都无法解析已被串行化后的字符串“{a:0L}”。
PS：当前使用情况是，后台系统使用FastJson串行化对象并存入数据库（因为项目需要，不得不使用SerializerFeature.WriteClassName），前端Java应用把已串行化的字符串返回给前端的JavaScript库jsoneditor展示，它会调用标准JSON进行反串行化，但这时候会失败。针对这种情况，我现在是在返回字符串给前端前先用FastJson先反串行化为对象，然后再使用FastJson转回字符串（不带SerializerFeature.WriteClassName），感觉这样的代码非常丑陋。
现在是否有已知的较好的解决方法呢？
4条答案
按热度按时间y0u0uwnf1#
这个是一个选项，缺省配置生成的JSON串都是兼容标准的。如果需要完整意义实现序列化和反序列化（支持类型和循环引用），目前的实现是不遵循标准的。也可以使用遵循标准的实现，性能或许受到一定影响。
flvtvl502#
这个问题有没有解决呢 ？加上SerializerFeature.WriteClassName后，double、long、float 数据后面都会加上对应的字母，json识别不了 （最新版：fastjson-1.2.43）
f3temu5u3#
缺省是兼容标准的，启用WriteClassName之后，就是为了正确保证能反序列化到原来类型。
pu82cl6c4#
目前有输出标准的json带java类类型的方案吗？