multipart/form-data Neulich habe ich die Kommunikationsverarbeitung mit HttpURLConnection von Java implementiert. Unter anderem habe ich einen Teil erstellt, der universell im Multipart- / Formulardatenformat gesendet werden kann, aber aus irgendeinem Grund nicht als Anforderung für Multipart- / Formulardaten erkannt wird, unabhängig davon, wie oft kommuniziert wird, und es dauert eine beträchtliche Zeit, um ihn aufzulösen. Ich habe es ausgegeben.
Die Ursache ist sehr lächerlich, gibt es noch jemanden, der davon abhängig ist? Es war so, aber ich würde es gerne als Memorandum schreiben.
Übrigens, als ich es zuerst schrieb, war es die Ursache.
Der allgemeine ist so. Die im folgenden Format zusammengestellten Inhalte werden auf den Körper gelegt und kommuniziert.
multipart/form-Datenbestand
--[Grenzzeichenfolge]
Content-Disposition: form-data; name="[Formularname]"
<<Formularinhalt>>
--[Grenzzeichenfolge]
Content-Disposition: form-data; name="[Formularname]"; filename="[Dateiname]"
Content-Type: text/plain
<<Dateiinhalt>>
--[Grenzzeichenfolge]
・
・
・
Fährt so viel fort, wie Sie senden
・
・
・
--[Grenzzeichenfolge]--
Schreiben Sie den Inhaltstyp des Anforderungsheaders nach mehrteiligen / Formulardaten und die Grenzzeichenfolge nach dem Inhaltstyp. Der Zeilenvorschubcode muss CRLF sein.
Betrachtet man den Anforderungshauptteil der gesendeten Anforderung, so gibt es im Vergleich zum obigen Format keine Anzeichen von Missverständnissen, und es besteht kein Zweifel daran, dass die Grenzspezifikation des Inhaltstyps im Anforderungsheader korrekt ist. Hmm?
Wenn Sie von Postman im Formulardatenformat kommunizieren und es mit einer Anfrage vergleichen, die normal erkannt wird,
multipart/form-Datenbestand
--[Grenzzeichenfolge]
Es gab kein erstes "-". .. Anfangs war ich mit dem Mechanismus von Mehrteil- / Formulardaten nicht sehr vertraut, daher habe ich mich auf die Sites im Netz bezogen, aber auf verschiedene Sites als Grenzzeichenfolge "-------- zufällige Zeichenfolge". Da es sich um eine Spezifikation handelte, habe ich sie gelernt und die Zeichenkette am Anfang mit "--------" angegeben, und es wurde nicht erkannt, dass am Anfang ein separates "-" erforderlich war. Es war, weil es schwierig war zu bestätigen, ob es tatsächlich entfernt wurde. (Es ist eine Geschichte, RFC richtig zu lesen.)
Das letzte Trennzeichen muss übrigens ein "-" hinter sich haben! (Erinnerung)
Der Glaube ist beängstigend.
Schreiben Sie es auf, damit niemand mit ähnlichen Inhalten hängen bleibt. (Gibt es so eine Person?)
Übrigens werden beim Testen der HTTP-Kommunikation die folgenden Sites empfohlen. Es gibt Endpunkte, die Informationen über von GET oder POST gesendete Anforderungen in Form von JSON, binären Antworten und verschiedenen anderen Endpunkten zurückgeben, also einfache Kommunikation Sie können die Kommunikation auch ziemlich sicher anhand der Bestätigung des Inhalts testen.
Wenn Sie es nicht wissen, verwenden Sie es bitte. Fortschritte machen. httpBin: https://httpbin.org/
Recommended Posts