Aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Unicode ist ein Informationstechnologie - Standard für die einheitliche Codierung , Darstellung und Bearbeitung von Text ausgedrückt in den meisten der weltweit Schreibsysteme . Der Standard wird vom Unicode-Konsortium beibehalten und umfasst ab März 2020 insgesamt 143.859 Zeichen. Unicode 13.0 (diese Zeichen bestehen aus 143.696 grafischen Zeichen und 163 Formatzeichen) umfasst 154 moderne und historische Skripte sowie mehrere Symbolsätze und Emoji .

Das Unicode-Zeichenrepertoire ist mit ISO / IEC 10646 synchronisiert , wobei jeder Code für Code mit dem anderen identisch ist. Der Unicode-Standard enthält jedoch mehr als nur den Basiscode. Neben den Zeichenkodierungen enthält die offizielle Veröffentlichung des Konsortiums eine Vielzahl von Details zu den Skripten und deren Anzeige: Normalisierungsregeln , Zerlegung, Sortierung , Wiedergabe und bidirektionale Anzeigereihenfolge für mehrsprachige Texte usw. [1] Die Norm enthält auch Referenzdatendateien und visuelle Diagramme zu helfen Entwickler und das Repertoire korrekt implementieren Designer.

Unicode - Erfolg bei vereinigende Zeichensätzen hat zu seiner weit verbreiteten und überwiegenden Nutzung in der Internationalisierung und Lokalisierung von Computersoftware . Der Standard wurde in vielen neueren Technologien implementiert, einschließlich moderner Betriebssysteme , XML , Java (und anderer Programmiersprachen ) und .NET Framework .

Unicode kann durch verschiedene Zeichencodierungen implementiert werden. Der Unicode-Standard definiert UTF-8 , UTF-16 und UTF-32 sowie mehrere andere Codierungen. Die am häufigsten verwendeten Codierungen sind UTF-8, UTF-16 und UCS-2 (ein Vorläufer von UTF-16 ohne vollständige Unterstützung für Unicode). GB18030 ist in China standardisiert und implementiert Unicode vollständig, ist jedoch kein offizieller Unicode-Standard.

UTF-8, die dominierende Codierung im World Wide Web (ab 2020 in über 95% der Websites und in einigen Sprachen bis zu 100% verwendet) [2] und auf den meisten Unix-ähnlichen Betriebssystemen, verwendet ein Byte [Hinweis 1] (8  Bit ) für die ersten 128 Codepunkte und bis zu 4 Byte für andere Zeichen. [3] Die ersten 128 Unicode-Codepunkte repräsentieren die ASCII- Zeichen, was bedeutet, dass jeder ASCII-Text auch ein UTF-8-Text ist.

UCS-2 verwendet zwei Bytes (16 Bit) für jedes Zeichen, kann jedoch nur die ersten 65.536 Codepunkte codieren , die sogenannte Basic Multilingual Plane (BMP). Mit 1.112.064 möglichen Unicode-Codepunkten, die Zeichen (siehe unten ) in 17 Ebenen entsprechen, und mit über 143.000 Codepunkten, die ab Version 13.0 definiert wurden, kann UCS-2 nur weniger als die Hälfte aller codierten Unicode-Zeichen darstellen. Daher ist UCS-2 veraltet, obwohl es in Software immer noch weit verbreitet ist. UTF-16 erweitert UCS-2 durch Verwendung derselben 16-Bit- Codierung wie UCS-2 für die mehrsprachige Grundebene und einer 4-Byte-Codierung für die anderen Ebenen. Solange es keine Codepunkte im reservierten Bereich U + D800 - U + DFFF enthält, [Klarstellung erforderlich ]Ein UCS-2-Text ist ein gültiger UTF-16-Text.

UTF-32 (auch als UCS-4 bezeichnet) verwendet vier Bytes, um einen bestimmten Codepunkt zu codieren, jedoch nicht unbedingt ein bestimmtes vom Benutzer wahrgenommenes Zeichen (lose gesagt ein Graphem ), da ein vom Benutzer wahrgenommenes Zeichen durch a dargestellt werden kann Graphemcluster (eine Folge mehrerer Codepunkte). [4] Wie bei UCS-2 ist die Anzahl der Bytes pro Codepunkt festgelegt, was die Indizierung von Zeichen erleichtert. Im Gegensatz zu UCS-2 kann UTF-32 jedoch alle Unicode-Codepunkte codieren. Da jedoch jedes Zeichen vier Bytes verwendet, benötigt UTF-32 erheblich mehr Speicherplatz als andere Codierungen und wird nicht häufig verwendet. Obwohl UTF-32 für jeden Codepunkt eine feste Größe hat, ist es auch in Bezug auf vom Benutzer wahrgenommene Zeichen variabel lang. Beispiele sind: dieDevanagari kshi , das von 4 Codepunkten codiert wird, und Nationalflaggen-Emojis, die aus zwei Codepunkten bestehen. [5] Alle kombinierten Zeichenfolgen sind Grapheme, aber es gibt auch andere Folgen von Codepunkten, zum Beispiel \ r \ n . [6] [7] [8] [9]

Herkunft und Entwicklung [ Bearbeiten ]

Unicode hat das explizite Ziel, die Beschränkungen traditioneller Zeichenkodierungen, wie sie in der Norm ISO / IEC 8859 definiert sind, zu überwinden , die in verschiedenen Ländern der Welt weit verbreitet sind, jedoch weitgehend inkompatibel bleiben. Viele traditionelle Zeichenkodierungen haben insofern ein gemeinsames Problem, als sie eine zweisprachige Computerverarbeitung ermöglichen (normalerweise unter Verwendung lateinischer Zeichen und des lokalen Skripts), jedoch keine mehrsprachige Computerverarbeitung (Computerverarbeitung von miteinander gemischten beliebigen Skripten).

Unicode codiert absichtlich die zugrunde liegenden Zeichen - Grapheme und graphemähnliche Einheiten - und nicht die varianten Glyphen (Renderings) für solche Zeichen. Bei chinesischen Schriftzeichen führt dies manchmal zu Kontroversen über die Unterscheidung des zugrunde liegenden Zeichens von seinen varianten Glyphen (siehe Han-Vereinigung ).

Bei der Textverarbeitung übernimmt Unicode die Aufgabe, für jedes Zeichen einen eindeutigen Codepunkt bereitzustellen - eine Zahl , keine Glyphe. Mit anderen Worten, Unicode stellt ein Zeichen auf abstrakte Weise dar und überlässt das visuelle Rendering (Größe, Form, Schriftart oder Stil) einer anderen Software, z. B. einem Webbrowser oder einem Textverarbeitungsprogramm . Dieses einfache Ziel wird jedoch aufgrund von Zugeständnissen der Unicode-Designer in der Hoffnung, eine schnellere Einführung von Unicode zu fördern, kompliziert.

Die ersten 256 Codepunkte wurden mit dem Inhalt von ISO / IEC 8859-1 identisch gemacht, um die Konvertierung von vorhandenem westlichem Text zu vereinfachen. Viele im Wesentlichen identische Zeichen wurden an verschiedenen Codepunkten mehrfach codiert, um die von älteren Codierungen verwendeten Unterscheidungen beizubehalten und daher die Konvertierung von diesen Codierungen in Unicode (und zurück) zu ermöglichen, ohne dass Informationen verloren gehen. Beispielsweise enthält der Abschnitt " Formulare mit voller Breite " von Codepunkten ein vollständiges Duplikat des lateinischen Alphabets, da chinesische, japanische und koreanische ( CJK ) Schriftarten zwei Versionen dieser Buchstaben enthalten, wobei "volle Breite" der Breite der CJK-Zeichen entspricht und normale Breite. Weitere Beispiele finden Sie unter Doppelte Zeichen in Unicode .

Geschichte [ bearbeiten ]

Basierend auf den Erfahrungen mit dem Xerox Character Code Standard (XCCS) seit 1980 [10] reichen die Ursprünge von Unicode bis 1987 zurück, als Joe Becker von Xerox mit Lee Collins und Mark Davis von Apple begann, die praktischen Aspekte der Erstellung eines universellen Zeichensatzes zu untersuchen. [11] Mit zusätzlichen Beiträgen von Peter Fenwick und Dave Opstad [10] veröffentlichte Joe Becker im August 1988 einen Entwurf eines Vorschlags für ein "internationales / mehrsprachiges Textzeichenkodierungssystem mit dem vorläufigen Namen Unicode". Er erklärte, dass "der Name 'Unicode' eine eindeutige, einheitliche, universelle Codierung suggerieren soll". [10]

In diesem Dokument mit dem Titel Unicode 88 skizzierte Becker ein 16-Bit- Zeichenmodell: [10]

Unicode soll die Notwendigkeit einer funktionsfähigen, zuverlässigen Welttextcodierung erfüllen. Unicode könnte grob als "Wide-Body-ASCII" beschrieben werden, das auf 16 Bit erweitert wurde, um die Zeichen aller lebenden Sprachen der Welt zu erfassen. In einem richtig konstruierten Design sind 16 Bit pro Zeichen für diesen Zweck mehr als ausreichend.

Sein ursprüngliches 16-Bit-Design basierte auf der Annahme, dass nur die im modernen Gebrauch verwendeten Skripte und Zeichen codiert werden müssten: [10]

Unicode misst der Sicherstellung des Nutzens für die Zukunft eine höhere Priorität bei als der Erhaltung vergangener Altertümer. Unicode zielt in erster Linie auf die im modernen Text veröffentlichten Zeichen ab (z. B. in der Vereinigung aller 1988 weltweit gedruckten Zeitungen und Zeitschriften), deren Zahl zweifellos weit unter 2 14 = 16.384 liegt. Abgesehen von diesen modernen Zeichen können alle anderen als veraltet oder selten definiert werden. Dies sind bessere Kandidaten für die Registrierung zur privaten Nutzung als für die Überlastung der öffentlichen Liste allgemein nützlicher Unicodes.

Anfang 1989 wurde die Unicode-Arbeitsgruppe um Ken Whistler und Mike Kernaghan von Metaphor, Karen Smith-Yoshimura und Joan Aliprand von RLG sowie Glenn Wright von Sun Microsystems und 1990 um Michel Suignard und Asmus Freytag von Microsoft und Rick McGowan erweitert von NeXT trat der Gruppe bei. Bis Ende 1990 waren die meisten Arbeiten zur Zuordnung bestehender Zeichencodierungsstandards abgeschlossen, und ein endgültiger Überprüfungsentwurf für Unicode war fertig.

Das Unicode-Konsortium wurde am 3. Januar 1991 in Kalifornien gegründet [12], und im Oktober 1991 wurde der erste Band des Unicode-Standards veröffentlicht. Der zweite Band über Han-Ideogramme wurde im Juni 1992 veröffentlicht.

1996 wurde in Unicode 2.0 ein Ersatzzeichenmechanismus implementiert, sodass Unicode nicht mehr auf 16 Bit beschränkt war. Dies erhöhte den Unicode-Codespace auf über eine Million Codepunkte, was die Codierung vieler historischer Skripte (z. B. ägyptischer Hieroglyphen ) und Tausender selten verwendeter oder veralteter Zeichen ermöglichte, von denen nicht erwartet wurde, dass sie codiert werden müssen. Unter den Zeichen, die ursprünglich nicht für Unicode bestimmt waren, befinden sich selten verwendete Kanji-Zeichen oder chinesische Zeichen, von denen viele Teil von Personen- und Ortsnamen sind. Daher werden sie selten verwendet, sind jedoch wesentlich wichtiger als in der ursprünglichen Architektur von Unicode vorgesehen. [13]

In der Microsoft TrueType-Spezifikation Version 1.0 von 1992 wurde der Name Apple Unicode anstelle von Unicode für die Plattform-ID in der Benennungstabelle verwendet.

Unicode-Konsortium [ Bearbeiten ]

Das Unicode-Konsortium ist eine gemeinnützige Organisation, die die Entwicklung von Unicode koordiniert. Vollmitglieder sind die meisten der wichtigsten Computer-Software- und -Hardware-Unternehmen, die sich für Textverarbeitungsstandards interessieren, darunter Adobe , Apple , Facebook , Google , IBM , Microsoft , Netflix und SAP SE . [14]

Im Laufe der Jahre waren mehrere Länder oder Regierungsbehörden Mitglieder des Unicode-Konsortiums. Derzeit ist nur das Ministerium für Stiftungen und religiöse Angelegenheiten (Oman) Vollmitglied mit Stimmrecht. [14]

Das Konsortium hat das ehrgeizige Ziel, vorhandene Zeichenkodierungsschemata durch Unicode und seine Standard-UTF-Schemata (Unicode Transformation Format) zu ersetzen, da viele der vorhandenen Schemata in Größe und Umfang begrenzt und mit mehrsprachigen Umgebungen nicht kompatibel sind .

Abgedeckte Skripte [ Bearbeiten ]

Viele moderne Anwendungen können eine wesentliche Teilmenge der vielen Skripte in Unicode rendern , wie dieser Screenshot aus der OpenOffice.org- Anwendung zeigt.

Unicode deckt fast alle Skripte ( Schreibsysteme ) ab, die derzeit verwendet werden. [15] [ fehlgeschlagene Überprüfung ] [16]

In der neuesten Version von Unicode (mit Alphabeten , Abugidas und Silben ) sind insgesamt 154 Skripte enthalten , obwohl es noch Skripte gibt, die noch nicht codiert sind, insbesondere solche, die hauptsächlich in historischen, liturgischen und akademischen Kontexten verwendet werden. Weitere Ergänzungen von Zeichen zu den bereits codierten Skripten sowie Symbole, insbesondere für Mathematik und Musik (in Form von Noten und rhythmischen Symbolen), treten ebenfalls auf.

Das Unicode-Roadmap-Komitee ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran [17] ) führt die Liste der Skripte, die Kandidaten oder potenzielle Kandidaten für die Codierung sind, und ihre vorläufigen Codeblockzuweisungen auf der Unicode-Roadmap- Seite der Unicode-Konsortium- Website . Für einige Skripte auf der Roadmap, wie z. B. kleine Skripte von Jurchen und Khitan , wurden Kodierungsvorschläge gemacht, die sich durch den Genehmigungsprozess arbeiten. Für andere Skripte wie Maya (neben Zahlen) und RongorongoEs wurde noch kein Vorschlag gemacht, und sie warten auf eine Einigung über das Charakterrepertoire und andere Details der beteiligten Benutzergemeinschaften.

Einige moderne erfundene Skripte, die noch nicht in Unicode enthalten sind (z. B. Tengwar ) oder die aufgrund mangelnder Verwendung in der realen Welt nicht in Unicode aufgenommen werden können (z. B. Klingonisch ) , werden zusammen mit inoffiziellen Skripten in der ConScript-Unicode-Registrierung aufgeführt aber weit verbreitete Codezuweisungen für Bereiche für den privaten Gebrauch .

Es gibt auch eine mittelalterliche Unicode-Schriftinitiative, die sich auf spezielle lateinische mittelalterliche Zeichen konzentriert. Ein Teil dieser Vorschläge wurde bereits in Unicode aufgenommen.

Die Script Encoding Initiative , ein Projekt von Deborah Anderson an der University of California in Berkeley, wurde 2002 mit dem Ziel gegründet, Vorschläge für Skripte zu finanzieren, die noch nicht im Standard kodiert sind. Das Projekt hat sich in den letzten Jahren zu einer wichtigen Quelle für vorgeschlagene Ergänzungen des Standards entwickelt. [18]

Versionen [ bearbeiten ]

Das Unicode-Konsortium und die Internationale Organisation für Normung haben nach der Erstveröffentlichung des Unicode-Standards im Jahr 1991 gemeinsam ein gemeinsames Repertoire entwickelt . Tatsächlich verwenden Unicode und der universelle codierte Zeichensatz der ISO identische Zeichennamen und Codepunkte. Die Unicode-Versionen unterscheiden sich jedoch in zwei wesentlichen Punkten von ihren ISO-Entsprechungen.

Während das UCS eine einfache Zeichentabelle ist, gibt Unicode zunächst die Regeln, Algorithmen und Eigenschaften an, die erforderlich sind, um die Interoperabilität zwischen verschiedenen Plattformen und Sprachen zu erreichen. Daher enthält der Unicode-Standard weitere Informationen, die sich eingehend mit Themen wie bitweiser Codierung, Sortierung und Rendering befassen . Es bietet auch einen umfassenden Katalog von Zeicheneigenschaften, einschließlich der zur Unterstützung von bidirektionalem Text erforderlichen , sowie visuelle Diagramme und Referenzdatensätze, um Implementierern zu helfen. Zuvor der Unicode- Standardwurde als Druckvolumen verkauft, das die vollständige Kernspezifikation, Standardanhänge und Codetabellen enthielt. Unicode 5.0, das 2006 veröffentlicht wurde, war jedoch die letzte Version, die auf diese Weise gedruckt wurde. Ab Version 5.2 kann nur die Kernspezifikation erworben werden, die als Print-on-Demand-Taschenbuch veröffentlicht wurde. [19] Der vollständige Text wird dagegen als kostenloses PDF auf der Unicode-Website veröffentlicht.

Ein praktischer Grund für diese Veröffentlichungsmethode ist der zweite signifikante Unterschied zwischen UCS und Unicode - die Häufigkeit, mit der aktualisierte Versionen veröffentlicht und neue Zeichen hinzugefügt werden. Der Unicode-Standard hat regelmäßig erweiterte Jahresversionen veröffentlicht, gelegentlich mit mehr als einer Version in einem Kalenderjahr und in seltenen Fällen, in denen die geplante Version verschoben werden musste. Beispielsweise gab das Unicode-Konsortium im April 2020, nur einen Monat nach Veröffentlichung von Version 13.0, bekannt, dass das geplante Veröffentlichungsdatum für Version 14.0 geändert und aufgrund der COVID-19-Pandemie um sechs Monate von März 2021 auf September 2021 verschoben wurde . Unicode 14.0 soll mindestens fünf neue Skripte sowie siebenunddreißig neue Emoji-Zeichen enthalten. [20]

Bisher wurden die folgenden Haupt- und Nebenversionen des Unicode-Standards veröffentlicht. Aktualisierungsversionen, die keine Änderungen am Zeichenrepertoire enthalten, sind durch die dritte Nummer (z. B. "Version 4.0.1") gekennzeichnet und werden in der folgenden Tabelle weggelassen. [21]

  1. ^ Die Anzahl der Zeichen für jede Version von Unicode aufgelistet ist die Gesamtzahl der Grafik- und Formatierungszeichen (dh ohne Berücksichtigung der privaten Gebrauch Zeichen , Steuerzeichen , noncharacters und Surrogat - Codepunkte ).

Architektur und Terminologie [ Bearbeiten ]

Der Unicode-Standard definiert einen Codespace [53], einen Satz numerischer Werte im Bereich von 0 bis 10FFFF 16 , [54], die als Codepunkte [55] bezeichnet werden und als U + 0000 bis U + 10FFFF ("U +" plus den Codepunktwert) bezeichnet werden in hexadezimaler Reihenfolge, vorangestellt mit führenden Nullen , falls erforderlich, um mindestens vier Ziffern zu erhalten, z. B. U + 00F7 für das Teilungszeichen, ÷, gegenüber U + 13254 für die ägyptische Hieroglyphe, die einen Schilfschutz oder eine gewundene Wand bezeichnet ( ) [56] ] ). Davon 2 16 + 2 20definierte Codepunkte, die Codepunkte von U + D800 bis U + DFFF, die zum Codieren von Ersatzpaaren in UTF-16 verwendet werden , sind vom Standard reserviert und dürfen nicht zum Codieren gültiger Zeichen verwendet werden, was zu einer Netto-Gesamtsumme von 2 führt 16 - 2 11 + 2 20 = 1.112.064 mögliche Codepunkte, die gültigen Unicode-Zeichen entsprechen. Nicht alle dieser Codepunkte entsprechen notwendigerweise sichtbaren Zeichen. Einige sind beispielsweise Steuercodes wie dem Wagenrücklauf zugeordnet .

Code-Ebenen und -Blöcke [ Bearbeiten ]

Der Unicode-Codespace ist in siebzehn Ebenen mit den Nummern 0 bis 16 unterteilt:

Auf alle Codepunkte im BMP wird als einzelne Codeeinheit in UTF-16- Codierung zugegriffen und kann in UTF-8 in einem, zwei oder drei Bytes codiert werden . Auf Codepunkte in den Ebenen 1 bis 16 ( zusätzliche Ebenen ) wird in UTF-16 als Ersatzpaar zugegriffen und in UTF-8 in vier Bytes codiert.

Innerhalb jeder Ebene werden Zeichen in benannten Blöcken verwandter Zeichen zugewiesen . Obwohl Blöcke eine beliebige Größe haben, sind sie immer ein Vielfaches von 16 Codepunkten und häufig ein Vielfaches von 128 Codepunkten. Die für ein bestimmtes Skript erforderlichen Zeichen können auf mehrere verschiedene Blöcke verteilt sein.

Allgemeine Kategorieeigenschaft [ Bearbeiten ]

Jeder Codepunkt verfügt über eine einzelne Eigenschaft für die allgemeine Kategorie . Die Hauptkategorien werden bezeichnet: Buchstabe, Markierung, Zahl, Zeichensetzung, Symbol, Trennzeichen und andere. Innerhalb dieser Kategorien gibt es Unterteilungen. In den meisten Fällen müssen andere Eigenschaften verwendet werden, um die Eigenschaften eines Codepunkts ausreichend anzugeben. Die möglichen allgemeinen Kategorien sind:

Codepunkte in dem U + D800 + DBFF-U (1.024 Codepunkte) Bereich sind als hoch bekannte Surrogat Codepunkte und Codepunkte im Bereich U + DC00-U + DFFF (1.024 Codepunkte) werden als Low-Surrogat bekannt Codepunkte. Ein Codepunkt mit hohem Ersatzcode, gefolgt von einem Codepunkt mit niedrigem Ersatzcode, bildet in UTF-16 ein Ersatzpaar , um Codepunkte darzustellen, die größer als U + FFFF sind. Diese Codepunkte können ansonsten nicht verwendet werden (diese Regel wird in der Praxis häufig ignoriert, insbesondere wenn UTF-16 nicht verwendet wird).

Es wird garantiert, dass ein kleiner Satz von Codepunkten niemals zum Codieren von Zeichen verwendet wird, obwohl Anwendungen diese Codepunkte auf Wunsch intern verwenden können. Es gibt sechsundsechzig dieser Nichtzeichen : U + FDD0 - U + FDEF und jeden Codepunkt, der mit dem Wert FFFE oder FFFF endet (dh U + FFFE, U + FFFF, U + 1FFFE, U + 1FFFF, ... U. + 10FFFE, U + 10FFFF). Der Satz von Nichtcharakteren ist stabil und es werden niemals neue Nichtcharaktere definiert. [57] Wie bei Ersatzzeichen wird die Regel, dass diese nicht verwendet werden können, häufig ignoriert, obwohl bei der Operation der Bytereihenfolge davon ausgegangen wird, dass U + FFFE niemals der erste Codepunkt in einem Text sein wird.

Ohne Surrogate und Nicht-Zeichen stehen 1.111.998 Codepunkte zur Verfügung.

Codepunkte für den privaten Gebrauch gelten als zugewiesene Zeichen, haben jedoch keine im Unicode-Standard [58] festgelegte Interpretation, sodass für den Austausch solcher Zeichen eine Vereinbarung zwischen Absender und Empfänger über ihre Interpretation erforderlich ist. Es gibt drei Bereiche für den privaten Gebrauch im Unicode-Codespace:

  • Bereich für den privaten Gebrauch: U + E000 - U + F8FF (6.400 Zeichen),
  • Zusätzlicher Bereich für den privaten Gebrauch - A: U + F0000 - U + FFFFD (65.534 Zeichen),
  • Zusätzlicher Bereich B für den privaten Gebrauch: U + 100000 - U + 10FFFD (65.534 Zeichen).

Grafische Zeichen sind Zeichen, die von Unicode für eine bestimmte Semantik definiert wurden und entweder eine sichtbare Glyphenform haben oder einen sichtbaren Raum darstellen. Ab Unicode 13.0 gibt es 143.696 grafische Zeichen.

Formatzeichen sind Zeichen, die kein sichtbares Erscheinungsbild haben, sich jedoch auf das Erscheinungsbild oder Verhalten benachbarter Zeichen auswirken können. Beispielsweise können U + 200C ZERO WIDTH NON-JOINER und U + 200D ZERO WIDTH JOINER verwendet werden, um das Standardformungsverhalten benachbarter Zeichen zu ändern (z. B. um Ligaturen zu hemmen oder die Bildung von Ligaturen anzufordern). Unicode 13.0 enthält 163 Formatzeichen.

Fünfundsechzig Codepunkte (U + 0000-U + 001F und 007F-U + U + 009F) werden als reservierte Steuercodes und entsprechen den C0 und C1 - Steuercodes in definierten ISO / IEC 6429 . U + 0009 (Tab), U + 000A (Zeilenvorschub) und U + 000D (Wagenrücklauf) werden häufig in Unicode-codierten Texten verwendet. In der Praxis werden die C1-Codepunkte häufig falsch übersetzt ( Mojibake ) als die alten Windows-1252- Zeichen, die von einigen englischen und westeuropäischen Texten verwendet werden.

Grafikzeichen, Formatzeichen, Steuercodezeichen und Zeichen für den privaten Gebrauch werden zusammen als zugewiesene Zeichen bezeichnet . Reservierte Codepunkte sind diejenigen Codepunkte, die zur Verwendung verfügbar sind, aber noch nicht zugewiesen wurden. Ab Unicode 13.0 sind 830.606 Codepunkte reserviert.

Abstrakte Zeichen [ Bearbeiten ]

Der von Unicode definierte Satz von Grafik- und Formatzeichen entspricht nicht direkt dem Repertoire abstrakter Zeichen , das unter Unicode dargestellt werden kann. Unicode codiert Zeichen, indem ein abstraktes Zeichen einem bestimmten Codepunkt zugeordnet wird. [59] Es werden jedoch nicht alle abstrakten Zeichen als ein einziges Unicode-Zeichen codiert, und einige abstrakte Zeichen können in Unicode durch eine Folge von zwei oder mehr Zeichen dargestellt werden. Zum Beispiel ein lateinischer Kleinbuchstabe "i" mit einem Ogonek , einem Punkt darüber und einem akuten Akzent , der auf Litauisch erforderlich istwird durch die Zeichenfolge U + 012F, U + 0307, ​​U + 0301 dargestellt. Unicode verwaltet eine Liste eindeutig benannter Zeichenfolgen für abstrakte Zeichen, die nicht direkt in Unicode codiert sind. [60]

Alle Zeichen für Grafik, Format und privaten Gebrauch haben einen eindeutigen und unveränderlichen Namen, anhand dessen sie identifiziert werden können. Diese Unveränderlichkeit wurde seit Unicode Version 2.0 durch die Richtlinie zur Namensstabilität garantiert. [57] In Fällen, in denen der Name schwerwiegend fehlerhaft und irreführend ist oder einen schwerwiegenden Tippfehler aufweist, kann ein formaler Alias ​​definiert werden, und Anträge werden aufgefordert, den formalen Alias ​​anstelle des offiziellen Charakternamens zu verwenden. Zum Beispiel hat U + A015YI SYLLABLE WU den formalen Alias YI SYLLABLE ITERATION MARK und U + FE18PRÄSENTATIONSFORMULAR FÜR VERTIKAL RECHTS WEISS LENTICULAR BRA KC ET ( sic ) den formalen Alias PRÄSENTATIONSFORMULAR FÜR VERTIKAL RECHTS WEISS LENTIKULAR BRA CK ET . [61]

Fertige versus zusammengesetzte Zeichen [ Bearbeiten ]

Unicode enthält einen Mechanismus zum Ändern von Zeichen, der das unterstützte Glyphenrepertoire erheblich erweitert. Dies umfasst die Verwendung der Kombination diakritischer Zeichen , die vom Benutzer nach dem Basiszeichen hinzugefügt werden können. Mehrere kombinierte Diakritika können gleichzeitig auf dasselbe Zeichen angewendet werden. Unicode enthält auch vorkomponierte Versionen der meisten Buchstaben / diakritischen Kombinationen bei normaler Verwendung. Diese vereinfachen die Konvertierung in und aus Legacy-Codierungen und ermöglichen es Anwendungen, Unicode als internes Textformat zu verwenden, ohne das Kombinieren von Zeichen implementieren zu müssen. Zum Beispiel kann é in Unicode als U + 0065 ( LATEINISCHER KLEINBUCHSTABE E ) gefolgt von U + 0301 ( KOMBINIEREN VON AKUTEM AKZENT) dargestellt werden), kann aber auch als vorkomponiertes Zeichen U + 00E9 ( LATEINISCHER KLEINBUCHSTABE E MIT AKUT ) dargestellt werden. Daher haben Benutzer in vielen Fällen mehrere Möglichkeiten, dasselbe Zeichen zu codieren. Um dies zu bewältigen, bietet Unicode den Mechanismus der kanonischen Äquivalenz .

Ein Beispiel hierfür ist Hangul , das koreanische Alphabet. Unicode bietet einen Mechanismus zum Zusammensetzen von Hangul-Silben mit ihren einzelnen Unterkomponenten, bekannt als Hangul Jamo . Es enthält jedoch auch 11.172 Kombinationen vorkomponierter Silben, die aus dem gebräuchlichsten Jamo hergestellt werden.

Die CJK- Zeichen haben derzeit nur Codes für ihre vorkomponierte Form. Die meisten dieser Zeichen bestehen jedoch aus einfacheren Elementen ( Radikale genannt ), sodass Unicode sie im Prinzip wie bei Hangul hätte zerlegen können. Dies hätte die Anzahl der erforderlichen Codepunkte erheblich reduziert und gleichzeitig die Anzeige praktisch aller denkbaren Zeichen ermöglicht (was einige der durch die Han-Vereinigung verursachten Probleme beseitigen könnte ). Eine ähnliche Idee wird von einigen Eingabemethoden wie Cangjie und Wubi verwendet . Versuche, dies für die Zeichenkodierung zu tun, sind jedoch auf die Tatsache gestoßen, dass chinesische Schriftzeichen nicht so einfach oder so regelmäßig zerfallen wie Hangul.

In Unicode 3.0 wurde eine Reihe von Radikalen bereitgestellt (CJK-Radikale zwischen U + 2E80 und U + 2EFF, KangXi-Radikale in U + 2F00 bis U + 2FDF und ideografische Beschreibungszeichen von U + 2FF0 bis U + 2FFB), jedoch der Unicode-Standard (Kapitel 12.2 von Unicode 5.2) warnt davor, ideografische Beschreibungssequenzen als alternative Darstellung für zuvor codierte Zeichen zu verwenden:

Dieser Prozess unterscheidet sich von einer formalen Kodierung eines Ideogramms. Es gibt keine kanonische Beschreibung von nicht kodierten Ideogrammen; den beschriebenen Ideogrammen ist keine Semantik zugeordnet; Für die beschriebenen Ideogramme ist keine Äquivalenz definiert. Konzeptionell ähneln ideografische Beschreibungen eher der englischen Phrase "ein 'e' mit einem akuten Akzent" als der Zeichenfolge <U + 0065, U + 0301>.

Ligaturen [ Bearbeiten ]

Viele Skripte, darunter Arabisch und Devanāgarī , haben spezielle Rechtschreibregeln , die erfordern , bestimmte Kombinationen von Buchstabenformen in spezielle kombiniert werden Ligatur Formen . Die Regeln für die Ligaturbildung können sehr komplex sein und erfordern spezielle Skriptformungstechnologien wie ACE (Arabic Calligraphic Engine von DecoType in den 1980er Jahren, mit der alle arabischen Beispiele in den gedruckten Ausgaben des Unicode-Standards generiert wurden), die zum Beweis wurden Konzept für OpenType (von Adobe und Microsoft), Graphite (von SIL International ) oder AAT (von Apple).

Anweisungen sind auch in Schriftarten eingebettet, um das Betriebssystem zu informierenwie man verschiedene Zeichenfolgen richtig ausgibt. Eine einfache Lösung für die Platzierung von kombinierten Markierungen oder diakritischen Zeichen besteht darin, den Markierungen eine Breite von Null zuzuweisen und die Glyphe selbst links oder rechts vom linken Seitenträger zu platzieren (abhängig von der Richtung des Skripts, mit dem sie verwendet werden sollen). Eine Markierung, die auf diese Weise behandelt wird, wird über dem vorangestellten Zeichen angezeigt, passt jedoch ihre Position nicht relativ zur Breite oder Höhe des Basisglyphen an. Es kann visuell umständlich sein und einige Glyphen überlappen. Ein echtes Stapeln ist unmöglich, kann aber in begrenzten Fällen angenähert werden (zum Beispiel können thailändische Top-Kombinationsvokale und Tonmarkierungen zunächst nur unterschiedliche Höhen haben). Im Allgemeinen ist dieser Ansatz nur bei monospaced Schriftarten wirksam, kann jedoch als Fallback-Rendering-Methode verwendet werden, wenn komplexere Methoden fehlschlagen.

Standardisierte Teilmengen [ Bearbeiten ]

Mehrere Untergruppen von Unicode sind standardisiert: Microsoft Windows seit Windows NT 4.0 unterstützt WGL-4 mit 657 Zeichen, die alle europäischen Sprachen betrachtet wird mit der lateinischen, griechischen oder kyrillischen Schrift zu unterstützen. Andere standardisierte Untergruppen von Unicode umfassen die mehrsprachigen europäischen Untergruppen: [62]

MES-1 (nur lateinische Skripte, 335 Zeichen), MES-2 (lateinische, griechische und kyrillische 1062 Zeichen) [63] und MES-3A & MES-3B (zwei größere Teilmengen, hier nicht gezeigt). Beachten Sie, dass MES-2 alle Zeichen in MES-1 und WGL-4 enthält.

Rendering-Software, die ein Unicode-Zeichen nicht angemessen verarbeiten kann, zeigt es häufig als offenes Rechteck oder als Unicode- Ersatzzeichen (U + FFFD, ) an, um die Position des nicht erkannten Zeichens anzuzeigen. Einige Systeme haben versucht, mehr Informationen über solche Zeichen bereitzustellen. Apple Last Resort Schrift wird eine Ersatz Glyphe , die den Unicode - Bereich des Zeichens anzuzeigen, und die SIL International ‚s Unicode Fallback - Schrift wird eine Box zeigt den hexadezimalen skalaren Wert des Zeichens angezeigt werden soll .

Mapping und Codierungen [ Bearbeiten ]

Es wurden verschiedene Mechanismen zum Speichern einer Reihe von Codepunkten als eine Reihe von Bytes angegeben.

Unicode definiert zwei Zuordnungsmethoden: die UTF-Codierungen ( Unicode Transformation Format ) und die UCS-Codierungen ( Universal Coded Character Set ). Eine Codierung ordnet (möglicherweise eine Teilmenge davon) den Bereich des Unicode- Codes zu und zeigt auf Folgen von Werten in einem Bereich fester Größe, die als Codeeinheiten bezeichnet werden . Alle UTF-Codierungen ordnen Codepunkte einer eindeutigen Folge von Bytes zu. [64] Die Zahlen in den Namen der Codierungen geben die Anzahl der Bits pro Codeeinheit (für UTF-Codierungen) oder die Anzahl der Bytes pro Codeeinheit (für UCS-Codierungen und UTF-1) an. UTF-8 und UTF-16 sind die am häufigsten verwendeten Codierungen. UCS-2 ist eine veraltete Teilmenge von UTF-16. UCS-4 und UTF-32 sind funktional gleichwertig.

UTF-Codierungen umfassen:

  • UTF-1 , ein pensionierter Vorgänger von UTF-8, maximiert die Kompatibilität mit ISO 2022 , das nicht mehr Teil des Unicode-Standards ist
  • UTF-7 , eine veraltete 7-Bit-Codierung, die manchmal in E-Mails verwendet wird (nicht Teil des Unicode-Standards , sondern nur als Informations- RFC dokumentiert , dh nicht im Internet Standards Track).
  • UTF-8 verwendet ein bis vier Bytes für jeden Codepunkt und maximiert die Kompatibilität mit ASCII
  • UTF-EBCDIC , ähnlich wie UTF-8, jedoch auf Kompatibilität mit EBCDIC ausgelegt (nicht Teil des Unicode-Standards )
  • UTF-16 verwendet eine oder zwei 16-Bit-Codeeinheiten pro Codepunkt und kann keine Ersatzzeichen codieren
  • UTF-32 verwendet eine 32-Bit-Codeeinheit pro Codepunkt

UTF-8 verwendet ein bis vier Bytes pro Codepunkt und bietet, da es für lateinische Skripte kompakt und ASCII-kompatibel ist, die De-facto- Standardcodierung für den Austausch von Unicode-Text. Es wird von FreeBSD und den neuesten Linux-Distributionen als direkter Ersatz für ältere Codierungen in der allgemeinen Textverarbeitung verwendet.

Die UCS-2- und UTF-16-Codierungen geben das Unicode- Byte-Ordnungszeichen ( Unicode Byte Order Mark, BOM) zur Verwendung am Anfang von Textdateien an, das zur Erkennung der Bytereihenfolge (oder zur Erkennung der Bytenendigkeit ) verwendet werden kann. Die Stückliste, Codepunkt U + FEFF, hat die wichtige Eigenschaft der Eindeutigkeit bei der Byte-Neuordnung, unabhängig von der verwendeten Unicode-Codierung. U + FFFE (das Ergebnis des Byte-Austauschs von U + FEFF) entspricht keinem legalen Zeichen, und U + FEFF an anderen Stellen als dem Textanfang übermittelt den nicht unterbrechenden Leerzeichen mit der Breite Null (ein Zeichen ohne Erscheinungsbild und keine andere Wirkung als die Verhinderung der Bildung von Ligaturen ).

Das gleiche in UTF-8 konvertierte Zeichen wird zur Bytefolge EF BB BF. Der Unicode-Standard erlaubt, dass die Stückliste "als Signatur für UTF-8-codierten Text dienen kann, bei dem der Zeichensatz nicht markiert ist". [65] Einige Softwareentwickler haben es für andere Codierungen, einschließlich UTF-8, übernommen, um UTF-8 von lokalen 8-Bit- Codepages zu unterscheiden . Jedoch RFC 3629 Der UTF-8-Standard empfiehlt, dass Byte-Ordnungsmarkierungen in Protokollen, die UTF-8 verwenden, verboten sind, erörtert jedoch die Fälle, in denen dies möglicherweise nicht möglich ist. Darüber hinaus bedeutet die große Einschränkung möglicher Muster in UTF-8 (zum Beispiel kann es keine einzelnen Bytes mit gesetztem High-Bit geben), dass es möglich sein sollte, UTF-8 von anderen Zeichenkodierungen zu unterscheiden, ohne sich auf die Stückliste zu verlassen.

In UTF-32 und UCS-4 dient eine 32-Bit- Codeeinheit als ziemlich direkte Darstellung des Codepunkts eines Zeichens (obwohl die Endianness, die auf verschiedenen Plattformen variiert, die Manifestation der Codeeinheit als Byte-Sequenz beeinflusst). In den anderen Codierungen kann jeder Codepunkt durch eine variable Anzahl von Codeeinheiten dargestellt werden. UTF-32 wird häufig als interne Darstellung von Text in Programmen verwendet (im Gegensatz zu gespeichertem oder übertragenem Text), da jedes Unix-Betriebssystem, das die gcc- Compiler zum Generieren von Software verwendet, diese als Standardcodierung für " breite Zeichen " verwendet. Einige Programmiersprachen wie Seed7 verwenden UTF-32 als interne Darstellung für Zeichenfolgen und Zeichen. Neueste Versionen von PythonDie Programmiersprache (beginnend mit 2.2) kann auch so konfiguriert werden, dass UTF-32 als Darstellung für Unicode-Zeichenfolgen verwendet wird, wodurch eine solche Codierung in codierter Software auf hoher Ebene effektiv verbreitet wird .

Punycode , eine andere Codierungsform, ermöglicht die Codierung von Unicode-Zeichenfolgen in den begrenzten Zeichensatz, der vom ASCII- basierten Domain Name System (DNS) unterstützt wird. Die Codierung wird als Teil von IDNA verwendet , einem System, das die Verwendung von internationalisierten Domänennamen in allen von Unicode unterstützten Skripten ermöglicht. Frühere und jetzt historische Vorschläge umfassen UTF-5 und UTF-6 .

GB18030 ist eine weitere Codierungsform für Unicode von der Standardization Administration of China . Es ist der offizielle Zeichensatz der Volksrepublik China (VR China). BOCU-1 und SCSU sind Unicode-Komprimierungsschemata. Der April Fools 'Day RFC von 2005 spezifizierte zwei UTF- Parodiecodierungen , UTF-9 und UTF-18 .

Annahme [ Bearbeiten ]

Betriebssysteme [ Bearbeiten ]

Unicode ist zum vorherrschenden Schema für die interne Verarbeitung und Speicherung von Text geworden. Obwohl noch viel Text in Legacy-Codierungen gespeichert ist, wird Unicode fast ausschließlich zum Aufbau neuer Informationsverarbeitungssysteme verwendet. Frühe Anwender tendierten dazu, UCS-2 (den Zwei-Byte-Vorläufer mit fester Breite für UTF-16) zu verwenden, und wechselten später zu UTF-16 (dem aktuellen Standard mit variabler Breite), da dies die am wenigsten störende Möglichkeit war, Unterstützung für Nicht hinzuzufügen -BMP-Zeichen. Das bekannteste System dieser Art ist Windows NT (und seine Nachkommen Windows 2000 , Windows XP , Windows Vista , Windows 7 , Windows 8 und Windows 10)), die UTF-16 als einzige interne Zeichenkodierung verwendet. Die Java- und .NET- Bytecode-Umgebungen, macOS und KDE verwenden es auch für die interne Darstellung. Teilweise Unterstützung für Unicode kann unter Windows 9x über Microsoft Layer for Unicode installiert werden .

UTF-8 (ursprünglich für Plan 9 entwickelt ) [66] ist auf den meisten Unix-ähnlichen Betriebssystemen (obwohl andere auch von einigen Bibliotheken verwendet werden) zur Hauptspeichercodierung geworden, da es einen relativ einfachen Ersatz für herkömmliche erweiterte ASCII- Zeichensätze darstellt. UTF-8 ist auch die häufigste Unicode-Codierung, die in HTML- Dokumenten im World Wide Web verwendet wird .

Zu den mehrsprachigen Text-Rendering-Engines, die Unicode verwenden, gehören Uniscribe und DirectWrite für Microsoft Windows, ATSUI und Core Text für macOS sowie Pango für GTK + und den GNOME- Desktop.

Eingabemethoden [ Bearbeiten ]

Da Tastaturlayouts nicht für alle Zeichen einfache Tastenkombinationen enthalten können, bieten mehrere Betriebssysteme alternative Eingabemethoden, die den Zugriff auf das gesamte Repertoire ermöglichen.

ISO / IEC 14755 , [67] , die Verfahren für die Eingabe von Unicode - Zeichen aus den Codepunkten legt verschiedene Verfahren standardisiert. Es gibt die Basic-Methode , bei der auf eine Anfangssequenz die hexadezimale Darstellung des Codepunkts und der Endsequenz folgt . Es wird auch eine Bildschirmauswahl-Eingabemethode angegeben, bei der die Zeichen in einer Tabelle auf einem Bildschirm aufgelistet werden, z. B. mit einem Zeichentabellenprogramm.

Zu den Online-Tools zum Auffinden des Codepunkts für ein bekanntes Zeichen gehören Unicode Lookup [68] von Jonathan Hedley und Shapecatcher [69] von Benjamin Milde. Bei der Unicode-Suche gibt man einen Suchschlüssel (z. B. "Brüche") ein und eine Liste der entsprechenden Zeichen mit ihren Codepunkten wird zurückgegeben. In Shapecatcher, basierend auf Form Kontext , zieht man die Zeichen in einem Feld und eine Liste von Zeichen , die Zeichnung annähert, mit ihren Codepunkten, zurückgegeben.

E-Mail [ bearbeiten ]

MIME definiert zwei verschiedene Mechanismen zum Codieren von Nicht-ASCII-Zeichen in E-Mails , je nachdem, ob sich die Zeichen in E-Mail-Headern (z. B. "Betreff:") oder im Textkörper der Nachricht befinden. In beiden Fällen wird der ursprüngliche Zeichensatz sowie eine Übertragungscodierung identifiziert. Für die E-Mail-Übertragung von Unicode werden der UTF-8- Zeichensatz und die Base64- oder die Quoted-Printable- Übertragungscodierung empfohlen, je nachdem, ob ein Großteil der Nachricht aus ASCII- Zeichen besteht. Die Details der beiden unterschiedlichen Mechanismen sind in den MIME-Standards festgelegt und für Benutzer von E-Mail-Software im Allgemeinen nicht sichtbar.

Die Einführung von Unicode in E-Mails war sehr langsam. Einige ostasiatische Texte sind immer noch in Codierungen wie ISO-2022 codiert , und einige Geräte, wie z. B. Mobiltelefone, können Unicode-Daten immer noch nicht korrekt verarbeiten. Die Unterstützung hat sich jedoch verbessert. Viele große kostenlose Mail-Anbieter wie Yahoo , Google ( Gmail ) und Microsoft ( Outlook.com ) unterstützen dies.

Web [ bearbeiten ]

Alle W3C- Empfehlungen verwenden seit HTML 4.0 Unicode als Dokumentzeichensatz . Webbrowser unterstützen Unicode, insbesondere UTF-8, seit vielen Jahren. Früher gab es Anzeigeprobleme, die hauptsächlich auf Probleme mit der Schrift zurückzuführen waren . Beispiel: Version 6 und älter von Microsoft Internet Explorer hat nicht viele Codepunkte gerendert, es sei denn, Sie wurden ausdrücklich aufgefordert, eine Schriftart zu verwenden, die diese enthält. [70]

Obwohl Syntaxregeln die Reihenfolge beeinflussen können, in der Zeichen angezeigt werden dürfen, enthalten XML- Dokumente (einschließlich XHTML ) per Definition [71] Zeichen aus den meisten Unicode-Codepunkten, mit Ausnahme von:

  • die meisten C0-Steuercodes ,
  • die permanent nicht zugewiesenen Codepunkte D800 - DFFF,
  • FFFE oder FFFF.

HTML-Zeichen manifestieren sich entweder direkt als Bytes gemäß der Codierung des Dokuments, wenn die Codierung sie unterstützt, oder Benutzer können sie als numerische Zeichenreferenzen basierend auf dem Unicode-Codepunkt des Zeichens schreiben. Zum Beispiel ist die Referenzen &#916;, &#1049;, &#1511;, &#1605;, &#3671;, &#12354;, &#21494;, &#33865;, und &#47568;(oder die gleichen in hexadezimal ausgedrückt numerischen Werten, mit &#xals Präfix) sollte auf allen Browsern als Δ, Й, zeigen ק, م, 7,あ,叶,葉und 말.

Bei der Angabe von URIs , beispielsweise als URLs in HTTP- Anforderungen, müssen Nicht-ASCII-Zeichen in Prozent codiert werden .

Schriftarten [ bearbeiten ]

Unicode befasst sich im Prinzip nicht mit Schriftarten an sich und betrachtet sie als Implementierungsoptionen. [72] Jeder gegebene Charakter kann viele Allographen haben , von den allgemeineren Fett-, Kursiv- und Basisbuchstabenformen bis hin zu komplexen dekorativen Stilen. Eine Schriftart ist "Unicode-kompatibel", wenn auf die Glyphen in der Schriftart mithilfe von Codepunkten zugegriffen werden kann, die im Unicode-Standard definiert sind. [73] Der Standard legt keine Mindestanzahl von Zeichen fest, die in der Schriftart enthalten sein müssen. Einige Schriftarten haben ein recht kleines Repertoire.

Kostenlose und im Einzelhandel erhältliche Schriftarten, die auf Unicode basieren, sind weit verbreitet, da TrueType und OpenType Unicode unterstützen. Diese Schriftformate ordnen Unicode-Codepunkte Glyphen zu, TrueType-Schriftarten sind jedoch auf 65.535 Glyphen beschränkt.

Es gibt Tausende von Schriftarten auf dem Markt, aber weniger als ein Dutzend Schriftarten - manchmal als "Pan-Unicode" -Schriftarten bezeichnet - versuchen, den Großteil des Charakterrepertoires von Unicode zu unterstützen. Stattdessen konzentrieren sich Unicode-basierte Schriftarten in der Regel darauf, nur grundlegende ASCII- und bestimmte Skripts oder Zeichensätze oder Symbole zu unterstützen. Mehrere Gründe rechtfertigen diesen Ansatz: Anwendungen und Dokumente müssen selten Zeichen aus mehr als einem oder zwei Schriftsystemen rendern. Schriftarten erfordern in Computerumgebungen in der Regel Ressourcen. Betriebssysteme und Anwendungen weisen eine zunehmende Intelligenz in Bezug auf das Abrufen von Glypheninformationen aus separaten Schriftdateien nach Bedarf auf, dh das Ersetzen von Schriftarten. Darüber hinaus ist das Entwerfen eines konsistenten Satzes von Renderanweisungen für Zehntausende von Glyphen eine monumentale Aufgabe. Ein solches Unterfangen geht bei den meisten Schriften über den Punkt hinaus, an dem die Renditen sinken .

Newlines [ Bearbeiten ]

Unicode behebt teilweise das Newline- Problem, das beim Versuch auftritt, eine Textdatei auf verschiedenen Plattformen zu lesen. Unicode definiert eine große Anzahl von Zeichen , die konforme Anwendungen als Zeilenabschluss erkennen sollten.

In Bezug auf die neue Linie führte Unicode den U + 2028 LINE SEPARATOR und den U + 2029 PARAGRAPH SEPARATOR ein . Dies war ein Versuch, eine Unicode-Lösung für die semantische Codierung von Absätzen und Zeilen bereitzustellen, die möglicherweise alle verschiedenen Plattformlösungen ersetzt. Auf diese Weise bietet Unicode einen Weg, um die historischen plattformabhängigen Lösungen zu umgehen. Nichtsdestotrotz haben nur wenige Unicode-Lösungen diese Unicode-Zeilen- und Absatztrennzeichen als einzige kanonische Zeilenendzeichen übernommen. Ein gängiger Ansatz zur Lösung dieses Problems ist jedoch die Normalisierung von Zeilenumbrüchen. Dies wird mit dem Cocoa-Textsystem unter Mac OS X sowie mit W3C-XML- und HTML-Empfehlungen erreicht. Bei diesem Ansatz wird jedes mögliche Newline-Zeichen intern in eine gemeinsame Newline konvertiert (was nicht wirklich wichtig ist, da es sich um eine interne Operation nur zum Rendern handelt). Mit anderen Worten, das Textsystem kann das Zeichen korrekt als Zeilenumbruch behandeln.unabhängig von der tatsächlichen Codierung des Eingangs.

Probleme [ bearbeiten ]

Philosophische und Vollständigkeitskritik [ Bearbeiten ]

Die Han-Vereinigung (die Identifizierung von Formen in den ostasiatischen Sprachen, die man als stilistische Variationen desselben historischen Charakters behandeln kann) ist trotz der Anwesenheit einer Mehrheit von Experten aus allen drei Regionen der USA zu einem der umstrittensten Aspekte von Unicode geworden Ideographic Research Group (IRG), die das Konsortium und ISO bei der Erweiterung des Repertoires und bei der Han-Vereinigung berät. [74]

Unicode wurde dafür kritisiert, dass ältere und alternative Formen von Kanji nicht separat codiert wurden, was laut Kritikern die Verarbeitung alter japanischer und ungewöhnlicher japanischer Namen erschwert. Dies ist häufig auf die Tatsache zurückzuführen, dass Unicode eher Zeichen als Glyphen codiert (die visuellen Darstellungen des Grundzeichens, die häufig von einer Sprache zur anderen variieren). Die Vereinheitlichung von Glyphen führt zu der Wahrnehmung, dass die Sprachen selbst, nicht nur die grundlegende Zeichendarstellung, zusammengeführt werden. [75] [ Klarstellung erforderlich ]Es gab mehrere Versuche, alternative Codierungen zu erstellen, die die stilistischen Unterschiede zwischen chinesischen, japanischen und koreanischen Schriftzeichen im Gegensatz zu Unicodes Politik der Han-Vereinigung bewahren. Ein Beispiel hierfür ist TRON (obwohl es in Japan nicht weit verbreitet ist, gibt es einige Benutzer, die mit historischem japanischen Text umgehen und ihn bevorzugen müssen).

Obwohl das Repertoire von weniger als 21.000 Han-Zeichen in der frühesten Version von Unicode weitgehend auf Zeichen beschränkt war, die heutzutage allgemein verwendet werden, umfasst Unicode jetzt mehr als 92.000 Han-Zeichen, und es werden weiterhin Tausende weitere historische und dialektale Zeichen hinzugefügt, die in China verwendet werden. Japan, Korea, Taiwan und Vietnam.

Die moderne Schrifttechnologie bietet ein Mittel, um das praktische Problem der Darstellung eines einheitlichen Han-Zeichens in Form einer Sammlung alternativer Glyphendarstellungen in Form von Unicode-Variationssequenzen anzugehen . Beispielsweise ermöglichen die erweiterten typografischen Tabellen von OpenType die Auswahl einer von mehreren alternativen Glyphenrepräsentationen, wenn der Zeichen-Glyphen-Zuordnungsprozess ausgeführt wird. In diesem Fall können Informationen im Klartext bereitgestellt werden, um anzugeben, welche alternative Zeichenform ausgewählt werden soll.

Verschiedene kyrillische Zeichen mit und ohne Kursivschrift

Wenn sich die Unterschiede in den entsprechenden Glyphen für zwei Zeichen in derselben Schrift nur in Kursivschrift unterscheiden, hat Unicode sie im Allgemeinen vereinheitlicht, wie aus dem Vergleich zwischen russischen (als Standard gekennzeichneten) und serbischen Zeichen rechts hervorgeht, was bedeutet, dass die Unterschiede bestehen Anzeige durch intelligente Schrifttechnologie oder manuelles Ändern von Schriftarten.

Zuordnung zu älteren Zeichensätzen [ Bearbeiten ]

Unicode wurde entwickelt, um eine Code-Punkt-für-Code-Punkt -Roundtrip-Formatkonvertierung zu und von bereits vorhandenen Zeichenkodierungen zu ermöglichen, sodass Textdateien in älteren Zeichensätzen in Unicode konvertiert werden können und dann zurück und dieselbe Datei zurückerhalten können. ohne kontextabhängige Interpretation anzuwenden. Dies hat dazu geführt, dass inkonsistente Legacy-Architekturen wie das Kombinieren von diakritischen Zeichen und vorkomponierten Zeichen in Unicode vorhanden sind und mehr als eine Methode zur Darstellung von Text bieten. Dies ist in den drei verschiedenen Codierungsformen für koreanisches Hangul am ausgeprägtesten. Seit Version 3.0 können vorkompositionierte Zeichen, die durch eine kombinierte Folge bereits vorhandener Zeichen dargestellt werden können, nicht mehr zum Standard hinzugefügt werden, um die Interoperabilität zwischen Software mit verschiedenen Unicode-Versionen zu gewährleisten.

Injective Mappings müssen zwischen Zeichen in vorhandenen Legacy-Zeichensätzen und Zeichen in Unicode bereitgestellt werden, um die Konvertierung in Unicode zu erleichtern und die Interoperabilität mit Legacy-Software zu ermöglichen. Mangelnde Konsistenz bei verschiedenen Zuordnungen zwischen früheren japanischen Codierungen wie Shift-JIS oder EUC-JP und Unicode führte zu Fehlanpassungen bei der Konvertierung des Roundtrip -Formats , insbesondere bei der Zuordnung des Zeichens JIS X 0208 '~' (1-33, WAVE DASH). Wird häufig in älteren Datenbankdaten verwendet, um entweder U + FF5EFULLWIDTH TILDE (in Microsoft Windows ) oder U + 301CWAVE DASH (andere Anbieter) zu verwenden. [76]

Einige japanische Computerprogrammierer haben Einwände gegen Unicode erhoben, da sie die Verwendung von U + 005C \ REVERSE SOLIDUS (Backslash) und U + 00A5 ¥ YEN SIGN , die in JIS X 0201 0x5C zugeordnet waren, trennen müssen und viel Legacy-Code vorhanden ist mit dieser Verwendung. [77] (Diese Codierung ersetzt auch Tilde '~' 0x7E durch Macron '¯', jetzt 0xAF.) Die Trennung dieser Zeichen besteht in ISO 8859-1 von lange vor Unicode.

Indische Skripte [ Bearbeiten ]

Indische Skripte wie Tamil und Devanagari erhalten jeweils nur 128 Codepunkte, die dem ISCII- Standard entsprechen. Das korrekte Rendern von Unicode Indic-Text erfordert die Umwandlung der gespeicherten Zeichen logischer Reihenfolge in visuelle Reihenfolge und die Bildung von Ligaturen (auch als Konjunktionen bezeichnet) aus Komponenten. Einige lokale Wissenschaftler sprachen sich für die Zuweisung von Unicode-Codepunkten zu diesen Ligaturen aus, was gegen die Praxis anderer Schriftsysteme verstößt, obwohl Unicode einige arabische und andere Ligaturen nur aus Gründen der Abwärtskompatibilität enthält. [78] [79] [80]Das Codieren neuer Ligaturen in Unicode erfolgt nicht, zum Teil, weil der Satz von Ligaturen von der Schriftart abhängt und Unicode eine Codierung ist, die von Schriftartenvariationen unabhängig ist. Die gleiche Art von Problem trat 2003 für die tibetische Schrift auf, als die chinesische Normungsbehörde vorschlug, 956 vorkomposierte tibetische Silben zu kodieren [81] , die jedoch vom zuständigen ISO-Ausschuss ( ISO / IEC JTC 1 / SC 2 ) zur Kodierung abgelehnt wurden . [82]

Die Unterstützung des thailändischen Alphabets wurde wegen der Reihenfolge der thailändischen Zeichen kritisiert. Die Vokale เ, แ, โ, ใ, ไ, die links vom vorhergehenden Konsonanten geschrieben sind, befinden sich im Gegensatz zu den Unicode-Darstellungen anderer indischer Skripte in visueller Reihenfolge anstelle der phonetischen Reihenfolge. Diese Komplikation ist darauf zurückzuführen, dass Unicode den thailändischen Industriestandard 620 geerbt hat , der auf die gleiche Weise funktionierte und wie Thai immer auf Tastaturen geschrieben wurde. Dieses Ordnungsproblem verkompliziert den Unicode-Kollatierungsprozess geringfügig und erfordert Tabellensuchen, um thailändische Zeichen für die Kollatierung neu zu ordnen. [75] Selbst wenn Unicode die Codierung in der gesprochenen Reihenfolge übernommen hätte, wäre es immer noch problematisch, Wörter in der Wörterbuchreihenfolge zu sortieren. ZB das Wort แสดง [sa dɛːŋ] "perform" beginnt mit einem Konsonantencluster "สด" (mit einem inhärenten Vokal für den Konsonanten "ส"), der Vokal แ - in gesprochener Reihenfolge würde nach dem ด kommen, aber in einem Wörterbuch ist das Wort zusammengestellt, wie es geschrieben steht, wobei der Vokal dem ส folgt.

Zeichen kombinieren [ bearbeiten ]

Zeichen mit diakritischen Zeichen können im Allgemeinen entweder als einzelnes vorkomposiertes Zeichen oder als zerlegte Folge eines Basisbuchstabens plus eines oder mehrerer nicht beabstandeter Zeichen dargestellt werden. Zum Beispiel sollten ḗ (vorkompositioniertes e mit Makron und akut oben) und ḗ (e gefolgt von der Kombination von Makron oben und Kombination von akut oben) identisch wiedergegeben werden, wobei beide als e mit Makron und akutem Akzent erscheinen, in der Praxis jedoch ihre Das Erscheinungsbild kann variieren, je nachdem, welche Rendering-Engine und welche Schriftarten zum Anzeigen der Zeichen verwendet werden. In ähnlicher Weise werden Unterpunkte , wie sie bei der Romanisierung von Indic erforderlich sind , häufig falsch platziert. [ Zitat benötigt ]. Unicode-Zeichen, die vorkomponierten Glyphen zugeordnet sind, können in vielen Fällen verwendet werden, um das Problem zu vermeiden. Wenn jedoch kein vorkomponiertes Zeichen codiert wurde, kann das Problem häufig mithilfe einer speziellen Unicode-Schriftart wie Charis SIL gelöst werden , die Graphite , OpenType oder verwendet AAT- Technologien für erweiterte Rendering-Funktionen.

Anomalien [ bearbeiten ]

Der Unicode-Standard hat Regeln auferlegt, die Stabilität gewährleisten sollen. [83] Abhängig von der Strenge einer Regel kann eine Änderung verboten oder erlaubt werden. Beispielsweise kann und wird sich ein "Name", der einem Codepunkt gegeben wird, nicht ändern. Eine "Skript" -Eigenschaft ist jedoch nach Unicodes eigenen Regeln flexibler. In Version 2.0 hat Unicode viele Codepunkt- "Namen" gegenüber Version 1 geändert. Gleichzeitig gab Unicode an, dass sich ein einem Codepunkt zugewiesener Name von nun an nie mehr ändern würde. Dies bedeutet, dass bei der Veröffentlichung von Fehlern diese Fehler nicht korrigiert werden können, auch wenn sie trivial sind (wie dies in einem Fall mit der Schreibweise BRAKCET für BRACKET geschehen istin einem Charakternamen). Im Jahr 2006 wurde erstmals eine Liste mit Anomalien bei den Charakternamen veröffentlicht. Ab April 2017 gab es 94 Zeichen mit identifizierten Problemen, [84] zum Beispiel:

  • U + 2118 SCRIPT CAPITAL P : Dies ist ein kleiner Buchstabe. Die Hauptstadt ist U + 1D4AB 𝒫 MATHEMATICAL SCRIPT CAPITAL P [85]
  • U + 034F ͏ KOMBINIEREN VON GRAFIKVERBINDERN : Verbindet keine Grapheme. [84]
  • U + A015 YI SYLLABLE WU : Dies ist keine Yi-Silbe, sondern ein Yi-Iterationszeichen.
  • U + FE18 PRÄSENTATIONSFORMULAR FÜR VERTIKALEN RECHTEN WEISSEN LENTIKULAREN BREMSBAND : Die Halterung ist falsch geschrieben. [86]

Rechtschreibfehler werden mithilfe von Unicode-Aliasnamen und Abkürzungen behoben .

Siehe auch [ Bearbeiten ]

  • Vergleich von Unicode-Codierungen
  • Religiöse und politische Symbole in Unicode
  • Internationale Komponenten für Unicode (ICU), jetzt als ICU- TC Teil von Unicode
  • Liste der Binärcodes
  • Liste der Unicode-Zeichen
  • Liste der Verweise auf XML- und HTML-Zeichenentitäten
  • Open-Source-Unicode-Schriften
  • Standards in Bezug auf Unicode
  • Unicode-Symbole
  • Universeller codierter Zeichensatz
  • Lotus Multi-Byte Character Set (LMBCS), eine parallele Entwicklung mit ähnlichen Absichten

Notizen [ Bearbeiten ]

  1. ^ Das Unicode-Konsortium verwendet den mehrdeutigen Begriff Byte . Die Internationale Organisation für Normung (ISO), die Internationale Elektrotechnische Kommission (IEC) und die Internet Engineering Task Force (IETF) verwenden den spezifischeren Begriff Oktett in aktuellen Dokumenten zu Unicode.

Referenzen [ bearbeiten ]

  1. ^ "Der Unicode-Standard: Eine technische Einführung" . Abgerufen am 16.03.2010 .
  2. ^ "Nutzungsübersicht der nach Rangfolge aufgeschlüsselten Zeichenkodierungen" . w3techs.com . Abgerufen am 09.06.2020 .
  3. ^ "Konformität" (PDF) . Der Unicode-Standard . März 2020 . Abgerufen am 15.03.2020 .
  4. ^ "UAX # 29: Unicode-Textsegmentierung §3 Graphemclustergrenzen" . unicode.org . 2020-02-19 . Abgerufen am 27.06.2020 .
  5. ^ "Unicode - eine kurze Einführung (fortgeschritten) • JavaScript für ungeduldige Programmierer" . exploringjs.com . Abgerufen am 14.06.2020 .
  6. ^ "Einführung in Unicode" . mathias.gaunard.com . Abgerufen am 14.06.2020 .
  7. ^ "Zeichenfolgen und Zeichen - Die schnelle Programmiersprache (Swift 5.2)" . docs.swift.org . Abgerufen am 14.06.2020 .
  8. ^ "Unsere Latin-1-Annahmen brechen - auf der Suche nach Faulheit" . manishearth.github.io . Abgerufen am 14.06.2020 . Unicode wollte nicht jedes Mal neue Flaggen hinzufügen, wenn ein neues Land oder Gebiet auftaucht. Sie wollten auch nicht in die heikle Angelegenheit einsteigen, herauszufinden, was ein Land ist , zum Beispiel im Umgang mit umstrittenen Gebieten. [..] Auf einigen chinesischen Systemen wird beispielsweise die Flagge für Taiwan (🇹🇼) möglicherweise nicht gerendert.
  9. ^ "Hören wir auf, Codepunkten eine Bedeutung zuzuweisen - auf der Suche nach Faulheit" . manishearth.github.io . Abgerufen am 14.06.2020 . Leute beginnen zu implizieren, dass Codepunkte etwas bedeuten und dass das Indizieren oder Schneiden von O (1) an Codepunktgrenzen eine nützliche Operation ist.
  10. ^ a b c d e Becker, Joseph D. (1998-09-10) [1988-08-29]. "Unicode 88" (PDF) . unicode.org (Nachdruck zum 10-jährigen Jubiläum). Unicode-Konsortium . Archiviert (PDF) vom Original am 25.11.2016 . Abgerufen am 25.10.2016 . 1978 machte Bob Belleville im Xerox PARC den ersten Vorschlag für eine Reihe von "Universal Signs" . Viele Personen haben Ideen zur Entwicklung eines neuen Codierungsdesigns beigetragen. Ab 1980 entwickelten sich diese Bemühungen zum Xerox Character Code Standard (XCCS) des vorliegenden Autors, eine mehrsprachige Codierung, die von Xerox seit 1982 als interner Unternehmensstandard durch die Bemühungen von Ed Smura, Ron Pellar und anderen beibehalten wird.
    Unicode entstand als Ergebnis von acht Jahren Berufserfahrung mit XCCS. Die grundlegenden Unterschiede zu XCCS wurden von Peter Fenwick und Dave Opstad (reine 16-Bit-Codes) sowie von Lee Collins (Vereinigung der ideografischen Zeichen) vorgeschlagen. Unicode behält die vielen Funktionen von XCCS bei, deren Nützlichkeit sich im Laufe der Jahre in einer internationalen Linie mehrsprachiger Kommunikationssystemprodukte bewährt hat.
  11. ^ "Zusammenfassung Erzählung" . Abgerufen am 15.03.2010 .
  12. ^ Verlauf der Unicode-Veröffentlichungs- und Veröffentlichungsdaten auf unicode.org. Abgerufen am 28. Februar 2017.
  13. ^ Searle, Stephen J. "Unicode Revisited" . Abgerufen am 18.01.2013 .
  14. ^ a b "Die Mitglieder des Unicode-Konsortiums" . Abgerufen am 04.01.2019 .
  15. ^ "Character Code Charts" . Abgerufen am 17.03.2010 .
  16. ^ "Unicode FAQ" . Abgerufen am 02.04.2020 .
  17. ^ "Roadmap zum BMP" . Unicode-Konsortium . Abgerufen am 30.07.2018 .
  18. ^ "Über die Script Encoding Initiative" . Das Unicode-Konsortium . Abgerufen am 04.06.2012 .
  19. ^ "Unicode 6.1 Taschenbuch verfügbar" . ansagen_at_unicode.org . Abgerufen am 30.05.2012 .
  20. ^ "Unicode 14.0.0" . www.unicode.org . Abgerufen 2021-02-10 .
  21. ^ "Aufgezählte Versionen des Unicode-Standards" . Abgerufen am 21.06.2016 .
  22. ^ a b c
    • "Unicode Version 1.0" . 1991.
    • "1.0.0 / UnicodeData.txt (rekonstruiert)" . 2004 . Abgerufen am 16.03.2010 .
  23. ^ a b "Unicode-Daten 1.0.1" . Abgerufen am 16.03.2010 .
  24. ^ a b
    • "Unicode Version 1.1" .
    • "Unicode Data 1995" . Abgerufen am 16.03.2010 .
  25. ^ a b
    • "Unicode Version 2.0.0" .
    • "Unicode Data-2.0.14" . Abgerufen am 16.03.2010 .
  26. ^ a b
    • "Unicode Version 2.1.0" .
    • "Unicode Data-2.1.2" . Abgerufen am 16.03.2010 .
  27. ^ "Unicode Data-3.0.0" . Abgerufen am 16.03.2010 .
  28. ^ "Unicode Data-3.1.0" . Abgerufen am 16.03.2010 .
  29. ^ "Unicode Data-3.2.0" . Abgerufen am 16.03.2010 .
  30. ^ "Unicode Data-4.0.0" . Abgerufen am 16.03.2010 .
  31. ^ "Unicode Data-4.1.0" . Abgerufen am 16.03.2010 .
  32. ^ "Unicode Data 5.0.0" . Abgerufen am 17.03.2010 .
  33. ^ "Unicode-Daten 5.1.0" . Abgerufen am 17.03.2010 .
  34. ^ "Unicode-Daten 5.2.0" . Abgerufen am 17.03.2010 .
  35. ^ "Unicode Data 6.0.0" . Abgerufen am 11.10.2010 .
  36. ^ "Unicode-Daten 6.1.0" . Abgerufen am 31.01.2012 .
  37. ^ "Unicode-Daten 6.2.0" . Abgerufen am 26.09.2012 .
  38. ^ "Unicode-Daten 6.3.0" . Abgerufen am 30.09.2013 .
  39. ^ "Unicode Data 7.0.0" . Abgerufen am 15.06.2014 .
  40. ^ "Unicode 8.0.0" . Unicode-Konsortium . Abgerufen am 17.06.2015 .
  41. ^ "Unicode Data 8.0.0" . Abgerufen am 17.06.2015 .
  42. ^ "Unicode 9.0.0" . Unicode-Konsortium . Abgerufen am 21.06.2016 .
  43. ^ "Unicode Data 9.0.0" . Abgerufen am 21.06.2016 .
  44. ^ Lobao, Martim (07.06.2016). "Dies sind die beiden Emoji, die nicht für Unicode 9 zugelassen waren, die Google aber trotzdem zu Android hinzugefügt hat" . Android Polizei . Abgerufen am 04.09.2016 .
  45. ^ "Unicode 10.0.0" . Unicode-Konsortium . Abgerufen am 20.06.2017 .
  46. ^ "Der Unicode-Standard, Version 11.0.0, Anhang C" (PDF) . Unicode-Konsortium . Abgerufen am 11.06.2018 .
  47. ^ "Ankündigung des Unicode-Standards, Version 11.0" . blog.unicode.org . Abgerufen am 06.06.2018 .
  48. ^ "Der Unicode-Standard, Version 12.0.0, Anhang C" (PDF) . Unicode-Konsortium . Abgerufen am 05.03.2019 .
  49. ^ "Ankündigung des Unicode-Standards, Version 12.0" . blog.unicode.org . Abgerufen am 05.03.2019 .
  50. ^ "Unicode Version 12.1 zur Unterstützung der Reiwa-Ära veröffentlicht" . blog.unicode.org . Abgerufen am 07.05.2019 .
  51. ^ a b
    • "Unicode 13.0.0" .
    • "Ankündigung des Unicode-Standards, Version 13.0" . blog.unicode.org . Abgerufen am 11.03.2020 .
  52. ^ "Der Unicode-Standard, Version 13.0 - Kernspezifikation Anhang C" (PDF) . Unicode-Konsortium . Abgerufen am 11.03.2020 .
  53. ^ "Glossar der Unicode-Begriffe" . Abgerufen am 16.03.2010 .
  54. ^ "3.4 Zeichen und Kodierung". Der Unicode-Standard, Version 13.0 (PDF) . 2019. p. 19.
  55. ^ "2.4 Codepunkte und Zeichen". Die Unicode-Standardversion 12.0 - Kernspezifikation (PDF) . 2019. p. 29.
  56. ^ "Anhang A: Notationskonventionen" (PDF) . Der Unicode-Standard . Unicode-Konsortium. März 2020. In Übereinstimmung mit dem Aufzählungspunkt in Bezug auf Unicode in MOS: ALLCAPS werden die formalen Unicode-Namen in diesem Absatz nicht verwendet.
  57. ^ a b "Stabilitätsrichtlinie für die Unicode-Zeichenkodierung" . Abgerufen am 16.03.2010 .
  58. ^ "Eigenschaften" (PDF) . Abgerufen am 15.03.2020 .
  59. ^ "Unicode-Zeichenkodierungsmodell" . Abgerufen am 16.03.2010 .
  60. ^ "Unicode Named Sequences" . Abgerufen am 16.03.2010 .
  61. ^ "Unicode Name Aliases" . Abgerufen am 16.03.2010 .
  62. ^ CWA 13873: 2000 - Mehrsprachige europäische Teilmengen in ISO / IEC 10646-1 CEN Workshop Agreement 13873
  63. ^ Begründung des mehrsprachigen europäischen Zeichensatzes 2 (MES-2) , Markus Kuhn , 1998
  64. ^ "UTF-8, UTF-16, UTF-32 & Stückliste" . Unicode.org FAQ . Abgerufen am 12.12.2016 .
  65. ^ Der Unicode-Standard, Version 6.2 . Das Unicode-Konsortium. 2013. p. 561. ISBN 978-1-936213-08-5.
  66. ^ Pike, Rob (2003-04-30). "UTF-8-Geschichte" .
  67. ^ "ISO / IEC JTC1 / SC 18 / WG 9 N" (PDF) . Abgerufen am 04.06.2012 .
  68. ^ Hedley, Jonathan (2009). "Unicode-Suche" .
  69. ^ Milde, Benjamin (2011). "Unicode-Zeichenerkennung" .
  70. ^ Holz, Alan. "Einrichten von Windows Internet Explorer 5, 5.5 und 6 für mehrsprachige und Unicode-Unterstützung" . Alan Wood . Abgerufen am 04.06.2012 .
  71. ^ "Extensible Markup Language (XML) 1.1 (Zweite Ausgabe)" . Abgerufen am 01.11.2013 .
  72. ^ Bigelow, Charles; Holmes, Kris (September 1993). "Das Design einer Unicode-Schriftart" (PDF) . Elektronisches Publizieren . VOL. 6 (3), 289–305: 292. |volume= has extra text (help)
  73. ^ "Schriftarten und Tastaturen" . Unicode-Konsortium. 28.06.2017 . Abgerufen am 13.10.2019 .
  74. ^ Eine kurze Geschichte der Zeichencodes , Steven J. Searle, ursprünglich 1999 geschrieben, zuletzt aktualisiert 2004
  75. ^ a b Das geheime Leben von Unicode: Ein Blick auf Unicodes weichen Unterbauch , Suzanne Topping, 1. Mai 2001 (Internet Archive)
  76. ^ AFII-Beitrag zu WAVE DASH , "Eine herstellerspezifische Unicode-Zeichentabelle für Japanisch" . web.archive.org . 2011-04-22. Archiviert vom Original am 22.04.2011.
  77. ^ ISO 646- * Problem , Abschnitt 4.4.3.5 der Einführung in I18n , Tomohiro KUBOTA, 2001
  78. ^ "Arabische Präsentationsformulare-A" (PDF) . Abgerufen am 20.03.2010 .
  79. ^ "Arabische Präsentationsformulare-B" (PDF) . Abgerufen am 20.03.2010 .
  80. ^ "Alphabetische Präsentationsformulare" (PDF) . Abgerufen am 20.03.2010 .
  81. ^ China (2002-12-02). "Vorschlag zur Kodierung tibetischer BrdaRten-Zeichen für ISO / IEC 10646 in BMP" (PDF) .
  82. ^ VS Umamaheswaran (2003-11-07). "Beschlüsse der Sitzung 2 der Arbeitsgruppe 2" (PDF) . Beschluss M44.20.
  83. ^ Unicode-Stabilitätsrichtlinie
  84. ^ a b "Unicode Technical Note # 27: Bekannte Anomalien in Unicode-Zeichennamen" . unicode.org . 2017-04-10.
  85. ^ Unicode-Diagramm: "Tatsächlich hat dies trotz seines Namens die Form eines kalligraphischen p in Kleinbuchstaben."
  86. ^ "Die falsche Schreibweise von BRACKET im Charakternamen ist ein bekannter Fehler."

Weiterführende Literatur [ Bearbeiten ]

  • The Unicode Standard, Version 3.0 , The Unicode Consortium, Addison-Wesley Longman, Inc., April 2000. ISBN 0-201-61633-5 
  • The Unicode Standard, Version 4.0 , The Unicode Consortium, Addison-Wesley Professional, 27. August 2003. ISBN 0-321-18578-1 
  • The Unicode Standard, Version 5.0, 5. Auflage , The Unicode Consortium , Addison-Wesley Professional, 27. Oktober 2006. ISBN 0-321-48091-0 
  • Julie D. Allen. The Unicode Standard, Version 6.0 , The Unicode Consortium , Mountain View, 2011, ISBN 9781936213016 , ( [1] ). 
  • Das vollständige Handbuch der Typografie , James Felici, Adobe Press; 1. Auflage, 2002. ISBN 0-321-12730-7 
  • Unicode: A Primer , Tony Graham, M & T-Bücher, 2000. ISBN 0-7645-4625-2 . 
  • Unicode entmystifiziert: Ein praktischer Programmierleitfaden zum Codierungsstandard , Richard Gillam, Addison-Wesley Professional; 1. Auflage, 2002. ISBN 0-201-70052-2 
  • Unicode erklärt , Jukka K. Korpela, O'Reilly; 1. Auflage, 2006. ISBN 0-596-10121-X 
  • Yannis Haralambous; Martin Dürst (2019). "Unicode aus sprachlicher Sicht". In Haralambous, Yannis (Hrsg.). Verfahren der Graphemik im 21. Jahrhundert, Brest 2018 . Brest: Fluxus Editions. S. 167–183. ISBN 978-2-9570549-1-6.

Externe Links [ Bearbeiten ]

  • Offizielle Website · Offizielle technische Website  
  • Unicode bei Curlie
  • Alan Woods Unicode-Ressourcen  - enthält Listen von Textverarbeitungsprogrammen mit Unicode-Funktion; Schriftarten und Zeichen werden nach Typ gruppiert. Zeichen werden in Listen und nicht in Gittern dargestellt.
  • Unicode-BMP-Fallback-Schriftart  - Zeigt den Unicode-Wert eines beliebigen Zeichens in einem Dokument, einschließlich des Bereichs für den privaten Gebrauch, anstelle des Glyphen selbst an.