JavaScript array parsen in PHP

[bindsa]

Ik wil de volgende (dummy) Javascript array omzetten naar een PHP array:

JavaScript:

var data = [
  { 'foo': 1, 'bar': 2, 'foobar': [
    { 'foo': 'string', 'foo': 'string\x27\x27', 'foo': 'skddf' } ]
  },
  { 'foo': 1, 'bar': 2, 'foobar': [
    { 'foo': 'string', 'foo': 'string\x27\x27', 'foo': 'skddf' } ]
  },
];

Maar dingen als json_decode() e.d. werken niet goed. Er zitten namelijk ook ge-escapde chars in (\x27 o.a.).
Ik kan nu wel een hele hoop regex gaan schrijven, maar volgens mij is dat niet de beste methode.

Hoe zouden jullie dit aanpakken?

[RedRose]

Gebruik gewoon str_replace. Zoveel ge-escapete characters zijn er niet. Heb je ook de manual voor json_decode gelezen en dan met name het "Common mistakes using json_decode()" gedeelte?

[bindsa]

RedRose schreef op dinsdag 13 december 2011 @ 16:50:
Gebruik gewoon str_replace. Zoveel ge-escapete characters zijn er niet. Heb je ook de manual voor json_decode gelezen en dan met name het "Common mistakes using json_decode()" gedeelte?

Ik heb inderdaad ook al de ' gereplaced met " maar dan blijft hij nog hangen op die special chars. Is er geen betere methode voor die special chars? In het 'echt' zijn er namelijk wel veel ge-escapede chars.

[ Voor 6% gewijzigd door bindsa op 13-12-2011 16:58 ]

[RobIII]

\x27 is helemaal geen geldige escape sequence; daar zit je probleem. Wat jij wil is:

PHP:

$foo = json_decode('{"foo":"ba\'r"}');
var_dump($foo);
$foo = json_decode('{"foo":"ba\"r"}');
var_dump($foo);
$foo = json_decode("{\"foo\":\"ba'r\"}");
var_dump($foo);
$foo = json_decode("{\"foo\":\"ba\\\"r\"}");
var_dump($foo);
$foo = json_decode('{"foo":"ba\u0027r"}');
var_dump($foo);

Niet gaan lopen klooien met replace ofzo.

En om 't nog duidelijker te maken:

PHP:

$foo = <<<EOD
{"foo": "ba'r"}
EOD;

var_dump(json_decode($foo));

$foo = <<<EOD
{"foo": "ba\"r"}
EOD;

var_dump(json_decode($foo));

$foo = <<<EOD
{"foo": "ba\u0027r"}
EOD;

var_dump(json_decode($foo));

$foo = <<<EOD
{"foo": "ba\u0022r"}
EOD;

var_dump(json_decode($foo));

[ Voor 61% gewijzigd door RobIII op 13-12-2011 17:16 ]

[RedRose]

Idealiter stop je in json_decode een UTF-8 string met inderdaad alleen correcte escape sequences, maar dat doe je dan vanaf de javascript kant en je POST actie. Een hoop mensen lopen te klooien om dit goed te krijgen en deze comment heeft het ook over een bug in PHP < 5.2.6.

Maar goed, dan kan het ook zijn dat je het replace geklooi in JavaScript frommelt. Net zo veel geklooi.

RobIII schreef op dinsdag 13 december 2011 @ 17:07:
...code...

Denk dat t punt duidelijk is. Correcte sequences worden gewoon keurig meegenomen. Het punt voor mij is: hoe ga je zorgen dat je JSON in de eerste plaats correct is?

[ Voor 88% gewijzigd door RedRose op 13-12-2011 17:19 ]

[.oisyn]

RobIII schreef op dinsdag 13 december 2011 @ 17:07:
\x27 is helemaal geen geldige escape sequence

Oh, sinds wanneer niet?
.edit: ah, specifiek in JSON niet

[ Voor 9% gewijzigd door .oisyn op 13-12-2011 17:27 ]

[RobIII]

RedRose schreef op dinsdag 13 december 2011 @ 17:15:
Denk dat t punt duidelijk is. Correcte sequences worden gewoon keurig meegenomen. Het punt voor mij is: hoe ga je zorgen dat je JSON in de eerste plaats correct is?

Door het wiel niet opnieuw uit te vinden?

.oisyn schreef op dinsdag 13 december 2011 @ 17:24:

.edit: ah, specifiek in JSON niet

[ Voor 18% gewijzigd door RobIII op 13-12-2011 17:40 ]

[bindsa]

Goed, laat ik het iets anders formuleren. Ik heb deze data:

JavaScript:

var data = [
  { 'foo': 1, 'bar': 2, 'foobar': [
    { 'foo': 'string', 'foo': 'string\x27\x27', 'foo': 'skddf' } ]
  },
  { 'foo': 1, 'bar': 2, 'foobar': [
    { 'foo': 'string', 'foo': 'string\x27\x27', 'foo': 'skddf' } ]
  },
];

Hoe krijg ik die data in een PHP array? Ik heb geen invloed op de Javascript code, die lees ik in uit bestaande bestanden.

[RedRose]

.oisyn schreef op dinsdag 13 december 2011 @ 17:24:
[...]

Oh, sinds wanneer niet?
.edit: ah, specifiek in JSON niet

Wat dus de vraag oproept waar die sequence vandaan komt. Daar moet het eigenlijk worden opgelost. In any case, als vrij ranzige workaround werkt dit uiteraard wel, omdat hexadecimale sequences wel worden geintepreteerd door het gebruik van double quotes:

PHP:

$foo = json_decode("{\"foo\":\"string\x27\x27\"}");
var_dump($foo);

Maar goed, beter neem je RobIII's wijze raad aan en zorg je dat je JSON gewoon goed is.

[.oisyn]

Maar waaruit blijkt dat hij de json data als string literal in php heeft dan? Dat maak jij ervan. Het lijkt mij dat hij de json gewoon uitleest. En dus staat er letterlijk een slash in, itt in jouw voorbeeld.

Als het niet bij de bron op te lossen is is het natuurlijk vrij simpel om alle \xdd te replacen met \u00dd.

[bindsa]

Opgelost.

2 str_replace's maken er valide JSON van:

PHP:

            $data = str_replace("'", '"', $data);
            $data = str_replace('\x', '\u00', $data);

't is dat ik het niet bij de bron kan aanpakken, anders had ik het wel gedaan...

[RobIII]

T.H. Lassche schreef op dinsdag 13 december 2011 @ 21:15:
Opgelost.

2 str_replace's maken er valide JSON van:

En beiden vernachelen (potentieel) je data.

Auto's wordt Auto"s
\\server\apps\xen wordt \\server\apps\u00en

IMHO levenslijp en onacceptabel.
De eerste is, volgens mij, gewoon te vangen met 't correct escapen: ' vervangen met \' (waarbij je dan uiteraard rekening dient te houden met een reeds escaped sequence: \' moet natuurlijk \' blijven en niet \\' worden). De tweede is met een relatief simpele regex al een stuk "veiliger" te krijgen: even uit de losse pols iets als \\x([0-9a-f]{2,4}) vervangen met \u00$1 _{...waarbij je niet moet vergeten dat \\x ook weer escaped moet worden als je 't in preg_replace mikt ofzo}
...en dan nog steeds zijn 't, IMHO, lijpe workarounds voor diverse edge-cases. Hoe "niet bij de bron kunnen" hebben we 't hier over?

[ Voor 51% gewijzigd door RobIII op 13-12-2011 21:54 ]

[NMe]

.oisyn zei dan ook niet voor niks dit:

.oisyn schreef op dinsdag 13 december 2011 @ 20:04:
Als het niet bij de bron op te lossen is is het natuurlijk vrij simpel om alle \xdd te replacen met \u00dd.

Die dd zijn nogal belangrijk hier; je wil zeker weten dat je echt met een hexadecimale notatie te maken hebt. Dat doe je (mogelijk) met een regular expression-replace, niet met een normale string replace. /\\x[0-9a-f]{2}/ opzoeken en vervangen is veel robuuster.

Het apostrof-probleem is iets lastiger op te lossen, maar een mogelijke oplossing staat nota bene bovenaan in de comments op de manualpagina van json_decode.

edit:
Vuile RobIII en zijn edits.

[.oisyn]

RobIII schreef op dinsdag 13 december 2011 @ 21:35:
\\server\apps\xen wordt \\server\apps\u00en

Dat lijkt me sowieso geen valid JSON string. Het zou dan "\\\\server\\apps\\xen" moeten zijn.

Wat tevens betekent dat \\x12 ook een valide encoding is voor de string "\x12", dus de regex die jij voorstelt klopt ook niet. Er is wel een regex voor te verzinnen, maar het wordt knap harig en dan zit je nog met het apostroph probleem.

Wat ik in deze situatie waarschijnlijk zou doen is gewoon zelf een JSON decoder schrijven die het dialect van je input wel accepteert.

[RobIII]

.oisyn schreef op dinsdag 13 december 2011 @ 22:42:
Dat lijkt me sowieso geen valid JSON string.

Dat is 't ook niet; dat is de value van de string Evenals 't Auto's voorbeeld erboven

.oisyn schreef op dinsdag 13 december 2011 @ 22:42:
Wat tevens betekent dat \\x12 ook een valide encoding is voor de string "\x12", dus de regex die jij voorstelt klopt ook niet.

Wat je dus allemaal concludeert op een verkeerde aanname (als ik 't nog goed begrijp) en wat ook precies de reden is waarom ik:

RobIII schreef op dinsdag 13 december 2011 @ 21:35:
...uit de losse pols...
_{...waarbij je niet moet vergeten dat \\x ook weer escaped moet worden als je 't in preg_replace mikt ofzo}

schreef. Uiteindelijk wordt 't dus zoiets:

PHP:

$test = <<<EOD
Dit \\x69s een \\x27test\\x27 \\xenapp!
EOD;
echo preg_replace('/\\\\x([0-9a-f]{2,4})/i', '\\u00$1', $test);

Dit \u0069s een \u0027test\u0027 \xenapp!

Dit ga je echter niet kunnen decoden wegens de (nu nog aanwezige) \x zie ik nu. Dus ja, hairy wordt 't wel

Maar ik ruik een major we-lullen-weer-eens-langs-elkaar aankomen

[ Voor 4% gewijzigd door RobIII op 13-12-2011 23:16 ]

[.oisyn]

RobIII schreef op dinsdag 13 december 2011 @ 23:10:
[...]

Dat is 't ook niet; dat is de value van de string

Ik snap je niet. Bedoel je dat je het eerst door json_decode gaat gooien zodat je naderhand de escapes kan patchen? Want je dealt aanvankelijk met ongeëncodeerde json data. Een dergelijk server path is dus zo in JSON gespecificeerd:

JavaScript: data.json

{
    "server": "\\\\server\\apps\\xen"
}

Als je dat in PHP uit gaat lezen (uit een file of een HTTP request of POST data of whatever), dan heb je dus letterlijk JSON data bestaande uit 3 regels, waar het woord server voorgegaan wordt door 4 backslashes.

Dat de value van server uiteindelijk "\\server\apps\xen" wordt weet je pas ná het decoden. Maar je moet vóór het decoden de escape sequences aanpassen want anders snapt json_decode() het niet.

[ Voor 44% gewijzigd door .oisyn op 13-12-2011 23:23 ]

[RobIII]

.oisyn schreef op dinsdag 13 december 2011 @ 23:18:
Ik snap je niet.

Wat ik bedoel is dat TS hier een replace los laat op (voor wat ik begrijp) de data voor het decoden (dus: patchen van rauwe string zodat 't gedecode zou moeten kunnen worden).

.oisyn schreef op dinsdag 13 december 2011 @ 23:18:
Bedoel je dat je het eerst door json_decode gaat gooien zodat je naderhand de escapes kan patchen?

Nee, je moet 't patchen zodat 't gedecode kan worden. Maar, as said, dat wordt nogal hairy.

Laten we in ieder geval concluderen dat:
• Een str_replace geen goed idee is
• Een regex wellicht ietwat verlichting brengt
• Het schrijven van een eigen parser de enige optie is die je sluitend zou moeten kunnen krijgen
• Je gewoon moet zorgen dat de meuk fatsoenlijk escaped aangeleverd/uitgepoept/whatever wordt in-the-first-place

_{Ik ken m'n en/decoding en (un)escaping wel hoor}

[ Voor 3% gewijzigd door RobIII op 13-12-2011 23:29 ]

[bindsa]

RobIII schreef op dinsdag 13 december 2011 @ 23:27:
[...]

Wat ik bedoel is dat TS hier een replace los laat op (voor wat ik begrijp) de data voor het decoden (dus: patchen van rauwe string zodat 't gedecode zou moeten kunnen worden).


[...]

Nee, je moet 't patchen zodat 't gedecode kan worden. Maar, as said, dat wordt nogal hairy.

Laten we in ieder geval concluderen dat:
• Een str_replace geen goed idee is
• Een regex wellicht ietwat verlichting brengt
• Het schrijven van een eigen parser de enige optie is die je sluitend zou moeten kunnen krijgen
• Je gewoon moet zorgen dat de meuk fatsoenlijk escaped aangeleverd/uitgepoept/whatever wordt in-the-first-place

_{Ik ken m'n en/decoding en (un)escaping wel hoor}

Ben het nu aan het proberen met regexen, mocht dat niet lukken dan ga ik wel een eigen parser schrijven.

Nog 1 opheldering: De getoonde Javascript vindt je browser prima, valideert gewoon.

[RobIII]

T.H. Lassche schreef op dinsdag 13 december 2011 @ 23:34:
Ben het nu aan het proberen met regexen

Ik dacht dat inmiddels wel duidelijk was dat dat ook niet echt de way to go is.

T.H. Lassche schreef op dinsdag 13 december 2011 @ 23:34:
mocht dat niet lukken dan ga ik wel een eigen parser schrijven.

Ik ruik een NIH syndroompje... Waarom geef je geen antwoord op:

RobIII schreef op dinsdag 13 december 2011 @ 21:35:
Hoe "niet bij de bron kunnen" hebben we 't hier over?

Ik maak 't wel eens mee, maar in 9 v.d. 10 gevallen schop ik gewoon de leverancier en die zorgt maar dat 'ie 't fixed.

T.H. Lassche schreef op dinsdag 13 december 2011 @ 23:34:
Nog 1 opheldering: De getoonde Javascript vindt je browser prima, valideert gewoon.

Ik ben helemaal de draad kwijt en heb geen benul welke JS je op doelt en wat je nu opeens onder 'valideert gewoon' verstaat (in welke context).

[ Voor 5% gewijzigd door RobIII op 13-12-2011 23:40 ]

[bindsa]

RobIII schreef op dinsdag 13 december 2011 @ 23:39:
[...]

Ik dacht dat inmiddels wel duidelijk was dat dat ook niet echt de way to go is.


[...]

Ik ruik een NIH syndroompje... Waarom geef je geen antwoord op:

[...]

Ik maak 't wel eens mee, maar in 9 v.d. 10 gevallen schop ik gewoon de leverancier en die zorgt maar dat 'ie 't fixed.


[...]

Ik ben helemaal de draad kwijt en heb geen benul welke JS je op doelt en wat je nu opeens onder 'valideert gewoon' verstaat (in welke context).

Testvoorbeeldje:

HTML:

<html>
<head>
<script type="text/javascript">
function init() {
    var data = [
      { 'foo': 1, 'bar': 2, 'foobar': [
        { 'foo': 'string', 'foo': 'string\x27\x27', 'foo': 'skddf' } ]
      },
      { 'foo': 1, 'bar': 2, 'foobar': [
        { 'foo': 'string', 'foo': 'string\x27\x27', 'foo': 'skddf' } ]
      }
    ];
    for (var i = 0; i < data.length; i++) {
      var j = data[i];
      console.log(j);
    }
}
</script>
</head>
<body onload="init()">

</body>
</html>

Het gaat dus om tools die gewoon valide javascript uitspugen, waarvan ik de data met PHP moet parsen.

[.oisyn]

RobIII schreef op dinsdag 13 december 2011 @ 23:27:
[...]

Wat ik bedoel is dat TS hier een replace los laat op (voor wat ik begrijp) de data voor het decoden (dus: patchen van rauwe string zodat 't gedecode zou moeten kunnen worden).

Op de rauwe JSON data ja. Wat zit je dan te zeuren over de value van de string? Hij werkt niet op de value. De string die hij wil replacen is in dat serververhaal \\\\bla\\xen. En dus niet \\bla\xen zoals jij voorstelde.

RobIII schreef op dinsdag 13 december 2011 @ 21:35:
[...]

\\server\apps\xen wordt \\server\apps\u00en

.edit: oh wacht, ik snap de verwarring al. Ik denk in termen van de strings en hoe die gereplaced worden, jij aan hoe het er uiteindelijk uit komt te zien. \\\\server\\apps\\xen wordt \\\\server\\apps\\u00en, met als resultaat na de decode \\server\apps\u00en

T.H. Lassche schreef op dinsdag 13 december 2011 @ 23:51:

Testvoorbeeldje:
[..]
Het gaat dus om tools die gewoon valide javascript uitspugen, waarvan ik de data met PHP moet parsen.

Niemand heeft gezegd dat de data die jij hebt geen valide javascript is. Het is alleen geen valide JSON. JSON is slechts een subset van wat toegestaan is in Javascript. In Javascript kun je als value van een item ook een hele expressie opgeven die dan wordt uitgevoerd, inclusief functioncalls en alles. In JSON is dat echter niet toegestaan. Ik mag hopen dat je niet in staat hoeft te zijn om Javascript uit te voeren (zou ook nogal onveilig zijn)

[ Voor 51% gewijzigd door .oisyn op 14-12-2011 00:15 ]

[RobIII]

.oisyn schreef op woensdag 14 december 2011 @ 00:08:
.edit: oh wacht, ik snap de verwarring al. Ik denk in termen van de strings en hoe die gereplaced worden, jij aan hoe het er uiteindelijk uit komt te zien.

RobIII schreef op dinsdag 13 december 2011 @ 23:10:

Maar ik ruik een major we-lullen-weer-eens-langs-elkaar aankomen

[bindsa]

Niemand heeft gezegd dat de data die jij hebt geen valide javascript is. Het is alleen geen valide JSON. JSON is slechts een subset van wat toegestaan is in Javascript. In Javascript kun je als value van een item ook een hele expressie opgeven die dan wordt uitgevoerd, inclusief functioncalls en alles. In JSON is dat echter niet toegestaan. Ik mag hopen dat je niet in staat hoeft te zijn om Javascript uit te voeren (zou ook nogal onveilig zijn)

Klopt, maar werken met JSON leek me het handigst, omdat het dialect daar al veel op leek, maar het heeft tot nu toe meer voeten in de aarde dan ik dacht.

[bindsa]

Het ene probleem, de escape sequences, heb ik nu redelijk dichtgetimmerd met RegEx:

PHP:

$test = <<<EOD 
Dit \\x69s een \\x27test\\x27 \\xenapp! 
EOD;
echo preg_replace('/(?<=[^\\\])(\\\x)([0-9a-f]{2})/', "\u00$2", $test);

Resultaat:

Dit \u0069s een \u0027test\u0027 \xenapp!

Nu ben ik bezig met een RegEx voor de andere.

[RobIII]

Je regex klopt nog niet; \x3F (?) zal niet vervangen worden \x3f wel. Ook gaat 't alsnog mis met, bijvoorbeeld iets als:

PHP:

$test = <<<EOD
Systeem: Windows 7\\ultimate\\x64
EOD;
echo preg_replace('/(?<=[^\\\])(\\\x)([0-9a-f]{2})/', "\u00$2", $test);

Maar ik probeer 't nog een keer:

RobIII schreef op dinsdag 13 december 2011 @ 23:39:
Waarom geef je geen antwoord op:

          "Hoe "niet bij de bron kunnen" hebben we 't hier over?"

Ik maak 't wel eens mee, maar in 9 v.d. 10 gevallen schop ik gewoon de leverancier en die zorgt maar dat 'ie 't fixed.

Geloof me; dit is een disaster waiting to happen. Wil je enigszins zekerheid hebben dan los je 't op bij de bron en nergens anders.

[ Voor 54% gewijzigd door RobIII op 14-12-2011 14:08 ]

[bindsa]

RobIII schreef op woensdag 14 december 2011 @ 14:04:
Je regex klopt nog niet; \x3F (?) zal niet vervangen worden \x3f wel. Ook gaat 't alsnog mis met, bijvoorbeeld iets als:

PHP:

$test = <<<EOD
Systeem: Windows 7\\ultimate\\x64
EOD;
echo preg_replace('/(?<=[^\\\])(\\\x)([0-9a-f]{2})/', "\u00$2", $test);

Maar ik probeer 't nog een keer:


[...]


Geloof me; dit is een disaster waiting to happen. Wil je enigszins zekerheid hebben dan los je 't op bij de bron en nergens anders.

GRMBL Maar nu werkt het wel:

PHP:

    $test = <<<'EOD'
    Systeem: Windows 7\\ultimate\\x64
EOD;
    echo preg_replace('/(?<!\\\)([\\\])(x)([0-9a-fA-F]{2})/', "\u00$3", $test);
    

    $test = <<<'EOD'
    Dit \\x69s een \\x27test\\x27 \x27 \\xenapp!
EOD;
    var_dump($test);
    echo preg_replace('/(?<!\\\)([\\\])(x)([0-9a-fA-F]{2})/', "\u00$3", $test);

Wat betreft de bron: 100% mee eens, maar ik kan er in dit geval echt niets aan doen.

Anyway, zo haal ik m'n RegEx kennis weer een beetje op.

Wat betreft de quotes heb ik nu dit in elkaar geprutst:

PHP:

        $string = preg_replace('/"/', '\"', $string);
        $string = preg_replace("/\\\'/", "{SINGLE_QUOTE}", $string);
        $string = preg_replace("/'/", "\"", $string);
        $string = preg_replace("/\{SINGLE_QUOTE\}/", "'", $string);

 ' " \' ' ==> " \" ' "

Dit werkt onder de aanname dat er alleen key/values zijn die met single quotes omringd zijn, en dus geen key/values die met dubbele quotes omringd zijn. Maar dat is in mijn geval ook zo.

[ Voor 26% gewijzigd door bindsa op 14-12-2011 14:33 ]

[Janoz]

Ach, garbage in garbage out. Je kunt stront wel in leuke taartvormpjes drukken, het blijft stinken.

Tot slot is er altijd wel wat aan de bron te doen. Als jij het niet kunt dan moet je zelf maar hoger in de boom.

[.oisyn]

T.H. Lassche schreef op woensdag 14 december 2011 @ 14:27:
[...]


GRMBL Maar nu werkt het wel:

Nee hoor Nu convert je \\x64 weliswaar niet, maar \\\x64 ook niet, terwijl dat gewoon \\\u0064 moet worden.

[ Voor 50% gewijzigd door .oisyn op 14-12-2011 14:50 ]

[bindsa]

.oisyn schreef op woensdag 14 december 2011 @ 14:40:
[...]

Nee hoor Nu convert je \\x64 weliswaar niet, maar \\\x64 ook niet, terwijl dat gewoon \\\u0064 moet worden.

Ah crap, dit is niet te doen Ik ga maar een mini parser bouwen.

[Cartman!]

T.H. Lassche schreef op woensdag 14 december 2011 @ 14:57:
Ah crap, dit is niet te doen

Dus moet je toch maar eens bij je projectmanager gaan aangeven dat je hier niet mee kunt werken. Je kan onmogelijk al die uitzonderingen goed gaan afvangen. Nu is het x64 en morgen is het xc1.

[.oisyn]

Een miniparser voor je JSON-dialect is vrij simpel te maken (tip: gebruik een parser generator), de productieregels staan vrij duidelijk op json.org.

Meanwhile, in oisynville

PHP:

$test = "\\x64 \\\\x64 \\\\\\x64 \\\\\\\\x64";
$regex = '/(^|[^\\\\]|(^|[^\\\\])(\\\\\\\\)+)\\\\x([0-9a-fA-F]{2})/';
echo preg_replace($regex, '\\1\\u00\\4', $test);

In gewoon Nederlands: replace alle \xdd die voorgegaan zijn door:
- niets
- geen backslash
- een even aantal backslashes (die zelf weer alleen voorgegaan mogen worden door danwel niets danwel geen backslash)

Waarom PHP vandaag de dag nog altijd geen syntax heeft voor regexen of voor strings zonder escape sequences is me een raadsel.

.edit: deze is iets simpeler

PHP:

$regex = '/(?<!\\\\)((\\\\\\\\)*)\\\\x([0-9a-fA-F]{2})/';

Replace alle \xdd die voorgegaan zijn door geen backslash optioneel gevolgd door een even aantal backslashes

[ Voor 52% gewijzigd door .oisyn op 14-12-2011 19:41 ]

[Killemov]

Even voor de duidelijkheid ... TS, spugen de door jou genoemde tools uit:
- valide JSON?
- valide Javascript?
- valide HTML met DAARIN valide Javascript?

[bindsa]

Killemov schreef op zaterdag 17 december 2011 @ 13:21:
Even voor de duidelijkheid ... TS, spugen de door jou genoemde tools uit:
- valide JSON?
- valide Javascript?
- valide HTML met DAARIN valide Javascript?

Dat laaste. Maar ik heb het inmiddels al redelijk voor elkaar. In ieder geval bedankt.