AJAX - JSON.stringify - Sonderzeichen

[dedlfix]

Tach!

Das würde mit allen Daten passieren, die so transportiert werden.

Nein eben nicht! Wenn nämlich der Content-Type 'application/x-www-form-urlencoded' gesendet wid, arbeitet der Parser entsprechend und deutet & als Trennzeichen sowie + als Leerzeichen (siehe auch RFC 3986). Somit ist es nicht nur unsinnig sondern auch falsch ein data=$json zu senden und dann in das $_POST Array zu greifen.

Und was daran ist "Nein eben nicht!"? Genau das ist doch das Problem, das das zu den Symptomen des OP passt. Also keinen Content-Typ angegeben oder den Default-Wert 'application/x-www-form-urlencoded' und die Daten vergessen zu maskieren. Das passiert mit jeglichen Daten, die so unmaskiert transportiert werden, nicht nur mit JSON.

Wenn das Nein vielmehr heißen sollte, man könne im Falle von JSON einen anderen Content-Type nehmen - ja klar, ändert aber nichts daran, dass man bei 'application/x-www-form-urlencoded' maskieren muss.

Trotzdem ist es nicht generell falsch, data=$json zu senden, es muss eben nur data=encodeURIComponent($json) draus gemacht werden. Solange der serverseitige Prozess das genauso erwartet, und wenn man keine öffentliche API schreibt, sondern nur die eigene Anwendung das so verwendet, sehe ich auch keinen Grund, das unnötig hübsch zu gestalten.

Wenn das bei Dir so üblich ist, hast Du den Sinn des Request-Content-Type nicht verstanden, aber diesen Eindruck hatte ich ja gestern schon.

Ich habe das schon verstanden.

Also entweder 'application/x-www-form-urlencoded' ODER 'application/json' senden und selbstverständlich muss das serverseitige Parsen dem im Request mitgegebenen Content-Type entsprechend erfolgen. Andererseits ist es auch unsinnig, ein Percent-Encoding gem. RFC 3986 in JSON-Strings anzuwenden.

Weil JSON nicht eine Componente von 'application/x-www-form-urlencoded' ist sondern einen eigenen Content-Type darstellt!

JSON ist nicht nur application/json, JSON ist auch text/plain oder auch binary/octet-stream. Oder anders gesagt, man kann JSON auch einfach nur als eine beliebige Zeichenfolge betrachten und sie zum Übertragen in einen anderen Container stecken. Das ist nicht falsch, muss sich aber wie jede andere beliebige Zeichenfolge an die Regeln des Containers halten.

Man könnte beispielsweise zusätzlich zum JSON auch noch andere Daten mitsenden wollen. Die würde man bei application/json nicht übertragen bekommen (höchstens als Header-Zeilen), ohne dass man sie in das JSON einbaut. Das kann aber je nach Anwendungsfall auch ungewünscht sein. Wenn z.B. der JSON-Teil einen Datensatz darstellt, den man nicht mit den anderen Daten vermischen möchte, dann kann man beispielsweise application/x-www-form-urlencoded und data=encodeURIComponent($json)&anderes=encodeURIComponent($anderes) verwenden.

PS: Die ++Bewertung Deiner Beiträge sagt mir, dass hier einiges im Argen liegt.

Das glaube ich auch. Zum Beispiel, dass du dich zu sehr in deiner eigenen Welt mit Perl, EAV und Binärdatenübertragung eingekuschelt hast, und so nicht mehr siehst, dass es noch jede Menge anderer Wege gibt.

dedlfix.