JSON解析新办法：JSEL

JSON解析和系列化功能，JSON官方网站是提供了官方的Java实现的（org.json）。

但是，官方的实现并不理想。
不仅接口复杂的要命。而且效率也不理想，基本可以判定是一个不合格产品。

另外一个我比较喜欢的解析器，叫做StringTree。
这个解析器最大的特点就是简单，JSONReader负责解析，JSONWriter负责序列化，成员方法也简单明了。
他的输出格式除原始类型外，返回的Map，和List，充分利用了Java 集合框架。比起官方实现来，干净了很多。

StringTree不仅简单易用，而且性能也非常不错。
根据我的测试结果，StringTree最好。大概是JSEL的两倍。
而官方版本最差，大概只有是JSEL一半。等比数列了，JSEL居中。

不过StringTree有一个bug，如果代码里面有注释，经常出现死循环。


再说JSEL：
与专门的JSON解析相比，JSEL不仅可以解析标准的JSON数据，他还可以处理（忽略）JSON中插入的注释。甚至能处理一些简单的表达式计算，接口简单，性能也还不错。
如：

{
    "time":24*60*60*1000*365*（2008-1981）,
    "data":[1,2,3,4,5],
     key:123
}

关于JSEL的更多的信息可参看如下连接：
详细介绍：http://code.google.com/p/lite/wiki/JSEL
详细介绍：http://code.google.com/p/lite/downloads/list

非常不错！我也一直觉得json.org的实现比较有问题。

呵呵，确实，一种简单的数据模型，搞的接口那么复杂，完全丧失了JSON简单的优点。

刚写JSEL的时候，也没想过把它用作JSON解析引擎，但是写完了才发现，他就是一个有效的JSON解析引擎。

正好可以吧那个官方版本给替了。

json为什么需要解释啊？不是eval一下就行了吗？如果是在服务端组成返回的json字符串，感觉还是自己组合字符串更加舒服。

这个在于你怎么看json了。
json不是js专有的，现在已经可以看成一种与xml同类的数据交换格式。

不好意思，我来唱点反调。。。

东西蛮好，就是有点鸡肋（我是指当json解析器来用）。

如果我看JSON的规范没有理解错误的话，json是没有注释（也就是指// /*一类东西），也不支持表达式运算的。

所以StringTree不支持注释并不能算bug（反而能算是feature？）。

固然，可以认为jsel是更宽松，或者提供了扩展，但是就一般的BS中的json应用来说，这是没有意义的——B端的toJSONString之类的方法产生的应该总是严格的JSON，而不会给JSEL用武之地。

反过来说，没有一个JSON引擎可以让JSEL有用武之地，因为如果产生的不是严格的JSON，就失去了互操作性，也就失去了JSON的意义。再就json在B端的一般JS实现来说，eval虽然可以处理注释、表达式，但是比较严格的解析器出于数据安全考虑，可能会认为带有注释和表达式运算的代码是非法的json代码，特别是在未来浏览器允许跨域数据访问的情况下。未来的ES3.1加入的json专用方法我估计肯定不会接纳非标准的json，除非先重新厘定JSON标准。

当然，也许有其他特殊的use cases是JSEL的适用场合，只是我暂时还没有想到。

呵呵，欢迎反调。

我来一一解释吧：
StringTree不支持注释本没有错，但是有错误不报出来，还吧自己搞进一个死循环在那里吓折腾那就是大错了。
如果你的服务器上有这样一个“不能算bug的featrue”，那么，一旦被别人发现，那么你就只有等死的分了。

而对于JSEL支持简单表达式运算，支持注释，我倒是认为可以看做一个附加的 featrue。
就好像是我们生活在中国，学几门外语也不是错误。只要别把母语忘记就行。

如果是系列化的时候产生了标准之外的东西，那毫无疑问，这是一个特大bug。而我是解析，解析的时候宽松一点，特征多一点，只要不影响正确格式的解析，我认为也是可以的，兼容标准，但不限于标准。当能鸡肋说也有道理。

再说了，这个鸡肋也不是完全一无用处，比如说，如果是一个用户可修改的json数据源，那么，我个人就很希望我能写一些注释。


在顺便解释一下，写JSEL最初的目的不是为了JSON解析，只是写完了才发现，本身就是一个不错的JSON解析器。
算是无心插柳吧。

嗯，出现死循环确实是有问题，应该算bug。

还有么，宽松一点当然好。我们一直信奉要严于律己，宽以待人。不过在json之类的交换格式上，我觉得宽松不一定是一个好策略。

比方说写注释这个事情吧，jsel支持当然好，但是如果这个json也要为其他人所用，比如B端用，或者.NET的客户端用，那么他们的json解析就可能报错。使用者就可能会纳闷了，为什么你这儿好的，那就不好呢？如果这是一个比较大的软件，维护者要跟踪此类数据交换问题就比较头大，那可能就是好心办了坏事了。

我为什么这样说呢，是因为我有这样的教训。

有一次我手写了一些json数据放在服务器上，给ajax应用使用。本来好好的。后来换了一个js库，就老是不行。那个抓狂啊。后来发现是我原来手写的json数据有问题。

按照严格的json规范：

1. 字符串应该用双引号，而不是单引号。
2. key:value的key部分也必须用双引号。

也就是说正确的格式是：

{"a":"xyz"}

而我写js的习惯是：

{a:'xyz'}

用的原本的js库，它只是简单eval，所以没问题，而后来改用了一个js库，有非法字符过滤，结果就老是失败了。恰恰由于以前都很顺利，所以你很难想到是这里出了问题，最初的痛快导致了后来加倍的痛苦。

这个给出一个教训，在某些时候宽以待人未必就是好事，就好象你宠着孩子未必是好事一样。

另一个著名的反例就是html啦。html规范对tag soup应该怎么处理语焉不详，后果很严重，开发者很触气。现在html5虽然争议不少，但大家一致赞成要重新制定详细的html解析规则。

所以孔子说不可以德报怨，而要以直报怨。

最后，其实我觉得支持这些特性也不是不可以，不过如果你是要给别人当成json解析器来使用的话，至少应该就这些问题扔一些warning出来。或者更好的一个办法是增加一个参数来让用户指定错误处理的方式是完全忽略、输出警告或者抛出异常。

呵呵。
刀磨得太快怕切到手。
糖做的太甜说坏了你胃口。
Window做的太易用了，说人家宠坏了用户。


什么东西都有着利害两面，关键在于用户如何去用他。

JSEL支持更多的语法本没有错，要错就错在你被它宠坏，宠坏了也没有错，但是宠坏了你还要移情别恋，那就是你的问题了。

这点确实值得一做，以后有这个需求了再补上，简单的说就是，JSEL如果还能有严格语法的验证支持，就更好了。