1. Get wird verwendet, um Daten vom Server zu erhalten, während Post zum Übergeben von Daten an den Server verwendet wird.
2. Get fügt die Daten im Formular zur URL hinzu, auf die durch die Aktion in Form von Variable = Wert vermerkt ist, und verwendet a? Verbindung zwischen den beiden, während die & Verbindung zwischen jeder Variablen; Post soll die Daten in der Form in der Datenbehörde platzieren und an die URL weitergeben, auf die die Aktion in der Art und Weise wie die Variable und den Wert dem Wert entspricht.
3. Get ist nicht sicher, da während des Übertragungsprozesses Daten in die angeforderte URL eingereicht werden. Heutzutage zeichnen viele vorhandene Server, Proxy -Server oder Benutzeragenten die angeforderte URL in der Protokolldatei auf und platzieren sie dann irgendwo, damit einige Datenschutzinformationen von Dritten angezeigt werden. Darüber hinaus können Benutzer die übermittelten Daten im Browser direkt sehen, und einige interne Systemnachrichten werden vor dem Benutzer angezeigt. Alle Operationen von Post sind für den Benutzer unsichtbar.
V. und Post kann eine große Datenmenge übertragen, sodass Sie beim Hochladen von Dateien nur Post verwenden können (natürlich gibt es einen weiteren Grund, der später erwähnt wird).
5. Beschränken Sie den Wert des Datensatzes von Formularen als ASCII -Zeichen. Während Post den gesamten ISO10646 -Zeichensatz unterstützt. Standardmäßig ISO-8859-1 Codierung
6. Get ist die Standardmethode des Formulars.
Der folgende Vergleich ist sehr, sehr nützlich:
Ich arbeite schon eine Weile an Java Web Development, und es gibt ein Problem, das mich immer stört, was das Problem der verstümmelten. Grundsätzlich suche ich online nach Lösungen (es gibt wirklich viele Online -Informationen), und alle stellen vor, wie man solche verstümmelten Probleme löst, aber nur wenige von ihnen erklären die ganze Geschichte des Problems klar. Nachdem ich einige Artikel gelesen habe, verstehe ich es manchmal, aber in der Entwicklung kommt das verstümmelte Problem wie ein Geist heraus und ist wirklich eine große Sache! Dieser Artikel ist eine Anhäufung eines Verständnisses meines langfristigen Kampfes mit verstümmelten Codes, und ich hoffe, dass mehr Freunde mir Ratschläge und Nahrungsergänzungsmittel geben.
Es gibt 2 Methoden für das Formular zum Senden von Daten an den Server. Lassen Sie uns über Get und Post sprechen.
(I) Einreichung erhalten
1. Lassen Sie uns zunächst darüber sprechen, wie Sie die Daten codieren und sie mit der GET -Methode an den Server senden.
Für die GET -Methode werden Daten nach der angeforderten URL als Parameter verkettet, wie z. B. http: // localhost: 8080/servlet?
(Ein sehr häufiges Problem des verstümmelten Codes wird angezeigt. Wenn in der URL chinesische oder andere Sonderzeichen angezeigt werden, wie z. B. http: // localhost: 8080/servlet? Der Prozess der URL-Encode dient darin, einen Teil der URL als Zeichen zu codieren und nach einer bestimmten Codierungsmethode in einen Binär-Byte-Code zu codieren (z. B. UTF-8, GBK usw.), und dann wird jedes Byte durch eine String- %-XY, die 3 Zeichen enthält, dargestellt, wobei XY die zwei Bit hexadezimale Darstellung des Bytes ist. Was ich hier gesagt habe, ist vielleicht nicht klar. Weitere Informationen finden Sie in der Einführung der Java.net.urlencoder -Klasse hier. Nachdem wir den Prozess der URL -Enkodierung verstanden haben, können wir zwei sehr wichtige Fragen sehen. Erstens: Die Zeichen, die eine URL-Enkodierung erfordern, sind im Allgemeinen Nicht-ASCII-Zeichen (im Allgemeinen). In einfachen Worten müssen alle englischen Buchstaben (wie Chinesen, Japanisch usw.) eine URL -Enkodierung durchführen. Daher wird die URL -Encode für uns nicht verstümmelt, wenn der Server verstümmelt wird. Der verstümmelte Code wird durch die URL verursacht, die chinesische oder Sonderzeichen in der URL enthält. Zweitens: In welcher Codierungsmethode codieren URL Zeichen? Dies ist das Geschäft des Browsers, und verschiedene Browser haben unterschiedliche Praktiken. Chinesische Versionen von Browsern verwenden im Allgemeinen standardmäßig GBK. UTF-8 kann auch durch Einstellen des Browsers verwendet werden. Unterschiedliche Benutzer haben möglicherweise unterschiedliche Browsereinstellungen, was zu unterschiedlichen Codierungsmethoden führt. Daher verwenden viele Websites die URL -Enkodus zuerst, indem sie JavaScript für die chinesischen oder Sonderzeichen in der URL verwenden und dann die URL zum Senden von Daten spleißen, dh eine URL -Enkodierung für den Browser. Der Vorteil besteht darin, dass die Website die Codierungsmethode zum Senden von Daten vereinen kann. Nach Abschluss der URL-Encode wird die aktuelle URL zu einem Zeichen innerhalb des ASCII-Bereichs und wandelt sie dann in der Codierungsmethode von ISO-8859-1 in binäre und wird zusammen mit dem Anforderungsheader gesendet. Ich möchte hier etwas mehr sagen, als für die GET -Methode keine Anforderungsentität und die URL, die Daten enthalten, im Anforderungsheader enthalten. Der Grund, warum ich eine URL -Encode verwende, ist: Für den Anforderungsheader müssen die reinen Daten des Anforderungsheaders in Binary 101010 codiert werden. Am Ende müssen reine Daten des Anforderungsheaders im Internet übertragen werden. Wenn Sie Sonderzeichen wie chinesische und andere Zeichen ISO-8859-1 direkt codieren, gehen die Informationen verloren, sodass zuerst URL-Enkodierung erforderlich ist.
2. Wie erhält die Serverseite (Tomcat) die Daten für die Dekodierung?
Der erste Schritt besteht darin, die Daten mit ISO-8859-1 zu dekodieren. Für die GET -Methode erhält Tomcat die Datenheaderzeichen im ASCII -Bereich und die Anforderungs -URL enthält Parameterdaten. Wenn es Sonderzeichen wie Chinesen im Parameter gibt, ist es nach der URL -Enkodierung immer noch der %xy -Zustand. Stoppen wir zuerst, lassen Sie uns über den allgemeinen Prozess des Erhaltens von Daten durch Entwickler sprechen. Normalerweise erhält jeder Parameterdaten. Das von uns erhaltene Anforderungsobjekt oder Daten ist dekodiert, das Programm kann es jedoch während des Dekodierungsprozesses nicht angeben. Hier müssen wir sagen, dass viele Neulinge sagen, dass die Verwendung von Request.setcharactercoding (Zeichensatz) die Dekodierungsmethode angeben kann, aber tatsächlich nicht möglich ist . Wenn man sich die offizielle API des Servlets ansieht, gibt es eine Erklärung für diese Methode: Überschreibt den Namen der Charaktercodierung, die im Körper dieser Anfrage verwendet wird. Diese Methode muss vor dem Lesen von Anforderungsparametern oder dem Lesen der Eingaben mit GetReader () aufgerufen werden. Es ist zu sehen, dass er machtlos etwas gegen die Get -Methode unternehmen kann. Welche Codierungsmethode wird zum Dekodieren von Daten verwendet? Dies ist Tomcats Geschäft. Die Standardeinstellung ist ISO-8859-1, sodass wir feststellen, warum die GET-Anforderung chinesische Parameter enthält und warum der verstümmelte Code auf der Serverseite erhalten wird. Der Grund dafür ist, dass UTF-8 oder GBK normalerweise zur Codierung der Daten-URL-Enkodierung verwendet wird. Hier ist der URL -Decoder offensichtlich nicht möglich. Im Programm können wir direkt
Java -Code
1. Neue String (Request.GetParameter (Name) .getBytes (ISO-8859-1), die vom Client angegebene URL-Encodierungsmethode)
Stellen Sie die Bytecode wieder her und dekodieren Sie die Daten richtig. Online -Artikel erstellen normalerweise eine Konfiguration in Tomcat
XML -Code
1. <Anschlussanschluss = 8080 Protokoll = HTTP/1.1 Maxthreads = 150 ConnectionTimeout = 20000 RedirectPort = 8443 URiencoding = GBK/>
Auf diese Weise kann Tomcat die angegebene Methode zum Abrufen der Daten verwenden. Die Einführung des URL -Decoders ist hier
(I) Posteinreichung
1. So codieren Sie die Daten und senden Sie sie mit der Post -Methode des Clients (Browser) an den Server.
Die Daten, die in der Post -Methode übertragen werden sollen, müssen auch eine URL -Enkodierung sein. Welche Codierungsmethode verwendet sie also?
Wenn es ein Segment gibt <meta http-äquiv = content-type content = text/html; charSet = Zeichensatz (GBK, UTF-8 usw.) in der HTML-Datei, in der sich das Formular befindet, und dann wird der Beitrag in der hier angegebenen Codierungsmethode codiert. Im Allgemeinen glaubt jeder, dass dieser Code den Browser wissen soll, welcher Zeichen für die Interpretation der Webseite gesetzt wird, sodass die Website ihn am vorderen Ende des HTML -Codes platziert und versucht, nicht verstümmelte Code zu erscheinen. Tatsächlich hat es auch eine andere Funktion, um die URL -Codierungs -Codierungsmethode der Post -Form -Form -Methode zum Senden von Daten anzugeben . Von hier aus können wir sehen, dass die URL -Codierungsmethode des Browsers für die GET -Methode durch die Browsereinstellungen bestimmt wird (kann in JS für einheitliche Spezifikationen angegeben werden) und die Postmethode kann vom Entwickler angegeben werden.
2. Wie erhält die Serverseite (Tomcat) die Daten für die Dekodierung?
Wenn Sie Tomcat-Standardeinstellungen verwenden und keine Codierungseinstellungen wie Filter vorgenommen werden, wird es auch mit ISO-8859-1 entschlüsselt, aber Setcharacterencoding (Zeichensatz) kann nützlich sein.
Ich fand heraus, dass die Prämisse dessen, was Tomcat oben tut, darin besteht, dass im Anforderungsheader keine Codierungsmethode angegeben ist. Wenn die im Anforderungsheader angegebene Codierungsmethode, wird sie auf diese Weise codiert.Es werden 2 Artikel empfohlen, und die Adressen sind
Eingeführte und leicht verständliche URL-Codierung: http://www.cnblogs.com/yencain/articles/1321386.html;
Müllcode -Problem beim Senden von Daten mit der Post -Methode: http://wanghuan8086.javaeye.com/blog/173869
Es ist wichtig, Post zu verwenden. Wenn in der HTML -Datei ein Segment vorhanden ist, in dem sich das Formular befindet. <meta http-äquiv = content-type content = text/html; charset = Zeichensatz (GBK, UTF-8 usw.)/>
Sehr empfohlen, Post einzureichen