Detaillierte Einführung in die Kodierung von XML-Dokumenten mit UTF-8

Der Sitemap-Dienst von Google erfordert, dass alle veröffentlichten Website-Karten im UTF-8 von Unicode codiert sein müssen. Google erlaubt nicht einmal andere Unicode-Kodierungen wie UTF-16, geschweige denn Nicht-Unicode-Kodierungen wie ISO-8859-1. Technisch gesehen bedeutet dies, dass Google einen nicht standardmäßigen XML-Parser verwendet, da die XML-Empfehlung ausdrücklich verlangt, dass „alle XML-Handler die UTF-8- und UTF-16-Codierungen von Unicode 3.1 akzeptieren müssen“, aber das ist der Fall Ist das wirklich ein großes Problem?

Jeder kann UTF-8 verwenden

Universalität ist der erste und überzeugendste Grund, sich für UTF-8 zu entscheiden. Es kann jedes derzeit weltweit verwendete Skript verarbeiten. Obwohl es noch einige Lücken gibt, werden diese immer weniger offensichtlich und werden nach und nach geschlossen. Nicht enthaltene Texte sind in der Regel in keinem anderen Zeichensatz implementiert und können auch dann nicht in XML verwendet werden, wenn sie es sind. Im besten Fall werden diese Skripte durch Ausleihen von Schriftarten an einen Einzelbyte-Zeichensatz wie Latin-1 übergeben. Echte Unterstützung für solch seltene Skripte wird wahrscheinlich zuerst von Unicode kommen, und wahrscheinlich werden sie nur von Unicode unterstützt.

Aber das ist nur ein Grund, Unicode zu verwenden. Warum UTF-8 anstelle von UTF-16 oder anderen Unicode-Kodierungen wählen? Einer der unmittelbarsten Gründe ist die umfangreiche Toolunterstützung. Grundsätzlich kann jeder große mögliche Editor für XML UTF-8 verarbeiten, einschließlich JEdit, BBEdit, Eclipse, Emacs und sogar Notepad. Keine andere Unicode-Codierung verfügt über eine so umfassende Toolunterstützung zwischen XML- und Nicht-XML-Tools.

Für einige dieser Editoren, wie BBEdit und Eclipse, ist UTF-8 nicht der Standardzeichensatz. Jetzt ist es notwendig, die Standardeinstellungen zu ändern. Bei der Auslieferung sollten alle Tools UTF-8 als Standardkodierung auswählen. Wenn dies nicht geschieht, werden wir in einem Sumpf der mangelnden Interoperabilität stecken bleiben, wenn Dateien über Grenzen, Plattformen und Sprachen hinweg übertragen werden. Bis jedoch alle Programme UTF-8 als Standardkodierung verwenden, können Sie die Standardeinstellungen problemlos selbst ändern. In Eclipse können Sie beispielsweise im in Abbildung 1 gezeigten Einstellungsfenster „Allgemein/Editoren“ festlegen, dass alle Dateien UTF-8 verwenden. Möglicherweise stellen Sie fest, dass Eclipse als Standardeinstellung MacRoman erwartet. In diesem Fall wird die Datei jedoch nicht kompiliert, wenn sie an einen Programmierer mit Microsoft® Windows® oder an einen Computer außerhalb der USA und Westeuropas übergeben wird.

Abbildung 1. Ändern des Standardzeichensatzes von Eclipse

Damit UTF-8 funktioniert, müssen natürlich auch alle von Entwicklern ausgetauschten Dateien UTF verwenden -8, aber das ist kein Problem. Im Gegensatz zu MacRoman ist UTF-8 nicht auf einige wenige Skripte oder Plattformen beschränkt. Jeder kann UTF-8 verwenden. MacRoman, Latin-1, SJIS und verschiedene andere alte nationale Zeichensätze können das nicht.

UTF-8 funktioniert gut in Tools, die keine Multibyte-Daten unterstützen. Andere Unicode-Formate wie UTF-16 enthalten tendenziell viele Nullbytes. Viele Tools interpretieren diese Bytes als End-of-File- oder ein anderes spezielles Trennzeichen, was zu unerwünschten, unerwarteten und oft unangenehmen Ergebnissen führt. Wenn beispielsweise UTF-16-Daten unverändert in C String geladen werden, wird die Zeichenfolge möglicherweise ab dem zweiten Byte des ersten ASCII-Zeichens abgeschnitten. UTF-8-Dateien enthalten nur Null, wenn null tatsächlich dargestellt wird. Natürlich sollte ein solch naives Tool nicht zur Verarbeitung von XML-Dokumenten gewählt werden. Allerdings landen Dokumente in Altsystemen oft an seltsamen Orten, und niemand erkennt oder versteht wirklich, dass diese Zeichenfolgen nur alter Wein in neuen Schläuchen sind. UTF-8 verursacht auf Systemen, die Unicode und XML nicht unterstützen, weniger Probleme als UTF-16 oder andere Unicode-Kodierungen.

Was die Experten sagen

XML ist der erste große Standard, der UTF-8 vollständig unterstützt, aber das ist erst der Anfang. Verschiedene Standardorganisationen empfehlen nach und nach UTF-8. Beispielsweise sind URLs, die Nicht-ASCII-Zeichen enthalten, ein seit langem bestehendes Problem im Web. URLs, die Nicht-ASCII-Zeichen enthalten, die auf einem PC funktionieren, funktionieren nicht auf einem Mac und umgekehrt. Das World Wide Web Consortium (W3C) und die Internet Engineering Task Force (IETF) haben dieses Problem kürzlich gelöst, indem sie vereinbart haben, dass alle URLs in UTF-8 und keiner anderen Codierung codiert werden müssen.

Das W3C und die IETF werden immer strenger, wenn es darum geht, ob UTF-8 zuerst, zuletzt oder gelegentlich verwendet werden soll. Im W3C-Zeichenmodell für das World Wide Web 1.0: Fundamentals heißt es: „Wenn eine Zeichenkodierung ausgewählt werden muss, muss es UTF-8, UTF-16 oder UTF-32 sein. US-ASCII ist aufwärtskompatibel mit UTF-8 ( US-ASCII-Strings sind auch UTF-8-Strings, siehe [RFC 3629]), wenn also Kompatibilität mit US-ASCII erforderlich ist, ist UTF-8 sehr gut geeignet. „Tatsächlich ist die Kompatibilität mit US-ASCII so wichtig fast erforderlich. Das W3C erklärt weise: „In anderen Fällen, beispielsweise für APIs, ist UTF-16 oder UTF-32 möglicherweise besser geeignet. Gründe für die Wahl einer Kodierung können die Effizienz der internen Verarbeitung und die Interoperabilität mit anderen Prozessen sein.“ >Ich stimme dem Grund der Effizienz der internen Verarbeitung zu. Beispielsweise ist die interne Darstellung von Zeichenfolgen in der Java™-Sprache UTF-16, sodass die Indizierung von Zeichenfolgen schneller erfolgt. Java-Code stellt diese interne Darstellung jedoch niemals dem Programm zur Verfügung, mit dem er Daten austauscht. Verwenden Sie stattdessen für den externen Datenaustausch java.io.Writer und geben Sie den Zeichensatz explizit an. Bei der Auswahl wird UTF-8 dringend empfohlen.

Die IETF ist noch expliziter. Die IETF Charset Policy [RFC 2277] besagt, dass in Sprachen ohne Unsicherheit:

Protokolle in der Lage sein müssen, den UTF-8-Zeichensatz zu verwenden, der aus dem ISO 10646-Kodierungssatz und dem UTF-8-Zeichen besteht Kodierungsmethode, siehe [10646] Anhang R (veröffentlicht in Revision 2) für den vollständigen Text.

Darüber hinaus legt das Protokoll möglicherweise fest, wie andere ISO 10646-Zeichensätze und Zeichenkodierungsschemata wie UTF-16 verwendet werden sollen. Die Unfähigkeit, UTF-8 zu verwenden, stellt jedoch einen Verstoß gegen diese Richtlinie dar Während des Prozesses ist es notwendig, das Änderungsverfahren ([BCP9] Abschnitt 9) zu durchlaufen und im Protokollspezifikationsdokument klare und zuverlässige Gründe anzugeben.

Bestehende Protokolle oder Protokolle zum Übertragen von Daten aus vorhandenen Datenspeichern müssen möglicherweise andere

Datensätze

unterstützen oder sogar andere Standardcodierungen als UTF-8 verwenden. Dies ist erlaubt, muss aber UTF-8 unterstützen können. Hinweis: Die Unterstützung älterer Protokolle und Dateien erfordert möglicherweise noch einige Zeit lang die Akzeptanz anderer Zeichensätze und Kodierungen als UTF-8, aber ich wäre sehr vorsichtig, wenn das der Fall sein müsste. Jedes neue Protokoll, jede neue Anwendung und jedes neue Dokument sollte UTF-8 verwenden.

Chinesisch, Japanisch und Koreanisch

Ein häufiges Missverständnis ist, dass UTF-8 ein komprimiertes Format ist. Dies ist nicht der Fall. In UTF-8 nehmen ASCII-Zeichen im Vergleich zu anderen Unicode-Kodierungen, insbesondere UTF-16, nur halb so viel Platz ein. Allerdings nimmt die UTF-8-Kodierung einiger Zeichen 50 % mehr Platz ein, insbesondere Hieroglyphen wie Chinesisch, Japanisch und Koreanisch (CJK).

Aber selbst wenn CJK XML in UTF-8 codiert ist, kann die tatsächliche Größe kleiner als UTF-16 sein. Beispielsweise enthalten chinesische XML-Dokumente eine große Anzahl von ASCII-Zeichen wie , &, =, ", ' und Leerzeichen. Die UTF-8-Kodierung dieser Zeichen ist kleiner als UTF-16. Die spezifische Komprimierung /Erweiterungsfaktoren variieren je nach Dokument, aber in beiden Fällen ist der Unterschied wahrscheinlich nicht offensichtlich.

Abschließend ist zu erwähnen, dass hieroglyphische Schriften wie Chinesisch und Japanisch Zeichen verwenden, verglichen mit alphabetischen Schriften wie z Aufgrund der schieren Menge an Zeichen sind für die vollständige Darstellung dieser Sprachen oft weniger erforderlich, d. h. im Vergleich zu denselben Wörtern oder Sätzen in Englisch oder Russisch Zum Beispiel wird „Baum“ auf Japanisch durch „Holz“ dargestellt (ähnlich wie ein Baum) und erfordert in UTF-8 drei Bytes, während das englische Wort „Baum“ vier Buchstaben erfordert Das Wort „grove“ ist „林“ (zwei Bäume nahe beieinander). Für die Codierung in UTF-8 sind drei Bytes erforderlich, während das englische Wort „grove“ fünf Bytes erfordert. erfordert immer noch drei Bytes, während das entsprechende englische Wort „forest“ sechs Bytes erfordert. Wenn eine Komprimierung wirklich erforderlich ist, verwenden Sie nach der Komprimierung die Größen von UTF-8 und UTF-16 sind unabhängig vom Unterschied in der Originalgröße, desto weniger Redundanz wird durch den Komprimierungsalgorithmus entfernt >Der eigentliche Vorteil liegt im Design: UTF-8 ist ein robusteres und einfacher zu interpretierendes Format als jede andere Textkodierung, die jemals zuvor oder seitdem entwickelt wurde Das Endianness-Problem wird sowohl durch Big-Endian als auch durch Little-Endian dargestellt, da UTF-8 auf 8-Bit-Bytes und nicht auf 16-Bit-Wörtern basiert. UTF-8 hat keine Endianness-Mehrdeutigkeit durch Endianness-Flags oder andere Heuristiken

Eines der wichtigeren Merkmale von UTF-8 ist die Staatenlosigkeit. Jedes Byte in einem UTF-8-Stream oder einer UTF-8-Sequenz ist eindeutig. In UTF-8 können Sie die Position immer kennen. Das heißt, Sie können bei einem gegebenen Byte sofort feststellen, ob es sich um ein Einzelbyte-Zeichen, das erste Byte eines Doppelbyte-Zeichens oder das erste Byte eines handelt Doppelbyte-Zeichen. Das zweite Byte oder das zweite, dritte oder vierte Byte eines Drei-Byte-/Vier-Byte-Zeichens (es gibt natürlich auch andere Möglichkeiten, aber Sie verstehen schon). In UTF-16 kann nicht festgestellt werden, ob das Byte „0x41“ der Buchstabe „A“ ist. Manchmal ist es das, manchmal nicht. Es muss ein ausreichender Zustand aufgezeichnet werden, um die Position im Fluss zu bestimmen. Geht ein Byte verloren, sind alle nachfolgenden Daten unbrauchbar. In UTF-8 sind fehlende oder beschädigte Bytes leicht zu ermitteln und haben keinen Einfluss auf andere Daten.

UTF-8 ist kein Allheilmittel. Anwendungen, die wahlfreien Zugriff auf bestimmte Stellen in einem Dokument erfordern, können mit Kodierungen mit fester Breite wie UCS2 oder UTF-32 schneller funktionieren. (Wenn Sie Substitutionspaare berücksichtigen, handelt es sich bei UTF-16 um eine Zeichenkodierung mit variabler Länge.) Die XML-Verarbeitung fällt jedoch nicht in diese Anwendungskategorie. Die XML-Spezifikation verlangt ausdrücklich, dass Parser mit dem Parsen vom ersten Byte eines XML-Dokuments bis zum letzten Byte beginnen, und alle vorhandenen Parser tun dies. Ein schnellerer Direktzugriff hilft der XML-Verarbeitung nicht, und obwohl dies ein guter Grund sein könnte, eine andere Kodierung für eine Datenbank oder ein anderes System zu verwenden, gilt dies nicht für XML.

Fazit

In einer zunehmend internationalen Welt verschwimmen sprachliche und politische Grenzen und Zeichensätze, die von der Region abhängen, sind nicht mehr anwendbar. Unicode ist der einzige Zeichensatz, der in vielen Regionen zusammenarbeiten kann. UTF-8 ist die beste verfügbare Unicode-Kodierung:

Umfassende Tool-Unterstützung, einschließlich erstklassiger Kompatibilität mit älteren ASCII-Systemen.

Einfache und effiziente Handhabung.

Korruptionsbekämpfung.

Plattformunabhängig.

Es ist an der Zeit, nicht mehr über Zeichensätze und Kodierungen zu streiten, sondern UTF-8 zu wählen und den Streit zu beenden.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in die Kodierung von XML-Dokumenten mit UTF-8. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!