Egy string-ről legkönnyebben úgy tudjuk megállapítani, hogy JSON vagy sem, hogy megpróbáljuk átalakítani. Ha sikerült, akkor az, ellenkező esetben pedig nem, ilyen egyszerű. :)
Store teljes tartalma JSON alakban:
A JSON formátum ellen a leggyakoribb kritika az eval miatti sebezhetőség. Én ezt túllihegett problémának érzem. De kétségtelen, hogy előfordulhat olyan példa, amikor kellemetlen következménye lehet a JSON értelmezés közben alkalmazott eval használatának. (bár ilyen eseteknél nem az eval az egyedüli probléma) Talán emiatt is lehetett, hogy nemrégibben több böngészőgyártó a JavaScript-hez hozzáadta az un. natív JSON kiegészítést. Így már az eval helyett használhatja az ember a beépített JSON elemzőt.
Amiért ez számomra érdekes volt, hogy meglepően gyorsabb az eval-nál.
Nagyon közhely: rossz kódban, rossz hibák vannak, és rossz azokat keresni! :)
PHP-ban valamiért összekeveredik a lista és az asszociatív tömb, talán emiatt is sokszor JavaScriptben is találni olyan példákat, hogy egy elem tulajdonságai nem Object-ben, hanem Array-ban vannak. (előre meghatározott sorrendben). Azontúl, hogy nagyon kerülendő ez a megoldás, még komoly hibaforrás is lehet, ha valamelyik tulajdonság undefined is lehet, majd mindezt valamiért JSON-nal el akarnánk kódolni.
Eredmény: "a: 3; b:2". és ugye azt mondani sem kell, hogy az indexek eggyel elcsúsztak... Meg lehetne hack-elni az encode-t, hogy készüljön fel erre az extrém esetre, de jobb inkább ezt az egészet elkerülni...
Általában mindenkinek azt szoktam ajánlani, hogyha teheti, akkor XML helyett JSON-nal kommunikáljon. Gyorsabb, könnyebb kezelni, rövidebb adat, típusosabb stb. Persze azért vannak hátrányai is… de ugye valamit valamiért. :)
Annyiból mindenképpen macerássabb, hogy a böngésző alapértelmezetten nem tudja szépen, átláthatóan megjeleníteni, ahogy az XML-t. Külső programok vannak erre, de némelyikhez még külön dll-t is fel kell pakolni a gépre. Nem olyan régen elkészítettem magamnak az egyik ilyen program online változatát, hogy kényelmesen mindenhol elérhessem.
