Nach dem chinesischen URL-Code stellt jedes %XX ein Byte dar, oder?
Das Ergebnis von urlencode('中') ist also %XX%XX%XX (utf-8-Kodierung)
Nach dem chinesischen URL-Code stellt jedes %XX ein Byte dar, oder?
Das Ergebnis von urlencode('中') ist also %XX%XX%XX (utf-8-Kodierung)
Ja, um das Problem zu lösen, dass Unicode zu viel Speicherplatz belegt und die Erweiterung unverändert bleibt, wurde die UTF-8-Spezifikation eingeführt.
Bei Einzelbyte-Symbolen wird das erste Bit des Bytes auf 0 gesetzt und die nächsten 7 Bits sind der Unicode-Code dieses Symbols. Für englische Buchstaben sind also die UTF-8-Kodierung und der ASCII-Code gleich.
Bei n-Byte-Symbolen (n>1) werden die ersten n Bits des ersten Bytes auf 1, das n-te Bit auf 0 und die ersten beiden Bits der folgenden Bytes auf 1 gesetzt auf 10 eingestellt. Die übrigen nicht erwähnten Binärbits sind alle der Unicode-Code dieses Symbols.
Das heißt, das Codierungsergebnis von UTF-8 hat eine variable Länge. Die UTF-8-Kodierung von 中
ist E4B8AD
, daher lautet der entsprechende URL-Code 中
.
Ja, die URL-Codierung stellt einfach die Daten von Sonderzeichen und Nicht-ASCII-Zeichen hexadezimal dar und fügt dann vor jedem Byte ein Prozentzeichen hinzu (d. h. zwei hexadezimale Zahlen). Für diese nicht-speziellen ASCII-Zeichen gilt die URL-Kodierung selbst.
Für dasselbe chinesische Zeichen sind es bei GBK-Codierung zwei Bytes, bei UTF-8 sind es drei Bytes.
Das Problem ist natürlich, dass die URL-Kodierung verwirrend ist. An einigen Stellen wird beispielsweise
zur Darstellung von Leerzeichen verwendet, an anderen wird
verwendet. Die spezifische Situation muss noch im Detail analysiert werden. Ersteres entspricht der Funktion urlencode
und letzteres entspricht rawurlencode
. Normalerweise wird Ersteres in Formulardaten verwendet (einschließlich der Abfrage in der URL, die der Teil nach ?
ist), und Letzteres wird im URL-Pfad (der Teil nach Host und vor der Abfrage)