Unicode

• Einige Programme (z. B. die Oracle-Datenbank ), die ihre Unicode-Daten intern im UTF-16-Format darstellen, haben (oder hatten) einen Konvertierungsfehler in UTF-8: ein Zeichen zwischen U + 10000 und U + 10FFFF, gespeichert in zwei 16- Bitwörter, wird als Folge von zwei Unicode-Zeichen in UTF-8 umgewandelt. Dies führte zur "versehentlichen" Erstellung von CESU-8 und hat den Vorteil, die Verwendung von Unicode auf 16-Bit-Plattformen zu erleichtern.
• Das Unicode-Nullzeichen U + 0000 wird in UTF-8 als einzelnes Nullbyte 0x00 codiert . Nach dem Unicode-Standard hat dieses Zeichen keine besondere Bedeutung; jedoch (aus historischen konzeptionellen Gründen) betrachten die C-Sprachbibliotheken zur Stringverarbeitung dieses Steuerzeichen als ein Ende des Strings, was die Implementierung einiger Anwendungsfälle erschwert . Unter der Java-Plattform wurde die  Version "  (en) Modified UTF-8 " geboren, indem die "16-Bit" -Portabilität des CESU-8 genutzt und die Möglichkeit der Codierung von U + 0000 unter der Sequenz 0xC0 0x80 . hinzugefügt wurde (normalerweise in UTF-8) verboten: Durch diesen Austausch mit den nativen C-Bibliotheken der unterstützten Plattform kann die Plattform problemlos alle gültigen Unicode-Texte sowie die kompilierten Klassendateien verwalten (portables alternatives Format, unabhängig von Endianness und Word Größe).

Das UTF-16 ist ein guter Kompromiss, wenn der Speicherplatz nicht zu klein ist, denn die überwiegende Mehrheit der den Schriften moderner Sprachen zugeordneten Unicode-Zeichen (einschließlich der am häufigsten verwendeten Zeichen) befinden sich in der mehrsprachigen Planbasis und können daher dargestellt werden auf 16 Bit. Die französische Version der ISO / IEC 10646 nennt diese 16-Bit-Wörter "seizets", die internationale Version beschreibt sie jedoch als klassische 16-Bit-Wörter, die aus zwei Bytes bestehen und den üblichen Regeln des Endismus unterliegen .

Die Codepunkte der sechzehn zusätzlichen Ebenen erfordern eine Transformation auf zwei 16-Bit-Wörtern:

• subtrahiere 0x10000 vom Codepunkt und belasse eine 20-Bit-Zahl im Bereich von 0x00 bis 0xFFFFF;
• die 10 höchstwertigen Bits (eine Zahl zwischen 0x00 und 0x3FF) werden zu 0xD800 addiert und ergeben die erste Codeeinheit in der oberen Halbzone ( 0xD800 bis 0xDBFF );
• die 10 niedrigstwertigen Bits (eine Zahl zwischen 0x00 und 0x3FF) werden zu 0xDC00 addiert und ergeben die zweite Codeeinheit in der unteren Halbzone ( 0xDC00 bis 0xDFFF );

Da sich die meisten der am häufigsten verwendeten Zeichen in der Basisebene befinden, wird die Codierung zusätzlicher Clips in der Software oft schlecht getestet, was selbst in weit verbreiteter Software zu Fehlern oder Sicherheitsproblemen führt. Bestimmte rechtliche Rahmenbedingungen wie GB 18030 können die Unterstützung zusätzlicher Pläne verlangen , die insbesondere Zeichen enthalten, die in Eigennamen vorkommen.

Es ist möglich, den Beginn der Codiersequenz von jeder Stelle in einem in UTF-16 dargestellten Text durch höchstens eine zusätzliche Lesung zu bestimmen, nur wenn diese Codestelle im unteren Halbbereich liegt. Dieses Formular ist für die Darstellung von Texten mit wenigen ASCII-Zeichen (U + 0000 bis U + 007F) kostengünstiger und schneller zu verarbeiten als UTF-8.

Diese Transformation weist jedoch zwei inkompatible Codierungsschemata auf, die von der Reihenfolge der Bytes in der 16-Bit-Ganzzahldarstellung abhängen. Um diese Mehrdeutigkeit aufzulösen und die Übertragung zwischen heterogenen Systemen zu ermöglichen, ist es erforderlich, Informationen über das verwendete Codierungsschema (UTF-16BE oder UTF-16LE) hinzuzufügen oder dem codierten Text die Darstellung des Codepunktes voranzustellen (zugewiesen dem Zeichen "Geschütztes Leerzeichen der Breite Null", ein Zeichen, das jetzt nur für diese alleinige Verwendung als Byte-Order-Marker reserviert ist), da der Codepunkt "umgekehrt" U + FFFE gültig ein Nicht-Zeichen ist, in Texten verboten konform zu Unicode und ISO/IEC 10646 .

Der andere Fehler von UTF-16 besteht darin, dass damit transformierter und mit einem der beiden Kodierungsschemata übertragener Text eine große Anzahl von Bytes enthält, die null sind oder einen Wert haben, der mit den d-Werten in Konflikt steht.'Bytes, die von bestimmten Austauschprotokollen reserviert sind.

Dies ist insbesondere die Codierung, die die Java- Plattform intern verwendet, sowie Windows für seine Unicode-kompatiblen APIs (mit dem Typ wchar).

Das UTF-32 wird verwendet, wenn der Speicherplatz kein Problem darstellt und wir direkt und ohne Größenänderung auf Zeichen zugreifen müssen ( Ägyptische Hieroglyphen ).

Der Vorteil dieser standardisierten Transformation besteht darin, dass alle Codeelemente die gleiche Größe haben. Es ist daher nicht erforderlich, zusätzliche Codepunkte zu lesen, um den Beginn der Darstellung eines Codepunktes zu bestimmen.

Dieses Format ist jedoch besonders unwirtschaftlich (auch im Speicher), da es unnötigerweise mindestens ein Byte (immer Null) pro Zeichen "verschwendet". Die Speichergröße eines Textes wirkt sich negativ auf die Leistung aus, da bei vollem Arbeitsspeicher mehr Lese- und Schreibvorgänge auf die Festplatte erforderlich sind , und verringert auch die Leistung des Speichercaches von Prozessoren.

Für Texte, die in aktuellen modernen Sprachen geschrieben sind (abgesehen von bestimmten seltenen Zeichen der ergänzenden ideographischen Ebene) und daher nur die Codepunkte der mehrsprachigen Basisebene verwenden, verdoppelt diese Transformation den erforderlichen Speicher im Vergleich zu UTF-16 .

Wie UTF-16 hat UTF-32 mehrere Kodierungsschemata, abhängig von der Reihenfolge der Bytes, die eine ganze Zahl von mehr als 8 Bits bilden (zwei Kodierungsschemata von UTF-32 sind standardisiert, UTF-32BE und UTF-32LE). Es ist daher auch erforderlich, dieses Kodierungsschema anzugeben oder es durch Voranstellen des Textes durch die Darstellung des Kodepunkts U + FEFF in UTF-32 zu bestimmen. Wie bei UTF-16 macht das Vorhandensein von Null-Bytes in den standardisierten Codierungsschemata von UTF-32 es mit vielen Protokollen für den Austausch zwischen heterogenen Systemen inkompatibel.

Auch dieses Format wird meistens nur sehr lokal für bestimmte Verarbeitungen als einfacher zu handhabende Zwischenform verwendet, und wir bevorzugen oft die UTF-16-Transformation, die für die Verarbeitung und Speicherung großer Textmengen oft effizienter ist, die Konvertierung zwischen die beiden sind sehr einfach durchzuführen und im Hinblick auf den Verarbeitungsaufwand sehr kostengünstig.

Tatsächlich werden viele Textverarbeitungsbibliotheken nur mit UTF-16 geschrieben und sind effizienter als UTF-32, selbst wenn die Texte Zeichen zusätzlicher Ebenen enthalten (da dieser Fall von Zahlen in den allermeisten Fällen selten bleibt).

Beachten Sie jedoch, dass die Transformation zu UTF-32 32-Bit-Codepunkte verwendet, von denen viele möglicherweise keinen gültigen Codepunkt darstellen (Werte außerhalb der beiden Intervalle, die gültige Codepunkte darstellen U + 0000 bis U + D7FF und U + E000 bis U + 10FFFF), daher kein gültiges oder reserviertes Zeichen (alle darin enthaltenen Informationen können daher kein Text im Sinne von Unicode sein). Die Übertragung von Texten, die diese ungültigen Codewerte in einem der standardisierten Codierungsschemata von UTF-32 verwenden, ist für jedes Unicode-konforme System verboten (es ist notwendig, stattdessen die Codepunkte für den privaten Gebrauch zu verwenden), da dies unmöglich ist um sie in einer anderen UTF-Transformation darzustellen, mit der die drei standardisierten UTFs bijektiv kompatibel sind.

Chinesischer Standard GB 18030

Dies ist eine Transformation von Unicode, die nicht vom Unicode-Konsortium definiert wird, sondern von der Standardverwaltung in China, wo ihre Unterstützung in Anwendungen obligatorisch ist. Historisch war dies ein codierter Zeichensatz, der durch eine algorithmische Transformation erweitert wurde, um das gesamte UCS-Repertoire zu unterstützen, wodurch eine große Code-zu-Code-Korrespondenztabelle vervollständigt wurde.

Unicode-Schriften

Zu behaupten, dass Unicode Zeichen kodiert, kommt der Behauptung gleich, dass es abstrakten Symbolen eine Zahl zuweist, nach einem Prinzip der logischen Kodierung. Unicode hingegen kodiert keine grafischen Darstellungen von Zeichen, Glyphen . Es gibt daher keine Bijektion zwischen der Darstellung des Zeichens und seiner Nummer, da alle grafischen Stilvarianten vereinheitlicht sind.

Darüber hinaus ist die Auswahl einer Glyphe durch einen Code im Gegensatz zu einer klassischen ASCII- oder Latin-1- Schrift nicht eindeutig und oft kontextabhängig und kann auch dieselbe Glyphe für verschiedene Codes anzeigen. So kann das französische Zeichen „é“ auf zwei Arten beschrieben werden: entweder durch direkte Verwendung der dem „é“ entsprechenden Zahl oder indem man der Zahl des „e“ ohne Jagd nach der des akuten Akzents folgt. Unabhängig davon, welche Option Sie wählen, wird dieselbe Glyphe angezeigt. Wir werden vom ersten Zeichen sagen, dass es vorkomponiert ist, vom zweiten, dass es eine Komposition ist (zwei Zeichen bilden eine einzelne Glyphe, die aus beiden besteht). Dies ist erlaubt und wird sogar dringend empfohlen, da die verschiedenen Kodierungsformen von Unicode als "kanonisch gleichwertig" eingestuft werden, was bedeutet, dass zwei gleichwertige Kodierungsformen gleich behandelt werden sollten.

Viele zusammengesetzte Zeichen sind in diesem Fall und können auf diese zwei Arten codiert werden (oder mehr, einige zusammengesetzte Zeichen können auf mehr als eine Weise zerlegt werden, insbesondere wenn sie mehrere diakritische Zeichen enthalten). In den meisten Fällen ist das vorkomponierte Zeichen für die Kodierung des Textes vorzuziehen, wenn es vorhanden ist (dies ist beispielsweise bei polytonischem Griechisch der Fall , das, in Zerlegung kodiert, grafisch möglicherweise nicht zufriedenstellend ist: Je nach Schriftart sind die Zeichen unterschiedlich, Bestandteile der Glyphe sind manchmal schlecht angeordnet und schwer zu lesen). Allerdings haben nicht alle zusammengesetzten Zeichen einen eindeutigen Codepunkt für ihre vorkomponierte Form.

Ebenso erfordern einige Schriftsysteme, wie Devânagarî , Persisch oder Arabisch , eine komplexe Behandlung von Ligaturen  : Die Grapheme ändern ihre Form je nach ihrer Position oder ihren Nachbarn (siehe Kontextvariante und Gemeinsamer Buchstabe ). Die Auswahl der richtigen Glyphe erfordert eine Verarbeitung, um zu bestimmen, welche kontextbezogene Form in der Schriftart ausgewählt werden soll, obwohl alle kontextbezogenen Formen identisch in Unicode codiert sind.

Aus diesen Gründen sollte eine Unicode-Schriftart mit Vorsicht behandelt werden. Beispielsweise reicht eine Schriftart mit allen vorhandenen Glyphen nicht aus. Es ist auch notwendig, dass das Anzeigesystem (die Rendering-Engine ) die Mechanismen besitzt, die in der Lage sind , Ligaturen , kontextuelle Varianten und gemeinsame Formen für bestimmte Sprachen zu verarbeiten. Umgekehrt verdient eine Schrift, die nur einen Teil der Zeichen darstellt, diese aber richtig darzustellen weiß, eher den Titel "Unicode-Schrift". Schließlich können bestimmte technische Einschränkungen von Schriftformaten verhindern, dass sie das gesamte Verzeichnis unterstützen. In der Praxis ist es (im Jahr 2009) unmöglich, eine einzelne Schriftart zu finden, die das gesamte Verzeichnis unterstützt.

Ein Unicode-Zeichenfont ist daher nur ein Font, der es ermöglicht, einen in allen von Unicode autorisierten Formen codierten Text direkt anzuzeigen und eine zusammenhängende Teilmenge zu unterstützen, die an eine oder mehrere Sprachen angepasst ist, um ein oder mehrere Skripte zu unterstützen. Keine Unicode-Schrift kann allein "funktionieren", und die vollständige Schreibunterstützung erfordert die Unterstützung dieser in einer Rendering-Engine , die in der Lage ist, äquivalente Kodierungsformen zu erkennen, nach kontextbezogenen Formen im Text zu suchen und die verschiedenen Glyphen einer mit Unicode kodierten Schriftart auszuwählen. bei Bedarf die in der Schrift selbst enthaltenen Korrespondenztabellen verwenden.

Technische Details

Softwarebibliotheken

Mit der plattformübergreifenden Softwarebibliothek der ICU können Sie mit Unicode codierte Daten bearbeiten. Plattformspezifische Unicode-Unterstützung wird auch von modernen Systemen ( Java , Microsoft Windows , GNU/Linux , Standard-C/C++- Bibliotheken , Python , etc.) integriert.

Die zum Speichern von Unicode-Variablen zu verwendenden Typen sind:

1. In UTF-8
2. Beachten Sie jedoch, dass der wchar_tSprachtyp C nicht immer die Codierung aller Unicode-Zeichen zulässt, da der Standard dieser Sprache keine ausreichende Mindestanzahl für diesen Standardtyp vorsieht. Viele Compiler der Sprache definieren jedoch wchar_tmit 32 Bit (oder sogar 64 Bit in Umgebungen, die standardmäßige 64-Bit-Ganzzahlen verarbeiten), was ausreichend ist, um jeden Punkt von standardisiertem Unicode-Code zu speichern. Aber andere Compiler stellen wchar_tauf 16 Bit dar (insbesondere unter Windows in einer 16- oder 32-Bit-Umgebung), sogar auf 8 Bit nur (insbesondere in eingebetteten Umgebungen ohne allgemeines Betriebssystem), da wchar_tsie die gleiche Darstellung wie der Typ verwenden können, charder mindestens 8 Bit.
3. Ähnlich wie C und C ++ hat die Java-Sprache einen Einheitentyp, der es erlaubt, 16 Bits zu codieren, aber keinen einzelnen Codepunkt mit beliebigem Wert zu codieren (der native Typ charist nur eine positive 16-Bit-Ganzzahl) . Um standardisierte Zeichen aus dem Vordergrund zu manipulieren, müssen Sie ein Paar Codepunkte verwenden, von denen jeder einen Wert enthält, der den beiden Codepunkten entspricht, die durch das UTF-16-Formular definiert sind. Auch die Objekttypen Stringoder char[2]eignen sich am besten zur Darstellung eines Unicode-Zeichens. Seit Java 1.4.1 bietet die Standardbibliothek volle Unicode-Unterstützung dank des nativen Typs int(der eine ganze Zahl auf 32 Bit definiert ist) und der statischen Methoden der Standardklasse Character(ein instanziiertes Objekt dieses Typs Characterlässt dies jedoch nicht zu, genau wie der native Typ char, um einen beliebigen Codepunkt zu speichern).
4. JavaScript hat verschiedene nicht standardisierte Implementierungen, einige ältere, die nicht mehr als 16 Bit pro Zeichen und manchmal nur 8 Bit unterstützen. Der ECMAScript-Standard dieser Sprache definiert jedoch eine Dienstprogrammklasse Characterauf 32 Bit (eigentlich basierend auf der Klasse Number), die alle Codepunkte der 17 standardisierten Pläne unterstützen muss, während die Zeichenfolgen Zeichen verwenden, die obligatorisch auf 16 Bit codiert sind (aber ohne Einschränkung, die die Paarung der UTF-16-Codeeinheiten verstärkt, wobei der Typ ECMAScript-Strings Stringnicht auf die einzige UTF-16-Kodierung beschränkt ist, sondern Vektoren von ganzzahligen Konstanten ohne Einschränkung auf 16 Bit kodiert ist, um die (Interoperabilität mit Java und anderen Sprachen, die auch keine UTF-16-Konformitätsbeschränkungen in ihren nativen Datentypen erzwingen). Diese beiden Sprachen unterstützen keine explizite Typisierung von Variablen, da der Typ dynamisch durch die ihnen zugewiesenen Werte definiert wird (auch mehrere interne Darstellungen sind möglich, deren Unterschiede normalerweise für den Programmierer transparent sind).

Unicode leidet jedoch immer noch unter einer schwachen Unterstützung für reguläre Ausdrücke durch einige Software, obwohl Bibliotheken wie ICU und Java diese unterstützen können. Eine solche Unterstützung ist für ECMAScript noch nicht standardisiert und wird nur mit Hilfe von mit der Sprache erstellten Bibliotheken oder Schnittstellen zur Interoperabilität mit anderen Systemen (insbesondere mit CORBA , COM ) oder Sprachen (insbesondere C++ und Java ) bereitgestellt .

Partitionierung

Die aktuelle Partitionierung finden Sie auf der offiziellen Unicode-Website. Angesichts der wichtigen Rolle von Unicode heute ( ISO / IEC 10646 ) werden hier jedoch die wichtigsten Zeichenblöcke beschrieben. Die französischen Namen sind die offiziellen Namen von ISO / IEC 10646 , dem internationalen zweisprachigen Standard, der dieselben Zeichen wie Unicode verwendet. Sie sind so offiziell wie die englischen Namen.

Der alte Unicode 1.0- Standard ist veraltet und nicht kompatibel mit ISO / IEC 10646 und Unicode 1.1 und all seinen späteren Versionen; die Hauptinkompatibilität ist die der Hangul-Zeichenblöcke, die zum Schreiben der koreanischen Sprache verwendet werden, die ihre Position geändert haben und deren alte Codepunkte inzwischen anderen Blöcken zugewiesen wurden. Die folgende Tabelle ist kompatibel mit ISO / IEC 10646 (alle Versionen) und Unicode 1.1 (oder höher).

Hinweis: Die Schreibweise von Blocknamen ist nicht normativ. „Basic Latin“ ist also gleichbedeutend mit „BASIC LATIN“.

In den folgenden Tabellen bedeutet jeder Blockname mit einem Hinweis zu einem offiziellen Unicode-PDF, dass die mit diesem Block verknüpfte Wikipedia-Seite nicht vorhanden oder falsch ist.