Der Unterschied zwischen utf-8 und utf-8 ohne BOM

BOM – Byte Order Mark, das ist die Byte Order Mark

In der UCS-Codierung gibt es ein Zeichen namens „ZERO WIDTH NO-BREAK SPACE“, und seine Codierung ist FEFF. FFFE ist ein Zeichen, das in UCS nicht existiert und daher in der tatsächlichen Übertragung nicht vorkommen sollte. Die UCS-Spezifikation empfiehlt, dass wir vor der Übertragung des Bytestreams die Zeichen „ZERO WIDTH NO-BREAK SPACE“ übertragen. Wenn der Empfänger FEFF empfängt, zeigt er auf diese Weise an, dass der Bytestrom Big-Endian ist. Wenn er FFFE empfängt, zeigt er an, dass der Bytestrom Little-Endian ist. Daher wird das Zeichen „ZERO WIDTH NO-BREAK SPACE“ auch BOM genannt.

UTF-8 erfordert keine Stückliste zur Angabe der Bytereihenfolge, kann die Stückliste jedoch zur Angabe der Kodierungsmethode verwenden. Die UTF-8-Kodierung des Zeichens „ZERO WIDTH NO-BREAK SPACE“ ist EF BB BF. Wenn der Empfänger also einen Bytestrom empfängt, der mit EF BB BF beginnt, weiß er, dass dieser UTF-8-codiert ist.

In UTF-8-kodierten Dateien belegt die Stückliste drei Bytes. Wenn Sie Notepad verwenden, um eine Textdatei als UTF-8-Kodierung zu speichern, die Datei mit UE öffnen und in den hexadezimalen Bearbeitungsmodus wechseln, können Sie das FFFE am Anfang sehen. Dies ist eine gute Möglichkeit, UTF-8-codierte Dateien zu identifizieren. Die Software verwendet BOM, um festzustellen, ob die Datei UTF-8-codiert ist. Viele Software erfordern auch, dass die gelesene Datei über BOM verfügt. Allerdings gibt es immer noch viele Softwareprogramme, die Stücklisten nicht erkennen können.

In frühen Versionen von Firefox konnten Erweiterungen keine Stücklisten haben, aber Versionen nach Firefox 1.5 haben begonnen, Stücklisten zu unterstützen. Jetzt habe ich festgestellt, dass PHP BOM auch nicht unterstützt. PHP hat das BOM-Problem bei der Entwicklung nicht berücksichtigt, was bedeutet, dass es die drei Zeichen des BOM am Anfang der UTF-8-codierten Datei nicht ignoriert.

Da es im Wiki von Bo-Blog zu sehen ist, ist auch Bo-Blog, das ebenfalls PHP verwendet, von BOM betroffen. Ein weiteres Problem wurde erwähnt: „Eingeschränkt durch den COOKIE-Sendemechanismus, in Dateien, die am Anfang dieser Dateien bereits eine Stückliste haben, kann das COOKIE nicht gesendet werden (da PHP den Datei-Header bereits gesendet hat, bevor das COOKIE gesendet wurde), also Anmelde- und Abmeldefunktionen ungültig. Alle Funktionen, die auf COOKIE und SESSION basieren, sind ungültig. „Dies sollte der Grund sein, warum eine leere Seite im WordPress-Hintergrund erscheint, da jede ausgeführte Datei eine Stückliste enthält und diese drei Zeichen gesendet werden in Abhängigkeit von Cookies und Die Sitzungsfunktion ist ungültig.

Die Lösung besteht darin, die Datei im ASCII-Code zu speichern, wenn sie nur englische Zeichen (oder Zeichen in ASCII-Kodierung) enthält. Wenn Sie einen Editor wie UE verwenden, klicken Sie auf Datei->Konvertieren->UTF-8 in ASCII oder wählen Sie unter Speichern unter die ASCII-Kodierung aus. Wenn es sich um eine Zeile handelt, die im DOS-Format endet, können Sie sie mit Notepad öffnen, auf „Speichern unter“ klicken und die ASCII-Kodierung auswählen. Wenn es chinesische Zeichen enthält, können Sie die Funktion „Speichern unter“ von UE verwenden und „UTF-8 ohne BOM“ auswählen.

UTF-8 sollte BOM gar nicht erst hinzufügen. Es hat keinen Sinn, außer dem Editor mitzuteilen, dass es sich um UTF-8 handelt. Tatsächlich ist der Editor vollständig in der Lage, die Kodierung einer Datei anhand der Merkmale von nicht allzu vielen Kodierungsformaten zu beurteilen. Auch wenn sie nicht automatisch erkannt werden kann, sollte der Editor über einen Ort zum Festlegen der Kodierung verfügen. Daher denke ich, dass BOM für UTF-8 überflüssig ist.

BOM muss nur für utf-16 hinzugefügt werden. Da es in Unicode-Reihenfolge codiert ist und zwei Bytes im BMP-Bereich umfasst, muss es als Big- oder Little-Endian identifiziert werden.

Eigentlich halte ich es für zu dumm, dass UTF-8 das Konzept von Big und Small Endianness einführt. Ich weiß nicht, was diese Standardkomitees denken. Die Bedeutung der Existenz von Big- und Small-Endianness liegt in der Verarbeitungsmethode der CPU. Wenn die CPU Big-Endian verarbeitet, muss für Little-Endian eine Konvertierungsschicht durchgeführt werden, was zu einer Verringerung der Effizienz führt. Aber wen interessiert in praktischen Anwendungen Endianness? Die Textkodierung bringt das Konzept der Bytereihenfolge mit sich. Man kann nur sagen, dass diejenigen, die Standards formulieren, zu starr sind. Für UTF-16 denke ich, dass es keine Notwendigkeit gibt, BOM zum Markieren zu verwenden, solange die ganze Welt einer Byte-Reihenfolgemethode folgt.

Allerdings unterstützt PHP keine UTF-16-codierten Dateien. Denn das $-Symbol besteht beispielsweise auch in UTF-8 aus zwei Bytes und kann vom PHP-Decoder nicht geparst werden. Ich weiß nicht, ob PHP6 dies unterstützen wird, nachdem das Konzept von Unicode in die interne Verarbeitung eingeführt wurde.

Das Codierungsproblem klingt einfach, ist aber tatsächlich sehr kompliziert. Viele Programme verwenden das Konzept der hierarchischen Codierung. Wie MySQL ist es in Konzepte wie Client->Verbindung->Speicher und Speicher->Verbindung->Ergebnis unterteilt. Der Speicher ist in System, Datenbank, Tabelle und Spalte unterteilt. Ich denke manchmal, ist es notwendig, es so kompliziert zu machen, TNND. Wer nutzt wie MySQL seine Funktionen? Sofern die beiden Clients nicht in unterschiedlichen Codierungsumgebungen arbeiten dürfen, besteht keine Notwendigkeit, die Client-Codierung zu trennen. In den meisten Fällen nur binärer Eingang/binärer Ausgang

Das Obige hat den Unterschied zwischen utf-8 und utf-8 ohne BOM vorgestellt, einschließlich der relevanten Aspekte. Ich hoffe, es wird für Freunde hilfreich sein, die sich für PHP-Tutorials interessieren.