Wenn ich eine POST -Anforderung mit einem JSON-Body an meinen REST -Dienst stelle, füge ich Content-type: application/json; charset=utf-8
in den Nachrichtenkopf ein. Ohne diesen Header erhalte ich eine Fehlermeldung vom Dienst. Ich kann Content-type: application/json
auch ohne den Teil ;charset=utf-8
erfolgreich verwenden.
Was genau macht charset=utf-8
? Ich weiß, es gibt die Zeichenkodierung an, aber der Dienst funktioniert auch ohne. Beschränkt diese Codierung die Zeichen, die im Nachrichtentext enthalten sein können?
Die Kopfzeile gibt nur an, in was der Inhalt codiert ist. Es ist nicht unbedingt möglich, den Typ des Inhalts aus dem Inhalt selbst abzuleiten, d. H. Sie können nicht unbedingt nur den Inhalt betrachten und wissen, was damit zu tun ist. Dafür sind HTTP-Header gedacht, die dem Empfänger mitteilen, mit welchen Inhalten sie (angeblich) zu tun haben.
Content-type: application/json; charset=utf-8
bezeichnet den Inhalt im JSON-Format, codiert in der UTF-8-Zeichencodierung. Das Festlegen der Codierung ist für JSON etwas redundant, da die Standardcodierung (nur?) Für JSON UTF-8 ist. In diesem Fall ist der empfangende Server anscheinend froh zu wissen, dass es sich um JSON handelt, und nimmt an, dass die Codierung standardmäßig UTF-8 ist. Aus diesem Grund funktioniert der Server mit oder ohne Header.
Beschränkt diese Codierung die Zeichen, die im Nachrichtentext enthalten sein können?
Nein. Sie können im Header und im Body alles senden, was Sie wollen. Wenn die beiden nicht übereinstimmen, erhalten Sie möglicherweise falsche Ergebnisse. Wenn Sie in der Kopfzeile angeben, dass der Inhalt UTF-8-codiert ist, Sie aber tatsächlich Latin1-codierten Inhalt senden, erzeugt der Empfänger möglicherweise Datenmüll und versucht, Latin1-codierte Daten als UTF-8 zu interpretieren. Wenn Sie natürlich angeben, dass Sie Latin1-codierte Daten senden und dies tatsächlich tun, sind Sie auf die 256 Zeichen beschränkt, die Sie in Latin1 codieren können.
Um die Behauptung von @ deceze zu untermauern, dass die Standard-JSON-Codierung UTF-8 ist ...
Von IETF RFC4627 :
JSON-Text MUSS in Unicode codiert sein. Die Standardkodierung ist UTF-8.
Da die ersten beiden Zeichen eines JSON-Textes immer ASCII Zeichen sind [RFC0020], kann festgestellt werden, ob ein Oktett-Stream UTF-8, UTF-16 (BE oder LE) oder UTF-16 (LE) ist. 32 (BE oder LE) durch Betrachten des Musters von Nullen in den ersten vier Oktetten.
00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8
Beachten Sie, dass IETF RFC4627 durch IETF RFC7158 ersetzt wurde. In Abschnitt [8.1] wird der zuvor von @Drew zitierte Text mit den folgenden Worten zurückgezogen:
Implementations MUST NOT add a byte order mark to the beginning of a JSON text.
Die Implementierung von Dart http verarbeitet die Bytes dank "charset = utf-8". Ich bin sicher, dass mehrere Implementierungen dies unterstützen, um den Fallback-Zeichensatz "latin-1" beim Lesen der Bytes aus der Antwort zu vermeiden. In meinem Fall geht das Format der Antworttextzeichenfolge vollständig verloren, sodass ich die Bytecodierung manuell für utf8 vornehmen oder diesen "inneren" Headerparameter in die API-Antwort meines Servers einfügen muss.
Ich stimme mit @deceze genau überein, aber ich möchte diesen "Ich erhalte einen Fehler vom Dienst" Teil der Frage entwickeln,
Wir erhalten diese Art von Fehlern als http 415
HTTP 415 Nicht unterstützter Medientyp-Fehler
Der HTTP 415-Client-Fehlerantwortcode "Nicht unterstützter Medientyp" gibt an, dass der Server die Anforderung nicht akzeptiert, da das Nutzdatenformat ein nicht unterstütztes Format aufweist.
Das Formatproblem kann auf den von der Anforderung angegebenen Inhaltstyp oder Inhaltscodierung oder auf das Überprüfen der Daten zurückzuführen sein direkt.
Mit anderen Worten, wie in https://stackoverflow.com/a/22643964/914284 diesem Beispiel dargestellt.