天天看點

Json 線上格式化與定義、各語言開源庫集錦

Json 線上格式化與定義、各語言開源庫集錦

<a target="_blank" href="http://blog.csdn.net/opengl_es">轉載請保留此句:太陽火神的美麗人生 -  本部落格專注于 靈活開發及移動和物聯裝置研究:iOS、Android、Html5、Arduino、pcDuino,否則,出自本部落格的文章拒絕轉載或再轉載,謝謝合作。</a>

<a target="_blank" href="http://www.json.org/json-zh.html">http://www.json.org/json-zh.html</a>

該連結是目前使用過的最好用的線上格式化、格式校驗和結構化 JSON 工具。

很多時侯,前背景配合開發過程中,服務端傳回的 JSON 串明顯是有問題的,可是服務端開發人員确不能有效地自查,每次提出問題,都是秒改,然後回複,再次測試發現還是有問題,而總會招來一些指責“同樣的接口,别人擷取就正常”一類的話,最後無耐,就得管點閑事兒,使此工具校驗确認其 JSON 結構錯在哪裡,并讓其自已拿此工具來校驗。

有時,也真是無耐,當出現這樣的明顯錯誤時,有些用戶端開發人員居然把擷取到的 JSON 結構進行修補了使用,原因是他不深刻了解 JSON 語言定義,而且解析不過去時,或者直接解析字元串的方式一點點按固化格式來取;而懂得 JSON 語言結構定義的,确拿着接口擷取到的錯誤 JSON ,用字元串處理的方式,把缺的地方補上,然後再交給 JSON 解析庫來解析。

這隻能有一個可能,服務端開發人員太難搞定,而且每每自已出現了問題,總能很堅挺地指責接口各方,這說明服務端的人員很有權威,但不知這權威是哪裡來的,難道權利這樣下放的後果,上層真的沒有察覺到,還是......真的不太曉得了

不過這個事情,到我這裡終止,必須要求服務端改好,最終彙報到老闆那裡,也要把這個問題背後的鍊條摸清呈報與老闆,讓老闆自已定奪。

如果老闆繼續遷就服務端,那麼至少在我這裡,也會變得和其它開發人員一樣,那隻能拿來是啥就用啥了,這種工作方式最終隻能打消工作積極性,至少是對目前的工作任務來說,而我們有時可能也得了解,可能老闆有苦中,不過我不會為這個事情多消耗的工時拿休息時間來買單,因為它不值,這也是原則,放棄自已的休息來為别人的錯誤擦屁股,而且是後續還會這樣的情況下;如果問題已經糾正了,那麼花些休息時間來彌補一下也是可以考慮的,至少為了後續的工作更順昨。

當然了,第二種情況,就是老闆施加壓力,服務端的大牛哥改正自已的錯誤,這最好不過了。

不過,這兩種情況,一般從來不會單獨發生,那麼就慘兮兮咯!

也沒關系,我們隻要把心态放平,不溫不火,不急不燥,天天寫報告記錄相關事宜多耗費的工作時間和埋下的問題查出所花費的時間,時間一久,老闆看着趕不上來的進度就着急,看着白白浪費的工時就心疼的時侯,自然就去給服務端那位大牛哥施加壓力了,最終結果,那位大牛哥,要麼醒悟過來,加緊學習,提高能力,要麼,滾蛋與否,或是從公司,或是從崗位上,無論怎樣,我們最終都不再受這份煎熬。

其實,這也是一種鍛煉,按一種錯誤的方式去做,你可以接觸更寬的知識域,對正确的方式有更深刻的了解。

總之,身體是自已的,要不為别人的過錯來禍害自已,生氣本身就是拿别人的過錯來懲罰自已,到目前,我能90%做到控制不生氣,偶爾還會忘記控制,但遇事之初,還是會有不悅的心境,畢竟是人嘛,能學會控制,本身就是比本身就不生氣要高一層,本身就不生氣的人,對啥事情都沒态度,那還了得。

<a target="_blank" href="http://www.bejson.com/">http://www.bejson.com/</a>

此連結,是 JSON 的文法定義,簡單概括,就是描述映射、數組和标量,這三者是包括 Java、C#、C++标準庫、OC、JavaScript 等在内都提供的,也是學任何一門語言都不可回避的,是以 JSON 的定義,真是一種高度的概括呀!