URLEncode konvertiert Zeichen wie folgt:
- Leerzeichen () werden in Pluszeichen (+) umgewandelt.
- Nicht alphanumerische Zeichen werden in ihre hexadezimale Darstellung maskiert.
Das ist ähnlich, aber nicht genau dasselbe wie W3C
Anwendung / x-www-form-urlencoded
Dies ist der Standardinhaltstyp. Formulare, die mit diesem Inhaltstyp eingereicht werden, müssen wie folgt codiert sein:
Namen und Werte von Steuerelementen sind Escapezeichen. Leerzeichen werden ersetzt mit '+' und dann reservierten Zeichen sind wie in RFC1738 beschrieben entkommen, Abschnitt 2.2: Nicht alphanumerisch Zeichen werden durch '% HH' ersetzt, a Prozentzeichen und zwei Hexadezimalzeichen Ziffern, die den ASCII-Code von darstellen der Charakter. Zeilenumbrüche sind dargestellt als "CR LF" -Paare (d. h. '% 0D% 0A').
Die Namen / Werte der Steuerelemente werden in der Reihenfolge aufgelistet, in der sie in der Liste erscheinen Dokument. Der Name ist getrennt von der Wert von '=' und Name / Wert-Paaren sind voneinander durch '& amp;' getrennt.
Meine Frage ist, hat jemand die Arbeit getan, um zu bestimmen, ob URLEncode gültige x-www-form-urlencoded Daten produziert?
Nun, die Dokumentation, die Sie verlinkt haben, ist für IIS 6 Server.UrlEncode, aber Ihr Titel scheint nach .NET zu fragen. System.Web.HttpUtility.UrlEncode . Mit einem Tool wie Reflector können wir die Implementierung des letzteren sehen und feststellen, ob es die W3C-Spezifikation erfüllt.
Hier ist die Kodierungsroutine, die letztendlich aufgerufen wird (beachten Sie, dass sie für ein Array von Bytes definiert ist, und andere Überladungen, die Strings annehmen, konvertieren diese Strings schließlich in Byte-Arrays und rufen diese Methode auf). Sie würden dies für jeden Steuerelementnamen und -wert aufrufen (um zu vermeiden, dass die reservierten Zeichen = & , die als Trennzeichen verwendet werden, nicht verwendet werden können).
Der erste Teil der Routine zählt die Anzahl der Zeichen, die ersetzt werden müssen (Leerzeichen und nicht-urlsichere Zeichen). Der zweite Teil der Routine weist einen neuen Puffer zu und führt Ersetzungen durch:
a-z A-Z 0-9 ()*-._!
%HH konvertiert
RFC1738 Staaten (Schwerpunkt meins):
Also nur alphanumerische Zeichen, die Sonderzeichen "$ -_. +! * '()," und
reservierte Zeichen, die für ihre reservierten Zwecke verwendet werden können verwendet werden unverschlüsselt innerhalb einer URL.Auf der anderen Seite, Zeichen, die nicht codiert werden müssen (einschließlich alphanumerische Zeichen) können innerhalb des schemaspezifischen Codes codiert sein Teil einer URL, sofern sie nicht für ein reserviertes
verwendet werden Zweck.
Der Satz von sicheren URL-Zeichen, der von UrlEncode erlaubt ist, ist eine Teilmenge der Sonderzeichen, die in RFC1738 definiert sind. Die Zeichen $, fehlen nämlich und werden von UrlEncode codiert, auch wenn die Spezifikation angibt, dass sie sicher sind. Da sie dürfen uncodiert (und nicht müssen ) verwendet werden, erfüllt sie immer noch die Spezifikation, um sie zu codieren (und der zweite Absatz gibt das explizit an).
In Bezug auf Zeilenumbrüche, wenn die Eingabe eine CR LF Sequenz hat, wird das mit Escapezeichen %0D%0A überschrieben. Wenn die Eingabe jedoch nur LF enthält, wird das mit Escapezeichen %0A überschrieben (es gibt also keine Normalisierung von Zeilenumbrüchen in dieser Routine).
Bottom Line: Er erfüllt die Spezifikation, wobei zusätzlich $, codiert wird, und der Aufrufer ist für die Bereitstellung von normalisierten Zeilenumbrüchen in der Eingabe verantwortlich.
Tags und Links .net urlencode standards-compliance