Beitrag zur Übermittlung von HTML-Daten_PowerNode Java Academy

Zu den vom HTTP/1.1-Protokoll angegebenen HTTP-Anforderungsmethoden gehören OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE und CONNECT. POST wird im Allgemeinen verwendet, um Daten an den Server zu senden. In diesem Artikel werden hauptsächlich verschiedene Möglichkeiten zum Senden von Daten mit POST erläutert.

Wir wissen, dass das HTTP-Protokoll im ASCII-Code übertragen wird und eine auf dem TCP/IP-Protokoll basierende Anwendungsschichtspezifikation ist. Die Spezifikation unterteilt HTTP-Anfragen in drei Teile: Statuszeile, Anforderungsheader und Nachrichtentext. Es sieht so aus:

<Methode> <Anforderungs-URL> <Version>
<Kopfzeilen>
<Entitätskörper></Entitätskörper></Header></Version></Anforderungs-URL></Methode>

Das Protokoll legt fest, dass die per POST übermittelten Daten in den Nachrichtentext (Entity-Body) eingefügt werden müssen. Das Protokoll legt jedoch nicht fest, welche Codierungsmethode für die Daten verwendet werden muss. Tatsächlich können Entwickler das Format des Nachrichtentexts vollständig selbst festlegen, solange die endgültig gesendete HTTP-Anforderung dem oben genannten Format entspricht.

Die Daten sind jedoch nur dann aussagekräftig, wenn sie vom Server erfolgreich analysiert werden. Allgemeine serverseitige Sprachen wie Java und ihre Frameworks verfügen über integrierte Funktionen zum automatischen Parsen gängiger Datenformate. Der Server erfährt normalerweise anhand des Felds „Content-Type“ im Anforderungsheader, wie der Nachrichtentext in der Anforderung codiert ist, und analysiert dann den Text. Das POST-Datenübermittlungsschema umfasst also zwei Teile: Inhaltstyp und Methode zur Kodierung des Nachrichtentexts. Lassen Sie uns nun damit beginnen, sie offiziell vorzustellen.

Anwendung/x-www-form-urlencoded

Dies dürfte die gängigste Methode zum Übermitteln von Daten per POST sein. Wenn das Attribut „enctype“ für das native Formular des Browsers nicht festgelegt ist, werden die Daten letztendlich im Format „application/x-www-form-urlencoded“ übermittelt. Die Anfrage sieht folgendermaßen aus (irrelevante Anfrageheader werden in diesem Artikel weggelassen):

POST http://www.example.com HTTP/1.1
Inhaltstyp: application/x-www-form-urlencoded; Zeichensatz=utf-8
Titel=Test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

Zunächst wird der Inhaltstyp als application/x-www-form-urlencoded angegeben. Zweitens werden die übermittelten Daten in der Form key1=val1&key2=val2 codiert und sowohl key als auch val sind URL-codiert. Die meisten serverseitigen Sprachen unterstützen diesen Ansatz gut. Beispielsweise kann in PHP POST['title'] den Wert von title abrufen, POST['title'] den Wert von title abrufen und _POST['sub'] das Unterarray abrufen.

Häufig verwenden wir diese Methode auch, wenn wir Daten mit Ajax übermitteln. Für JQuery Ajax ist der Standardwert von Content-Type beispielsweise „application/x-www-form-urlencoded; charset=utf-8“.

mehrteilige/Formulardaten

Dies ist eine weitere gängige Möglichkeit zum Senden von POST-Daten. Wenn wir ein Formular zum Hochladen einer Datei verwenden, müssen wir den Verschlüsselungstyp des Formulars auf diesen Wert setzen. Schauen wir uns ein Anfragebeispiel an:

POST http://www.example.com HTTP/1.1
Inhaltstyp: multipart/Formulardaten; Grenze=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Inhaltsdisposition: Formulardaten; Name="Text"
Titel
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Inhaltsdisposition: Formulardaten; Name="Datei"; Dateiname="chrome.png"
Inhaltstyp: image/png
PNG … Inhalt von chrome.png …
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

Dieses Beispiel ist etwas komplizierter. Zunächst wird eine Grenze erzeugt, um die verschiedenen Felder voneinander zu trennen. Um eine Duplizierung mit dem Haupttextinhalt zu vermeiden, ist die Grenze sehr lang und komplex. Dann gibt der Inhaltstyp an, dass die Daten in Multipart-/Formulardaten codiert sind und wo die Grenze dieser Anfrage liegt. Der Nachrichtentext ist je nach Anzahl der Felder in mehrere ähnlich strukturierte Teile unterteilt. Jeder Teil beginnt mit --boundary, gefolgt von Inhaltsbeschreibungsinformationen, dann einem Wagenrücklauf und schließlich dem spezifischen Inhalt des Felds (Text oder Binär). Wenn die Datei übertragen wird, müssen auch der Dateiname und die Dateitypinformationen enthalten sein. Der Nachrichtentext endet mit dem Tag --boundary--. Die detaillierte Definition von „Multipart/Formulardaten“ finden Sie in rfc1867.

Diese Methode wird im Allgemeinen zum Hochladen von Dateien verwendet und wird auch von den wichtigsten serverseitigen Sprachen gut unterstützt.

Die beiden oben genannten Methoden zum POSTen von Daten werden beide nativ von Browsern unterstützt, und derzeit unterstützen native Formulare nur diese beiden Methoden. Da jedoch immer mehr Websites, insbesondere WebApps, Ajax zur Dateninteraktion verwenden, können wir neue Methoden zur Datenübertragung definieren, um die Entwicklung komfortabler zu gestalten.

Anwendung/Json

Sie müssen mit dem Content-Type application/json als Antwortheader vertraut sein. Tatsächlich verwenden es immer mehr Leute als Anforderungsheader, um dem Server mitzuteilen, dass der Nachrichtentext eine serialisierte JSON-Zeichenfolge ist. Aufgrund der Popularität der JSON-Spezifikation unterstützen alle gängigen Browser mit Ausnahme der niedrigeren IE-Versionen JSON.stringify nativ, und serverseitige Sprachen verfügen auch über Funktionen zur Verarbeitung von JSON, sodass bei der Verwendung von JSON keine Probleme auftreten.

Es ist auch nützlich, dass das JSON-Format strukturierte Daten unterstützt, die viel komplexer sind als nur Schlüssel-Wert-Paare. Ich erinnere mich, dass bei meiner Arbeit an einem Projekt vor ein paar Jahren die zu übermittelnde Datenebene sehr tief war, sodass ich die Daten vor der Übermittlung in JSON serialisiert habe. Ich habe jedoch die JSON-Zeichenfolge als Wert verwendet, sie trotzdem in das Schlüssel-Wert-Paar eingefügt und im Format x-www-form-urlencoded übermittelt.

Die Ajax-Funktion in Google AngularJS übermittelt standardmäßig eine JSON-Zeichenfolge. Beispielsweise der folgende Code:

var Daten = {'Titel':'Test', 'Sub': [1,2,3]};
$http.post(url, daten).erfolg(funktion(ergebnis) {
...
});

Die letzte gesendete Anfrage lautet:

POST http://www.example.com HTTP/1.1
Inhaltstyp: application/json;charset=utf-8
{"Titel":"Test","Sub":[1,2,3]}

Diese Lösung kann problemlos komplex strukturierte Daten übermitteln und ist besonders für RESTful-Schnittstellen geeignet. Wichtige Tools zur Paketerfassung, wie die in Chrome integrierten Entwicklertools, Firebug und Fiddler, zeigen JSON-Daten in einer Baumstruktur an, was sehr benutzerfreundlich ist. Einige serverseitige Sprachen unterstützen diese Methode jedoch noch nicht. Beispielsweise kann PHP den Inhalt der obigen Anforderung nicht über das $_POST-Objekt abrufen. Zu diesem Zeitpunkt müssen Sie es selbst tun: Wenn der Inhaltstyp im Anforderungsheader application/json ist, holen Sie sich den ursprünglichen Eingabestream von php://input und decodieren Sie ihn dann per json in ein Objekt. Einige Java-Frameworks haben bereits damit begonnen.

Natürlich kann AngularJS auch so konfiguriert werden, dass Daten mit x-www-form-urlencoded übermittelt werden.

text/xml

XML-RPC (XML-Remoteprozeduraufruf). Es handelt sich um eine Remote-Calling-Spezifikation, die HTTP als Übertragungsprotokoll und XML als Kodierungsmethode verwendet. Eine typische XML-RPC-Anfrage sieht folgendermaßen aus:
POST http://www.example.com HTTP/1.1
Inhaltstyp: text/xml
<!--?xml version="1.0"?-->
<Methodenaufruf>
<Methodenname>Beispiele.getStateName</Methodenname>
<Parameter>
<Parameter>
<Wert><i4>41</i4></Wert>
</params>
</Methodenaufruf>

Das XML-RPC-Protokoll ist einfach, funktional und verfügt über Implementierungen in verschiedenen Sprachen. Es wird auch häufig verwendet, beispielsweise als XML-RPC-API von WordPress, im Ping-Dienst von Suchmaschinen usw. In JavaScript gibt es auch vorgefertigte Bibliotheken, die diese Dateninteraktion unterstützen und vorhandene XML-RPC-Dienste gut unterstützen können. Ich persönlich denke jedoch, dass die XML-Struktur immer noch zu aufgebläht ist und JSON für allgemeine Szenarien flexibler und praktischer ist.