太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
http://www.json.org/json-zh.html
该链接是目前使用过的最好用的在线格式化、格式校验和结构化 JSON 工具。
很多时侯，前后台配合开发过程中，服务端返回的 JSON 串明显是有问题的，可是服务端开发人员确不能有效地自查，每次提出问题，都是秒改，然后回复，再次测试发现还是有问题，而总会招来一些指责“同样的接口，别人获取就正常”一类的话，最后无耐，就得管点闲事儿，使此工具校验确认其 JSON 结构错在哪里，并让其自已拿此工具来校验。
有时，也真是无耐，当出现这样的明显错误时，有些客户端开发人员居然把获取到的 JSON 结构进行修补了使用，原因是他不深刻理解 JSON 语言定义，而且解析不过去时，或者直接解析字符串的方式一点点按固化格式来取；而懂得 JSON 语言结构定义的，确拿着接口获取到的错误 JSON ，用字符串处理的方式，把缺的地方补上，然后再交给 JSON 解析库来解析。
这只能有一个可能，服务端开发人员太难搞定，而且每每自已出现了问题，总能很坚挺地指责接口各方，这说明服务端的人员很有权威，但不知这权威是哪里来的，难道权利这样下放的后果，上层真的没有察觉到，还是......真的不太晓得了
不过这个事情，到我这里终止，必须要求服务端改好，最终汇报到老板那里，也要把这个问题背后的链条摸清呈报与老板，让老板自已定夺。
如果老板继续迁就服务端，那么至少在我这里，也会变得和其它开发人员一样，那只能拿来是啥就用啥了，这种工作方式最终只能打消工作积极性，至少是对当前的工作任务来说，而我们有时可能也得理解，可能老板有苦中，不过我不会为这个事情多消耗的工时拿休息时间来买单，因为它不值，这也是原则，放弃自已的休息来为别人的错误擦屁股，而且是后续还会这样的情况下；如果问题已经纠正了，那么花些休息时间来弥补一下也是可以考虑的，至少为了后续的工作更顺昨。
当然了，第二种情况，就是老板施加压力，服务端的大牛哥改正自已的错误，这最好不过了。
不过，这两种情况，一般从来不会单独发生，那么就惨兮兮咯！
也没关系，我们只要把心态放平，不温不火，不急不燥，天天写报告记录相关事宜多耗费的工作时间和埋下的问题查出所花费的时间，时间一久，老板看着赶不上来的进度就着急，看着白白浪费的工时就心疼的时侯，自然就去给服务端那位大牛哥施加压力了，最终结果，那位大牛哥，要么醒悟过来，加紧学习，提高能力，要么，滚蛋与否，或是从公司，或是从岗位上，无论怎样，我们最终都不再受这份煎熬。
其实，这也是一种锻炼，按一种错误的方式去做，你可以接触更宽的知识域，对正确的方式有更深刻的理解。
总之，身体是自已的，要不为别人的过错来祸害自已，生气本身就是拿别人的过错来惩罚自已，到目前，我能90%做到控制不生气，偶尔还会忘记控制，但遇事之初，还是会有不悦的心境，毕竟是人嘛，能学会控制，本身就是比本身就不生气要高一层，本身就不生气的人，对啥事情都没态度，那还了得。
此链接，是 JSON 的语法定义，简单概括，就是描述映射、数组和标量，这三者是包括 Java、C#、C++标准库、OC、JavaScript 等在内都提供的，也是学任何一门语言都不可回避的，所以 JSON 的定义，真是一种高度的概括呀！
Json 在线格式化与定义、各语言开源库集锦