Portál AbcLinuxu, 30. dubna 2025 20:14
Tiskni
Sdílej:
Pro člověka je snáze čitelný například INI nebo YAML. Pro počítač jsou rychleji čitelné s-výrazy nebo JSON nebo nějaký binární blob.
From Intel XML Parsing Accelerator, we found that character checking loop occupies more than 60% CPU cycles of the whole parsing process
All Unicode characters may be placed within the quotation marks3 Encoding:
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.Přehled různých implementací najdeš na json.org, ale plnohodnotný minimalistický parser kdyžtak sám spácháš za odpoledne
Tohle ti prijde dlouhe??? http://www.w3.org/TR/REC-xml/Na to, jak málo to umí, mi to přijde extrémně dlouhé. Vždyť to co jsi odkázal umí jenom syntaxi pro strom nějakých znakových dat a nic víc. Dokonce v tý odkazovaný specifikaci nejsou ani namespaces.
nebo nejaka serializovana data na ktere nikdy nesahnes jinak nez pres svuj program, tak pouzij JSON, nebo YAML.
Proc? Prave k rucni editaci jsou JSON a YAML "relativne" vhodne. Jinak souhlas - XML jen pro automatizovany vystup dat a nasledne nacitani a zpracovani.
Ja jsem par mesicu mel OpenBox a odesel jsem z nej pouze z jednoho duvodu - XML konfigurace. To se proste nedalo... Malo prehledne, silene ukecane, co mam v PekWM na jednom radku, tam zabralo radku klidne 8 nebo 10. Nakonec se z neznameho duvodu cele XML rozsypalo (bylo cele na 1 radku), fungovalo do te doby, nez jsem potreboval neco upravit (zkousel jsem v ruznych editorech), proste jakmile se ulozilo, tak cely OpenBox odmital XML nacist, pry z duvodu chyb. Nekolik hodin jsem se snazil XML procistit ruznymi pomuckami, aby kod byl citelny, pak jsem to musel vzdat.
11.6.2010 14:25
12.6.2010 19:40
11.6.2010 15:26
11.6.2010 19:03
xmlindent konfigurák.xml a je odsazeno, případně použít nějaký inteligentní editor, který odsadit celý dokument taky umí.
xmlindent vubec neznam a nemam ho ani v systemu, mel jsem se tu radsi asi zeptat. Zkousel jsem to pres ruzne podobne utilitky online a tam to vubec neslo, jelikoz byly v kodu chyby a odmitalo to zformatovat. Jinak proc byl konfigurak na jednom radku? To bych prave taky rad vedel, proste to tak jednoho dne bylo, kdyz jsem ho otevrel.
Tam prave naopak, konfigurak openboxu je koncipovan pouze pro rucni editaci, zadna utilitka k tomu neni.A na to jsi přišel jak?
Tohle také vypadá hodně zajímavě - http://sexpr.sourceforge.net/
s-expression
Zas tak hrozné to není... a určitě to není tak náročná na pasování...
(edges ( (1389.886593 1341.567282) (1383.122623 1339.369530) ) ( (1383.122623 1339.369530) (1387.706464 1325.261939) ) ( (1387.706464 1325.261939) (1394.470360 1327.459664) ) ( (1394.470360 1327.459664) (1389.886593 1341.567282) ) ); edges end (edges ( ( 1.1 2.2 ) (2.2 3.3) ) ( ( 2.2 3.3 ) (3.3 3.3) ) ( ( 3.3 3.3 ) (1.1 2.2) ) ) ; end edges of triangle room ====================================================== (setq a (point 1 2)) (setq b (point 5 7)) (setq k1 (circle a b)) (setq k2 (circle b a)) (setq tmp (section k1 k2)) (draw a b (segment (point1 tmp) (point2 tmp)))
JSON: [123, "abc"] sexp: (123 "abc") XML: <list><number>123</number> <string>abc</string></list>Samozrejme, pro jednu konkretni aplikaci by asi slo udelat rozumne XML-based reseni a uvedeny priklad je jen jedna z moznosti, ale pokud uvazuju opravdu o generickem jazyku pro reprezentaci strukturovanych dat, pak je XML pro tyto ucely znacne neprehledne. Oproti tomu s-expressions a JSON jsou syntakticky velmi podobne.
12.6.2010 19:08
Petr Tomášek | skóre: 39
| blog: Vejšplechty
<l n="123" s="abc"/>
[ "number": 123, "string": "abc" ] :-)
hodnoty v JSON mají typyTypy nemají o nic víc než v XML. Leda maximálně o uvozovky, to ale nic nezaručuje.
123, 1.234, "string", ...123, 1.234, "string", ...<values> <value>123</value> <value>1.234</value> <value>"string"</value> </values>První může být integer, float s ořezáváním desetinných míst nebo řetězec. Druhé může být řetězec, float, dva integer oddělené tečkou nebo cokoli jiného. Třetí může být řetezec obsahující "string", řetězec obsahující string nebo cokoli jiného.
Tady je vidět rozdílný přístupAno, přesně ten jsem měl v úmyslu ukázat, protože jsem měl za to, že ho ignoruješ. Rozdílný cíl/účel vyžaduje rozdílný přístup. A v čem mi pomůže to, že XML schema má nějaké datové typy? A regulární výraz? Jak mi ten pomůže k naparsování prefixu do dvou například 32bitových čísel? A jak nadefinuješ třeba rodné číslo? Taky pomocí regexpu? V tomhle je schema středně silný nástroj, který se tváří, že umí všechno, ale neumí. Osobně trvám na tom, že ve výše uvedeném případě je XML méně vhodné než obě ostatní zmíněné možnosti.
Kdežto v XML použiješ...Existují i jiné knihovny pro práci s datem, časem a IP adresama :).
Druhé může být řetězec, float, dva integer oddělené tečkou nebo cokoli jiného.Ne, dle XML to dva integery být "nemůžou", to by byly každý ve svým tagu (což je ale spíše detail).
Ne, muzou. Muze to byt cokoliv, je na aplikace nebo schematu (coz neni "samotne XML"), aby definovala o co se jedna.V tom případě můžu mít klidně v JSONu
"12.33" apod. Taky tam můžeš mít cokoliv. Ano, nebude to JSON-košér, ale <item>123.456<item> jakožto dva integery taky není XML-košér.
Mozna ti to pripada jako detail, ale je v tom velky rozdil.Tak mi ten velký rozdíl ukaž, opravdu mi není jasný, kde je.
Pak ti snad dojde, na co je dobre vedet, jakeho typu jsou data.Schema nespecifikuje pouze jakého typu jsou data, ale především kde má jaký typ dat být, to je to podstatné, a v tom taky je rozlišení typů u JSONu prakticky nahouby.
Opet, jo, neni to idealni, ale stale lepsi nez neznat ani ten typ dat.A co ti brání si do toho XML dát něco jako tohle?
<položka typ="int">123</položka>Vždyť je to jako když v JSONu někde máš uvozovky a někde ne – vždycky stejně musíš v aplikaci řešit, jestli tam náhodou bez uvozovek není napsané třeba
abcd místo čísla. V JSONu můžeš mít jen dva typy dat (no dobře, různé druhy čísel) a v XML jich můžeš mít neomezeně mnoho, to je to eXtensible ve zkratce XML.
Problem spis vidim s hura programatory, kteri "jo, budem cool, budem pouzivat XML", ale na schema se vyprdnou.Něco podobného se mi nedávno stalo – asi trochu pod vlivem toho, jak se dneska všude vnucují noSQL resp. bezschémové databáze a je to děsná „móda“, tak jsem si řekl, že to taky zkusím bez schématu – akorát jsem používal XML a soubory, ale to je jedno. Je to velice jednoduchá aplikace, tak jsem si říkal, že to zvládnu – ale ne – hodně rychle jsem si to schéma dodělal. A to to byla opravdu jednoduchá aplikace s pár dokumenty o pár elementech – ale jak jsem ji vyvíjel, přidával nové funkce nebo měnil, tak se měnily i dokumenty – a nebavilo mne ručně kontrolovat, jestli je každý dokument je v souladu s aktuálním kódem programu (nebo to naopak nekontrolovat a nechat kód bobtnat různými alternativními větvemi jako, co když tenhle element chybí, nebo co když se jmenuje ještě postaru atd. tak udělej tohle…)
A co ti brání si do toho XML dát něco jako tohle?
To, že potřebuje ukázat, jak je XML špatné. :-)
a anti-XML fanaticiZatím jsem tu žádného neviděl, akorát pro-XML fanatiky. Teda na jednoho anti-XML jsem podezření měl, ale nepotvrzené. Jakou máš motivaci prosadit XML jako jediné správné řešení a pošpinit všechny ostatní? Vždyť je to jen syntaxe.
Tak si to přečti znovaTak jsem si to přečetl znova a zareagoval bych znova stejně. Můžeš mě prosím upozornit, co jsem pochopil špatně a proč jsem si měl tvůj příspěvek číst znova?
Přestřelit se dá na obě stranyMám to chápat, jakože uznáváš, že XML není na místě za všech okolností?
použít ne-XML na moc složitá dataByly dokonce doby, kdy XML neexistovalo a pravděpodobně přijdou doby, kdy XML existovat nebude. Můžeš mi říct objektivní důvod, proč je XML jediným rozumným formátem pro "složitá data"? Samozřejmě kromě toho, že je v módě.
Závěrem bych řekl, že i ten JSON je většinou lepší než nějaké specializované formáty, které si vymyslel autor programu XYZ a nikde jinde se nepoužívajíVětšinou.
má se používat UTF-8 a pokud chceš něco jiného, tak si to deklaruješ uvnitř dokumentuSouhlasím že v tuhle chvíli nenajdeš vhodnější znakovou sadu než Unicode a vhodnější kódování než UTF-8 a taky doufám, že se bude čím dál tím víc ustalovat na úkor iso*, windows* i UTF-16.
jen jsem na tom chtěl ukázat, že XML umí to samé, co JSONTak to jsme se nepochopili. Považoval jsem za samozřejmost, že v XML půjde uložit to co v JSONu. I to, že pro něj taky jde nějakým způsobem definovat schéma.
a mnoho dalšíhoOno to XML v oblasti strukturovaných dat zase nic moc navíc oproti JSONu neumí, nebo jsem si aspoň ničeho nevšiml.
V JSONu můžeš mít jen dva typy dat (no dobře, různé druhy čísel) a v XML jich můžeš mít neomezeně mnohoPočkej, tohle nemůžeš myslet vážně. V čem je XML bohatší na typy než JSON? Umí oba zapsat string? Ano. Umí oba zapsat číslo? Ano, oba v textové podobě, JSON ho navíc narozdíl od XML odlišuje od stringu. Umí oba zapsat strukturovaná data (seznamy a objekty)? Ano. Tak mi prosimtě vysvětli, kde vidíš ten rozdíl, případně co tě vedlo k tomuto omylu.
Viz ty datové typy, které jsem tu už několikrát odkazoval – je to daleko bohatší než string a číslo.XML specifikaci jsem četl a nic takového tam není.
V XML je možné hodně věcí vyřešit už na úrovni formátu/parseru, kdežto JSONem projdou až do aplikace a musíš je ošetřovat tam – to je jedna z výhod XML.V tomhle se XML a JSON neliší.
pět je tu ta přenositelnost a znovupoužitelnost – pro někoho je možná tvorba XML Schématu nepřekonatelně těžká a napsat pár řádků v jeho oblíbeném jazyce mu přijde jednodušší, ale zase XML Schéma napíšeš jednou a použiješ v libovolném jazyce – tady zase záleží, jestli je to nějaká jednoúčelová interní záležitost, nebo věc, na které má spolupracovat víc lidí/firem/systémů/jazyků…Co konkrétně se ti na JSON schéma nelíbí?
Jiste, je to slabe, ale furt lepsi nez XML, ktere neumoznuje ani to rozliseni typu. ...Jo, o pidikousíček lepší to je
Opet, jo, neni to idealni, ale stale lepsi nez neznat ani ten typ dat.
To jo, ale bavime se tu o cistem XML, ne o DTD nebo XML schema. Pokud mas schema, tak nemam nic proti. Problem spis vidim s hura programatory, kteri "jo, budem cool, budem pouzivat XML", ale na schema se vyprdnou.No tak s tím samozřejmě souhlasím, o tom žádná...
<object> <string>Josef</string> <string>Novák</string> <integer>25</integer> </object>psát raději:
<osoba> <jméno>Josef</jméno> <příjmení>Novák</příjmení> <věk>25</věk> </osoba>V prvním případě dokument obsahuje informaci o datových typech, ale význam hodnot na jednotlivých pozicích musí být definovaný někde mimo dokument. Naopak druhý příklad obsahuje význam hodnot, ale neobsahuje informaci o datových typech – ta musí být definovaná mimo dokument. Případně jde oba přístupy zkombinovat a uvnitř dokumentu definovat všechno:
<osoba type="object"> <jméno type="string">Josef</jméno> <příjmení type="string">Novák</příjmení> <věk type="integer">25</věk> </osoba>Osobně mi přijde nejvhodnější druhá možnost, byť samozřejmě záleží na konkrétních podmínkách a ty druhé dvě taky mohou najít svoje využití. P.S. píšu to v XML protože je mi nejbližší, ale mělo by to jít i v jiných jazycích – pro zajímavost můžete tyhle tři příklady přepsat do toho svého oblíbeného
br nebo img, které mají z definice empty content, to až tak nevadí. Za daleko horší považuji fakt, že HTML nikdy nezavedlo povinnost ukončovat elementy typu li, td, tr nebo p.
13.6.2010 12:31
script. Tohle funguje:<script type="text/javascript" src="můj/geniální/script.js"></script>a tohle nefunguje:
<script type="text/javascript" src="můj/geniální/script.js" />
img, br), a ne pro elementy, které mohou obsah mít, ale náhodou zrovna žádný nemají. On totiž třeba ještě MSIE verze 6 XHTML vůbec neumí a zobrazí ho pouze v případě, že mu o něm řeknete, že je to HTML, a také ho pak jako HTML interpretuje.
No z XHTML zustal zachovan jen nazev a to, ze je to aplikace XML. Je fakt, ze jsem to v puvodnim prispevku moc dobre nenapsal.Tak... zůstalo to, že je to apliakce XML a taky zůstalo to, že je to předpokládaný nástupce/alternativa HTML. Což si myslím přesně zkratka XHTML vystihuje. To že si pánové teoretici vymysleli nějakou slepou větev, kterou jim nikdo nechce používat, to je jenom ukázka toho, že ignorování praxe je přinejmenším stejná chyba jako ignorování teorie.
S tim HTML5 a SGML jsem se spletl, resp. jsem mylne predpokladal, ze tak jako predchozi verze bude aplikaci SGML.Myslím, že jednou z výhod novějších HTML je právě to, že se už oficiálně odklánějí od SGML, které už dávno browsery parsovat neumí.
To že si pánové teoretici vymysleli nějakou slepou větev, kterou jim nikdo nechce používatTo vycházíš z čeho? Že se lidi nevrhli na přepisování starých zprasených stránek do XHTML je celkem pochopitelné (to snad nikdo nečekal, ne?). Ale podívej se, v čem vznikají nové weby – tady se XHTML stalo normou, pokud někdo dělá seriózně* webdesign, tak používá právě XHTML, lidi si oddechli, že snad končí ten chaos a bude trochu pořádek, souvisí to i dost s koncem optimalizace pro jednotlivé prohlížeče a respektováním standardů, což je správná cesta. Slepá cesta je HTML 4, to je mrtvé, není důvod ho používat a (X)HTML5 pořád není hotové, a tak v podstatě jediným rozumným formátem je dneska XHTML 1.0/1.1. Časem asi (X)HTML5, ale zatím to není tak horké (zatím se o něm víc mluví a píší články, než že by se něco dělalo). Házet špínu na XHTML prostě není na místě. Je to zralá osvědčená technologie, která se běžně používá. Rozhodně bych ji neoznačoval jako mrtvou nebo neúspěšnou. Mrtvé je HTML 4 a ve vývoji je (X)HTML5, což je zatím spíš experiment (a hlavně buzzword) a jak to všechno dopadne a kam se vyvine se teprve uvidí. *) projdi si prezentace známých lidí a studií, co nabízejí webdesign – všichni dělají XHTML, zatímco HTML 4 nenabízí nikdo, za to by se musel stydět, HTML 4 prostě spadá do té smutné etapy webu, kdy byl všude neskutečný bordel a na stránky se dávali nápisy typu „optimalizováno pro MSIE verze X a rozlišení 800x600“. Ti pokrokovější se možná pochlubí znalostí (X)HTML5, ale v současné době jde hlavně o to říct: „my jsme nezaspali, víme, že to existuje a učíme se nové věci“ než že by se v tom seriózně pracovalo. Maximálně ti někdo udělá web s <video/>, ale stejně to bude ohackované javascriptem a pojištěné Flashem, aby se to lidem zobrazilo.
Viz moje komentáře o filtrech a o tom, že by bylo dobré oddělit dvě věci:
Viz moje komentáře o filtrech a o tom, že by bylo dobré oddělit dvě věci:
Z pohledu idealisty tomu rozumím a chápu tě. Ale k tomuhle nemůžeš lidi donutit. Kde se nějaké to XSLT usadí a bude se pracovat tímto stylem, tak to bude třeba fungovat. Ale je to relativně drahé třeba pro jednotlivce, kteří by museli platit někoho, kdo dobře ovládá XML a XSLT.
Neumí vůbec nic navíc oproti HTML kromě faktu, že je to XML, který je zcela k ničemu na web stránkách.Přínos XHTML byl obrovský, webdesign se konečně vyhrabal z toho hnoje, už se nedělali stránky psané na míru proprietárním prohlížečům, ale lidi si začali uvědomovat, že existují nějaké standardy, které slouží jako společná dohoda – řídí se jím webař, řídí se jím prohlížeč a výsledkem je fungující komunikace – to bylo v dobách HTML zcela nevídané. Lidi na tu dobu pomalu zapomínají, ale myslím, že je dobré o tom mluvit a občas to připomenout – dneska už se považuje za normální, že když si otevřu stránku ve Firefoxu, že vypadá stejně jako v IE nebo v Opeře, ale ne vždy tomu tak bylo.
Třeba i pan Kosek se diví, proč by HTML nemělo být používáno.Pokud vím, tak pan Kosek k tomu řekl, že jeho stránky jsou moc rozsáhlé a on má spoustu jiné práce než aby je předělával do XHTML.
která za krátký čas zajde na nedostatek potravy a zájmuJak zajde? Přestanou ho podporovat prohlížeče? Začnou lidi hromadně přepisovat stránky z XHTML do HTML5? Obávám se že ne, stejně jako je všechny nepřepsali z HTML 4 do XHTML. Ještě odkážu na diskusi na Zdrojáku – HTML 5 sice přináší některé zajímavé funkce (které možná budou zabity neschopností prohlížečů se na něčem shodnout), ale jinak je to strašný bastl, splácaný a nedokonalý, zbytečně zatížený údajnou „zpětnou kompatibilitou“. Viz moje komentáře k
h1 a další.
Přínos XHTML byl obrovský, webdesign se konečně vyhrabal z toho hnoje, už se nedělali stránky psané na míru proprietárním prohlížečůmPokud vím, tak tohle přineslo právě HTML 4.0. XHTML 1.0 nepřineslo pokud vím žádné změny značek nebo vůbec cokoliv co by sjednocovalo prohlížeče více než předtím... a navíc přineslo nový velmi špatný zvyk a to vydávat XHTML za HTML.
Nicméně i já mám web v HTML a budu mít web v HTML. A to jsem člověk, který kdysi před lety přinášel do Česka jako první informace o novém XHTML.Tak v tom tě můžu jenom podpořit. On je velký rozdíl mezi lidmi, co vědí a lidmi, co se potřebují svést na vlně nadšení. A když někdo zapadá do obou kategorií, tak je to docela schíza, na jedné straně se chovat k zákazníkům tak, abys splnil očekávání a na druhé straně jiným říkat jak věci jsou.
Ale podívej se, v čem vznikají nové weby – tady se XHTML stalo normouBavíme se oba dva ještě pořád o XHTML 2.0 nebo vznikl nějaký informační šum? Zatím jsem slovo XHTML viděl používat hlavně s nesmysly typu content type text/html s hlavičkou XHTML 1.0, případně 1.1 a jestli toto někdo označuje za pokrok, tak má trošku jinou definici pokroku než já.
projdi si prezentace známých lidí a studiíKdybych se živil webem na této úrovni, tak bych asi musel tohle divadlo hrát taky. Ale ruku na srdce, kde jsou výhody XHTML 1.0 proti HTML 4.0 pro koncového uživatele?
"firstName": "John"
JSON zase dochází k mixování "schématu" a vlastních dat:K tomu v XML dochází úplně prakticky stejně.
<firstName>John</firstName>To schéma je tam akorát zduplikované a best practice říká, že se nebudou používat libovolně nazvané tagy, ale dodržuje se nějaké schéma (i kdyby nepsané). Stejná konvence jde aplikovat i na JSON.
Psal jsem v obojím a to XML mi přijde příjemnější – nejen syntaxí
Obvzláště pro zápis matematiky. Syntakticky je TeX flexibilnější než XML a podle mne zápis v TeXu je i přehlednější.
v DocBooku píšu, co se bude sázet, ne jak se to bude sázet
Pokud chcete udělat typograficky kvalitní dokument, tak je to nevýhoda.
Autor se sazbou většinou vůbec nepřijde do styku.
Jinak volba mezi DocBookem a (La)TeXem je volbou ze dvou zel, obojí je do určité míry zvrhlé a záleží na tom, k jaké úchylce inklinuje uživatel. O žádné třetí volbě nevím, osobně bych vybral ten LaTeX.
Jinak mám pocit, že si neodporujeme. Psát knihu v TeXu nebo DocBooku je práce pro vraha (DocBook – Kosek, TeX – Olšák ), ale pro takové ty technické dokumentace, které má ve firmě na starosti s bídou jeden člověk, se to asi dá.
Já knihu napsal a celou jsem jí napsal ve vimu v plain textu.A nebylo by lepší do toho textu ve vimu občas vrznout něco jako:
<section> <title>Tohle je nadpis</title> … a tady zase pokračuji v psaní prostého textu </section>nebo aspoň
\section{Tohle je nadpis}
než to pak procházet znova označovat kusy textu a dávat jim styly dodatečně?
JSON vs XML - příklad na Wikipedii. Je to skoro stejné.Ok, jesliže jsou oba tyto formáty nevyhovující, jakou alternativu navrhuješ?
Různým datovým formátům a konfiguračním souborům typicky mixed content škodí.Jak může škodit? Prostě ho nevyužiji (nepovolím ve schématu) a je to. Že má XML hodně funkcí a mně jich stačí málo přece není takový problém. Počítač taky umí (může umět) spoustu věcí a přesto ho hodně lidí používá jen k brouzdání po webu – a nevypadá to, že by jim to nějak vadilo.
acl {
10.0.0.0/8;
192.168.0.0/16;
172.16.0.0/12;
}
případně
[
"10.0.0.0/8",
"192.168.0.0/16",
"172.16.0.0/12"
]
versus
<acl>
<item>10.0.0.0/8</item>
<item>192.168.0.0/16</item>
<item>172.16.0.0/12</item>
</acl>
Dál ještě XML knihovny dost překáží programátorovi, co potřebuje právě jenom takové jednoduché konfigurační direktivy. Parsing je ok (když vynechám efektivitu), ale třeba generování "pěkných" XML konfiguráků řeší velká část běžných XML knihovem špatně (teď ani nevím, která to řeší dobře).
Psát za každým příkazem středník, nebo každý příkaz o závorkovat, to vyjde téměř nastejno...
Prolog ještě úplně nevymizel.
Ale jejich rozšíření v zásadě jen klesá.
To si nemyslím. Už jen proto, že poslední dobou vychází docela velké množství knih o funkcionálních programovacích jazycích jako F#, Scala nebo Clojure.
myWonderfulQuery=SELECT \
something, \
something_else \
FROM \
(SELECT \
…
Při vývoji té druhé jsem se poučil a použil XML:
…
<entry key="myWonderfulQuery">
SELECT
something,
something_else,
FROM
(SELECT
…
</entry>
…
Ano. Rozdíl je v těch backslashích. Asi každému je jasné, jaké peklo se musí podstoupit při úpravě dotazu, který je uložen v Properties. Načítání těch konfiguráků je v obou případech na dva řádky.
Takže tak. Existují případy, kdy je XML opravdu o malinko lepší.
obj = eval(json_string);Tolik k "šílenému".
json_string obsahuje opravdu jen data a nikoli kód? 
var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');Muhehe.
JSON.parse(text) pro deserializaci a JSON.stringify(obj) pro serializaci. Viz též http://www.json.org/js.html.
XMLDecoder.readObject(); XMLEncoder.writeObject();akorát ten XMLDecoder a XMLEncoder máme už od dob Javy 1.4
Optimální to není, ale pokud ten postup vypadá takhle:
objekt → serializovat → odeslat → přijmout → deserializovat → objekt
tak je celkem jedno, co je uvnitř. V obou případech je to formát odvozený od nějaké konkrétní platformy (v jednom případě Java, v druhém JavaScript), udělat k tomu načítací a ukládací knihovny pro jiné jazyky jde v obou případech. JSON je méně „ukecaný“ a přehlednější, lepší pro ruční psaní – ale pokud ho ručně nepíšeš (místo toho serializuješ objekty), tak je to celkem jedno. Když chceš lepší (přizpůsobitelný) výstup, tak stejně nepoužiješ obyčejnou serializaci, ale mapování třeba pomocí JAXB.
pokud ten postup vypadá takhle: objekt → serializovat → odeslat → přijmout → deserializovat → objekttak použiju Protocol Buffers nebo spíš Thrift
Jen malé doplnění: Načtení dat uložených v JSON se v Javascriptu dělá takto:No to je možné, že v javascrpitu se to tak dělá. Já to psal z pohledu člověka, co píše C++, a tam by to imho šílené bylo dost...obj = eval(json_string);Tolik k "šílenému".
Jen malé doplnění: Načtení dat uložených v JSON se v Javascriptu dělá takto:Nejsem Javascriptových programátor, ale podle toho, co jsem četl o JSONu, tak to není pravda. Podle mých informací v Javascriptu existuje podpora pro JSON (nevím které verze kterých implementací to podporují).obj = eval(json_string);Tolik k "šílenému".
eval('(' + json + ')'), ale to je detail. Nativní serializace a deserializace existuje, ale ještě zdaleka ne všude.
Je to pravdaI podle ostatních příspěvků není.
a musí to jít už protoSamozřejmě, že to musí jít, ale to ještě neznamená, že je to správný nebo dokonce rozumný způsob. JSON je samostatný datový formát, byť je z hlediska syntaxe podmnožinou programovacího jazyka. Způsob, který uvádíš je nebezpečný a špatný. Pokud je jenom trochu zbytí, nebo není zvláštní důvod, proč ho použít, tak bych se mu vyhnul.
Nativní serializace a deserializace existuje, ale ještě zdaleka ne všude.V případě absence čtecí rutiny to do jisté míry chápu, ale ani tak to nepovažuju za ideální.
Zkus se podívat na implementaci JSON.parse v JavaScriptuVidíš, já si dodnes myslel, že Javascript je programovací jazyk. Takže... na kterou z mnoha implementací se mám podívat? Nebo nechceš mi rovnou udělat statistiku kolik jich to řeší jakým způsobem?
j = eval('(' + text + ')'); Nedává smysl implementovat v JavaScriptu parser JSONu, i když by to samozřejmě šlo.
kde není JSON.parse/stringify k disposici nativněTohle je přesně ta varianta, o které jsem psal jako o výjimce, když není nativní implementace.
Po kontroleAle ta kontrola je tam velmi důležitá. Kdyby se dělal jenom eval, je to dost průser.
Ostatně na tomtéž principu funguje JSONP.
evalem reagoval, že to není pravda Ale dobře, řekněme, že mezi dělá se a správně by se mělo dělat je drobný rozdíl, který může v komunikačním šumu zaniknout
K JSONP: nejsem si jistý, jestli tě chápu, ale celý ten chytrý hack spočívá v tom, že klient dynamicky vytvoří element script, čímž zajistí vykonání načteného kódu v JavaScriptu, a server pošle JSONová data, která by normálně poslal, akorát obalená závorkami a na začátku ještě s textem, který klient zadá. Akorát že ošklivý server může poslat jakýkoli kód v JavaScriptu…
Ale dobře, řekněme, že mezi dělá se a správně by se mělo dělat je drobný rozdílKdyž napíšeš, že v Javascriptu se to dělá pomocí eval, nevyzní to jako "jednou z obvyklých chyb programátora je parsovat JSON funkcí eval". Ten drobný rozdíl tu tedy je, ale to, co jsi napsal v podstatě může znamenat obojí a vybral jsem si interpretaci, kterou jsi asi namysli neměl.
K JSONPTen jsem neznal. Moje chyba, je to přesně jak píšeš.
to co je opravdu zajimave se typove zabezpecit neda.
Pokud máte důkaz, že program má určité vlastnosti, není důvod, proč by ten důkaz neměl jít zapsat v typovém systému (vhodného jazyka).
No takhle, ja treba nemam nic proti tomu, jak je to udelano v Haskellu (i kdyz ho vlastne moc neznam). Tam totiz to odvozovani z vetsi casti dela ten jazyk za vas.
Problém je v tom, že typová inference je pro složitější typové systémy nerozhodnutelná (čímž samozřejmě nechci ospravedlňovat jazyky, které ji nepoužívají tam, kde by to šlo -- třeba Vámi zmíněná Java).
Nejvic by se mi asi libilo, kdyby ty asserty doplnoval pocitac na zaklade pozorovani behu programu. A programator by je pak jen schvalil. Chci vytvorit takovy jazyk, ale zatim jsem se k tomu nedostal.
To je zajímavá myšlenka, ale problém bude asi s tím, jak zařídit, aby počítač zobecnil konkrétní pozorování a vytvořil z nich "rozumné" asserty.
Mnohem lepsi by proste bylo, kdyby byla knihovna podminek, ktere ma ta datova struktura splnovatTímhle stylem je postavený Schematron – XML Schema není jediný způsob jak definovat „schéma“ v XML.
Ono takové DTD nebo kompaktní Relax NG taky nejsou samy o sobě XML, přestože se k validaci XML používají (a k definici schématu). Pak by se snad dosáhlo dokonalosti a nebylo by už potřeba vymýšlet další jazyk pro popis schématu
, open source verze je pod GPL.
Je to typické ženské vyjadřování.
) dekuji za tipy, jiz jsem si nakouknul stranky a budu to zkouset.
k Vasemu prispevku bych rad neco vic:
- napisu si XSL transformaci
ano, to je patrne ta spravna cesta, jak jsem vycetl z te volne pristupne knizky o XML od pana Koska (kterou jsem take ze zoufalstvi nahledl pri hledani moznych cest). Ona je to takova kratka veta a kdybychom to umeli, tak to asi ve firme i udelame. Ale my nechceme delat vsechno, my si u nas myslime, ze delba prace je ta spravna odpoved pri tvorbe software a proto jsme se poohledli, jestli by to pro nas nekdo nenapsal. Prekvapeni bylo, ze odpovidajici odbornici minili, ze zadny problem, udela se sezeni, nastartuje se projekt, zanalyzuji se pozadavky, .. blabla ... Cena odpovidajici.
Muzete to potvrdit a nebo se nekdo snazil vyuzit nasi neznalost.?
- Tex a ostatni
take jsme na to mysleli a pri otukavani te varianty jsem narazili na problematiku unicodu v Texu. Existuji dodatkove pakety a trochu jine pakety a k nim rada dokumentu, jak to naraficit, aby ten unicode (je potreba windows arial-sada) fungoval. To nas take znepokojilo.
Pod carou bych rekl, my jsme si mysleli, ze s XML prijde nejaky takovy format, kde bude mozno bez nejakych kurzu a skoleni ztreba i za pomoci _dostupnych_ nastroju provadet transformace do jinych formatu. To ale ne ten pripad.
12.6.2010 19:11
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Co chceš kam přidávat?add docbook...
A tohle jste už viděly? http://ogdl.sourceforge.net/
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.