Textverarbeitung Text Processing

Home , AkelPad, Bob Bemer, CDC display code, Cork encoding, DIN 66003, DIN 66303

Dipl. Math. F. Braun Universität Regensburg Rechenzentrum https://homepages.uni- regensburg.de/~brf09510/EDV/kurs_info/brf09510/kurs_info/textproc/textproc.html https://homepages.uni- regensburg.de/~brf09510/EDV/kurs_info/brf09510/kurs_info/textproc/textproc.pdf svn/doku/trunk/textproc/textproc.tex 9. Dezember 2019

KAPITEL 1

Zeichensätze, Zeichencodes und encodings

1. Webseiten über den Unicode

One Code to rule them all, One Code to nd them, One Code to bring them in, and in the darkness bind them

Bemerkung: Tengwar, die Elbenschrift, in der dieser böse Spruch geschrieben wurde, hat im Unicode die Code- points U+016080 bis U+0160FF. http://www.unicode.org/roadmaps/smp/ Das Tengwar-Projekt scheint jedoch seit 1997 zu ruhen. Der Unicode Standard 12.1.0: https://www.unicode.org/versions/Unicode12.1.0/ http://www.unicode.org/versions/Unicode12.0.0/UnicodeStandard-12.0.pdf und seine jüngeren und älteren Brüder: http://www.unicode.org/versions/ Joel Spolsky: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Un- icode and Character Sets (No Excuses!), 2003 http://www.joelonsoftware.com/articles/Unicode.html

Dr. Florian Deiÿenböck: No Such Thing As Plain Text, 2015 https://www.cqse.eu/en/blog/no-such-thing-as-plain-text/

QbProg: Do you really want me to write code like that?! Unicode and your application, Sunday, November 11, 2012 http://cppwhispers.blogspot.de/2012/11/unicode-and-your-application-1-of-n.html

ICU hat ein Tag bei stackoverow: http://stackoverflow.com/questions/tagged/icu

2. Geschichte

Robert Bemer: https://www.thocp.net/biographies/bemer_bob.htm

Robert Bemer: Survey of coded character representation https://dl.acm.org/citation.cfm?id=367493 Full text as PDF

Bob Bemer: HOW ASCII GOT ITS BACKSLASH

3 4 1. ZEICHENSÄTZE, ZEICHENCODES UND ENCODINGS

1960 Ascii, ASA, American Standards Association, X3.2 1986 ANSI X3.4-1986, ISO/IEC 646:1991, ECMA-6 1987,1998-2003 ISO 8859 zu spät und zu wenig! ISO/IEC 8859-1:1998, ISO/IEC 8859-2:1999 ISO/IEC 8859-3:1999, ISO/IEC 8859-4:1998, ISO/IEC 8859-5:1999, ISO/IEC 8859-6:1999, ISO/IEC 8859-7:2003, ISO/IEC 8859-8:1999, ISO/IEC 8859-9:1999, ISO/IEC 8859-10:1998, ISO/IEC 8859-11:2001, ISO/IEC 8859-12 eingestellt, ISO/IEC 8859-13:1998, ISO/IEC 8859-14:1998, ISO/IEC 8859-15:1999, ISO/IEC 8859-16:2001 1991 Unicode 1.0.0 1992 Unicode 1.0.1 1993 Unicode 1.1.0, ISO/IEC 10646:1993 1995 Unicode 1.1.5 1996 Unicode 2.1.0, ISO/IEC 10646-1:1993+Amendment 5/7 1998 Unicode 2.1.2 1998 Unicode 2.1.5 1998 Unicode 2.1.8 1999 Unicode 2.1.9 1999 Unicode 3.0.0, ISO/IEC 10646-1:2000 2000 Unicode 3.0.1 2001 Unicode 3.1.0, ISO/IEC 10646-1/2:2001 2001 Unicode 3.1.1 2002 Unicode 3.2.0, ISO/IEC 10646-1/2:2001+Amendment 1 2003 Unicode 4.0.0, ISO/IEC 10646:2003 2004 Unicode 4.0.1 2005 Unicode 4.1.0 2006 Unicode 5.0.0 2008 Unicode 5.1.0 2009 Unicode 5.2.0 2010 Unicode 6.0.0, ISO/IEC 10646:2011 2012 Unicode 6.1.0, ISO/IEC 10646:2012 2012 Unicode 6.2.0 2013 Unicode 6.3.0 2014 Unicode 7.0.0 2015 Unicode 8.0.0, ISO/IEC 10646:2014 2016 Unicode 9.0.0, ISO/IEC 10646:2015, 4. ed. 2017 Unicode 10.0.0, ISO/IEC 10646:2017; Bitcoin, CJK 2018 Unicode 11.0.0, ISO/IEC 10646:2017; Copyleft, Chinese chess 2019 Unicode 12.0.0, ISO/IEC 10646:2017. 5. ed.; small hiragana and katagana, tamil, lao, hieroglyphs

Der Unicode enthält heute als 21-Bit-Code etwas über 2 Millionen Zahlen. Sie werden nicht alle als Codepoints (s.u.) verwendet: in Gebrauch sind lediglich etwas über 1 Million Codepoints mit Nummern zwischen 0 und 10FFFF. Sie werden in 17 Ebenen gegliedert; die base plane enthält die 65536 (sehr häugen) Codepoints von 0 bis FFFF. Weitere Zeichen verteilen sich auf die 16 weiteren supplementary planes. Bisher wurden davon nur 5 Ebenen (1, 2, 14, 15, 16) deniert; 11 davon (3-13) sind für künftigen Erweiterungen noch frei. Die Ebenen sind nicht lückenlos mit Schriftzeichen gefüllt und enthalten nicht ausschlieÿlich Schriftzeichen. In den ersten drei Ebenen sind daher in Version 10 (2017) von den hier theoretisch möglichen 196608 Schriftzeichen (3 · 216) 136690 Zeichen in 139 Schriftsystemen verfügbar.

3. Begrie http://www.joelonsoftware.com/articles/Unicode.html Joel Spolsky: The Absolute Minimum Every Soft- ware Developer Absolutely, Positively Must Know About Unicode and Character Sets, 2003 http://www.gymel.com/charsets/ Zeichentabellen, 2001 http://czyborra.com/charsets/ Czyborra: charsets, 1998 http://userguide.icu-project.org/unicode ICU, _die_ Unicode Library http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=IWS-Chapter03 Peter Constable, Cha- racter set encoding basics, 2001-06-13 3. BEGRIFFE 5 http://www.goland.org/unicode_c_windows/ Unicode, Windows and C++, 2012 Ein Zeichensatz (character set oder character repertoire) ist eine exakt festgelegte Menge S verschiedener Schriftzeichen. Hier sind noch keine Zeichennummern im Spiel. Der Unicode-Zeichensatz als Beispiel ist wirklich sehr umfangreich. Kleiner sind die Menge der 26 lateinischen Buchstaben, das kyrillische oder griechische Alphabet und DIN 66003 bez. DIN 66303. Ein Zeichencode (ccs, coded character set) ist ein Zeichensatz S mit einer bijektiven (injektiv und surjektiv) Abbildung zwischen den Schriftzeichen des Zeichensatzes und einer Codemenge M (Byte, endliche Teilmenge der ganzen Zahlen . . . ). Die Menge M heiÿt auch codespace oder codepage mit dem dizilen Unterschied, daÿ der codespace eher die Codemenge M und die codepage die Zeichenmenge S beschreibt. Im Unicode besteht M aus einer Teilmenge der ganzen Zahlen 0 - 2097151 = 221 − 1, die in maximal 21 Bit gespeichert werden können. Für weniger mit mathematischer Sprache Vertraute ist der Zeichencode einfach eine willkürliche Durchnum- merierung der in Zeichensatz festgelegten Schriftzeichen, d.h. jedes Schriftzeichen bekommt eine eindeutige Nummer aus der Codemenge M. Die Nummerierung ist nicht zwingend lückenlos. Ein codepoint oder encoded character ist ein Element der Codemenge M, das ein Schriftzeichen aus S bezeichnet. Man kann also das Schriftzeichen oder seinen codepoint angeben. Ein Beispiel ist das Eurozeichen e mit der Nummer 8364 im Unicode. Für Neulinge zusätzlich erschwerend ist, dass die Nummer meist im Sedezimalsystem angegeben wird, beim Eurozeichen also 20AC1. Für Uniccode-Codepoints hat sich die Notation U+20AC mit genau vier Sedezimalziern eingebürgert. In HTML haben Sie vielleicht schon die sedezimale und die dezimale Schreibweise € und € gesehen. In vielen Programmiersprachen benutzt man die Notation \uxxxx. Texte werden durch die Codepoints ihrer Schriftzeichen dargestellt. Ein Text besteht also aus einer Folge von Codepoints aus einem Zeichencode. Wenn Ihr neuer Rechner 719,16e gekostet hat und dieser Preis im Unicode gespeichert wird, besteht er aus den Codepoints 55 49 57 44 49 54 8364 oder im Sedezimalsystem 37 31 39 2C 31 36 20AC. Notationen dieser Folge sind dann U+0037 U+0031 U+0039 U+002C U+0031 U+0036 U+20AC oder auch \u0037 \u0031 \u0039 \u002C \u0031 \u0036 \u20AC. In einfachen Fällen können die Codepoints wie im Beispiel direkt aneinandergereiht werden. Werden sie als Text angegeben, müssen sie durch ein Zeichen getrennt werden. Im Beispiel wurde das Leerzeichen verwendet. Im Rechnerspeicher benutzt man Bytes mit Werten zwischen 0 und 255 für ASCII-Texte (UCS-1), Doppelbytes mit Werten zwischen 0 und 65535 (UCS-2) oder Vierbytegruppen mit Werten zwischen 0 0 und 4294967295 (UCS- 4) für Unicodetexte. Zusätzlich muss bei Bytegruppen mit mehr als einem Byte die sog. endianess festgelegt werden. Als UCS-2-Text müssen im Beispiel die zu kurzen Zahlen mit Nullen auf 2 Byte aufgefüllt werden: 0037 0031 0039 002C 0031 0036 20AC. Wenn man dieses Beispiel in Einzelbytes auöst erhält man 00 37 00 31 00 39 00 2C 00 31 00 36 20 AC in der bigendian-Darstellung und 37 00 31 00 39 00 2C 00 31 00 36 00 AC 20 in der littleendian-Darstellung. Dieser Parameter wird von der verwendeten Hardware bestimmt; Intel und ARM speichern littleendian, Risc-Cpus (Sparc, Power, Mips), 68000, Alpha oder MMIX speichern bigendian. Die genaue Festlegung, wie Codepoints abgespeichert werden, wird encoding genannt. Heute wird UCS selten verwendet, da die encodings UCS-1, UCS-2, UCS-4 mit der endianess als Zusatzangabe als veraltet gelten. Die Verfahren, Codepoints mit mehr als 8 Bit zu speichern, sind also deutlich komplexer geworden. Das encoding ist die Festlegung des konkret verwendeten Ablageverfahrens. Die encoding form (gute deutsche Übersetzung nicht bekannt, cef, character encoding form, oft nur kurz encoding genannt) deniert, in wie groÿe Bytegruppen ein Codepoint gespeichert wird und wie Codepoints, die die denierte Bytegruppe überschreiten, gespeichert werden können. Im UTF-8 werden Einzelbytes verwendet, UTF-16 speichert Codepoints in ein oder zwei 16-Bit-Variablen und UTF-32 kann alle heutigen Codepoints in einer 32-Bit-Variablen speichern. Die Variablen heiÿen auch code units. Weil der Begri so wichtig ist: Eine code unit ist eine Speichereinheit für einen ganzen Codepoint oder, falls die code unit zu klein ist, für einen Codepoint-Teil. Dann besteht der Codepoint aus mehreren code units. Das encoding scheme (gute deutsche Übersetzung nicht bekannt, ces, character encoding scheme, oft nur kurz endianess genannt) deniert die Ablage der Variablen als Bytes im Speicher. In einfachen Fällen wird nur die Reihenfolge festgelegt (big-endian oder little-endian), jedoch sind auch platzsparende schemes deniert (SCSU, BOCU, Puniycode). Komplexe Schemes können zwischen mehreren Varianten wechseln (ISO/IEC

1Das Sedezimalsystem, auch Hexadezimalsystem benutzt die ersten sechs Buchstaben A, B, C, D, E und F als Ziern mit den Werten A=10, B=11, C=12, D=13, E=14 und F=15. Die Basis des Zahlensystems ist 16, also gilt 20AC = 2 · 163 + 0 · 162 + A · 161 + C · 160 = 2 · 4096 + 0 · 256 + A · 16 + C = 2 · 4096 + 0 · 256 + 10 · 16 + 12 = 8192 + 0 + 160 + 12 = 8364 6 1. ZEICHENSÄTZE, ZEICHENCODES UND ENCODINGS

2022). Einfache Schemes werden manchmal am Anfang eines Textes als BOM (byte order mark) angezeigt (0xEF,0xBB,0xBF bei UTF-8 nicht empfohlen, 0xFF, 0xFE bei little-endian, 0xFE, 0xFF bei big-endian). Manchmal werden cef und ces zusammengefaÿt, wie bei IANA mit den Bezeichnungen UTF-16BE und UTF- 16LE. Dann sind BOMs verboten. Die Byte-Reihenfolge-Markierung (byte order mark, BOM) dient in gespeicherten Unicode-Texten zur automatischen Erkennung des verwendeten encoding-schemes. Als BOM wird der Codepoint U+FEFF verwendet, der auch als zero width no-break space gilt. Verdeutscht ist das ein Zeichen, das als Leerraum (space) ohne Breite (zero-width) gilt und den umgebenden Text nicht unterbricht (no-break). Noch kürzer ist das ein Zeichen fast ohne jede Wirkung auf die Textdarstellung. Es sollte nur am Anfang eines Unicode-Textes vorkommen und dient zur automatischen Erkennung des encodings, genauer des ces. Ein BOM im Text sollte nicht zur ces-Erkennung, sondern immer als zero width no-break space verarbeitet werden. BOMs in PHP-Dateien ziehen Ärger an. Win- dows Notepad speichert ungefragt BOMs. Notepad++ tut das erfreulicherweise nicht. Viele Compiler hassen BOMS. Ein Glyph ist aktuelle Darstellung eines einzelnen Schriftzeichens.

Beispiel: Das chinesische Schriftzeichen für Berg, shan, (falls Sie das Bild nicht sehen, es sieht so ähnlich wie |_|_| oder ein lateinisches W aus) hat im Unicode den Codepoint U+5C71 = 山. Mit UTF-16 als cef wird es als eine code unit abgelegt. Mit ces bigendian steht 5C, 71 im Speicher, mit littleendian 71, 5C. Mit UTF-8 (nicht empfohlen) stehen die drei units E5, B1, B1 im Speicher. Ein Glyph ist . Beispiele: ASCII, Unicode, UTF-8, big-endian ASCII, ISO-8859, Unicode Diverse alte 6 - 12 Bit. UTF-1, UTF-5, UTF-6, UTF-7 Probleme: Microsoft Codepages CP 850, 852, 1252, 1250 Tschechisch: Kamenicky, PC Latin 2, ISO Latin 2, KOI-8 CS2, cp1250 (MS Windows CS and EE), Macintosh CE, Cork. http://luki.sdf-eu.org/txt/cs-encodings-faq.html Chinesisch: Unicode, GB2312-80, GBK, Big 5, CNS, GB-18030 Japanisch: JIS, New JIS, Old JIS, Shift-JIS, NEC JIS, EUC, UNICODE, UTF-7, UTF-8,

4. ASCII, ISO-8859, Unicode

In den Beispielen sind wichtige Kodierungen schon erwähnt worden. Welche sollte man denn nun verwenden? Veraltete Kodierungen sind nur im historischen Zusammenhang oder in alten Dateien von Bedeutung. Das gilt für die vielen maschinenspezischen Kodierungen, wie den CDC display code mit 6 Bit. Und natürlich speziell für den historischen ECDIC Code von IBM. Die vielen paarweise inkompatiblen OEM codes, die als Abwandlungen von ASCII für die ersten IBM-PCs entstanden sind, sind im selben Sinn als historisch zu betrachten. Leider irrlichtern diese historischen Kodierungen in Form unzähliger Codepages durch viele Dateien, Editoren und Webseiten (CP 1252, CP 437, CP 850 . . . ). Solche Kodierungen waren auch in Sprachen mit nichtlateinischer Schrift entstanden (Big5, JIS, KS). Die verbleibenden Kodierungen kann man in zwei Gruppen, die mit maximal 8 Bit (1 Byte) und die mit mehr als 8 Bit unterteilen. Zur 8-Bit-Gruppe gehören der 7-Bit ASCII code und seine genormten Varianten ISO-8859. Hier kann man englische Texte oder Texte aus einer sehr begrenzten Sprachengruppe byteweise speichern und bequem in den entsprechenden Datentypen verarbeiten (char, CHARACTER). Insbesondere muÿ man dem encoding keine Beachtung widmen. Alle anderen Bedürfnisse erfüllt heute eigentlich ausschlieÿlich der Unicode. Er erlaubt die einheitliche Darstel- lung eines Textes mit beliebigen Sprachkombinationen, dessen korrekte Darstellung überall gewährleistet ist, auch wenn sie manchmal nicht trivial ist. 5. UTF-8 7

Sein einziges Problem ist das encoding, das leider wie man sagen muss heute in einer OEM-ähnlichen verwirrenden Vielfalt möglich ist. Sowohl in der Sprache Java, als auch im Betriebssystem DOS/Windows von Microsoft wurde zunächst ein heute nicht mehr haltbares UCS-2 verwendet, bei dem alle Zeichen in 16 Bit gespeichert werden. Dateinamen beim Erönen von Microsoft-Dateien werden bis heute nur in diesem UCS-2 zugelassen. UCS-2 ist obsolet und mittlerweile durch UTF-16 ersetzt. UCS-4 ist auf der sicheren Seite, da wirklich alle Zeichen gespeichert werden können, verschwendet jedoch viel Speicher in rein oder vorwiegend englischen Texten2. Da es keine Unterschiede zu UTF-32 gibt, wird die Bezeichnung UCS-4 als obsolete betrachtet. So lag der Weg zu den komprimierenden encodings nahe: Unter Verzicht auf eine einheitliche Zeichenlänge kann man eine eziente Darstellung englischer und lateinischer Texte erreichen, ohne auf chinesisch oder klingonisch verzichten zu müssen. Der Kompromiss heiÿt UTF-8 und UTF-16 und wäre akzeptabel, wenn es nicht noch UTF-1, UTF-4, UTF-5, UTF-7, SCSU oder BOCU gäbe. UTF-32 ist bis auf weiteres identisch mit UCS-4 solange niemand das 4294967296-ste Zeichen im Unicode deniert; fast hätte ich Unocide geschrieben! Gute Übersichten zum Unicode: http://userguide.icu-project.org/strings/unicodeset http://www.unicode.org/faq/basic_q.html http://blog.aegisub.org/2008/10/unicode-utf-8-utf-16-ucs-2-in-nutshell.html

5. UTF-8

UTF-8 geht auf Thompson und Pike 1992 zurück. Es wurde in den RFCs 2044 (1996), 2279 (1998) und 3629 (2003) standardisiert. UTF-8 speichert Unicode-Codepoints in n-Byte-Gruppen mit n ∈ {1, 2, 3, 4}. Die Codeunits sind genau 1 Byte lang. Wie lange eine Bytegruppe ist (wieviele Codeunits sie enthält), wird durch festgelegte Bits sehr systematisch markiert. Zur richtigen Interpretation von UTF-8 muss man also Bits inspizieren. In der folgenden Darstellung wird ein x für ein Codepoint-Bit verwendet. 0xxx xxxx 1 Byte mit 7 Bit für Codepoints 0 - 127 110x xxxx 10xx xxxx 2 Byte mit 11 Bit für Codepoints 128 - 2047 1110 xxxx 10xx xxxx 10xx xxxx 3 Byte mit 16 Bit für Codepoints 2048 - 65535 1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx 4 Byte mit 21 Bit für Codepoints 65536 - 2097151

Die Systematik ist leicht zu erkennen: Die Einserbits am Anfang einer Bytegruppe markieren die Anzahl n der Bytes, alle Folgebytes einer Gruppe beginnen mit 10. Sollte der Unicode noch wachsen, kann UTF-8 problemlos auf n = 5 und mehr Bytes erweitert werden. Eine BOM U+FEFF mit 16 Bit wird in einer 3-Byte-Gruppe gespeichert. Die 16 Bits 1111 1110 1111 1111 werden auf die x verteilt. Zum Verständnis sind zunächst die x-Gruppen eingeklammert, in der zweiten Darstellung werden nur noch die Bytegrenzen berücksichtigt: 1110 (1111) 10 (1110 11) 10 (11 1111) 1110 1111 1011 1011 1011 1111 EF BB BF

RFC 3629 und Unicode empehlt allerdings, die BOM in UTF-8 nicht zu speichern, eine möglicherweise frag- würdige Festlegung. In der Praxis wird die BOM auch in UTF-8 meistens problemlos verarbeitet. Allerdings können UTF-8 Dateien, die nur strenges ASCII enthalten, mit einer BOM nicht mehr von Programmen gelesen werden, die nur ASCII verstehen; die BOM selbst ist kein ASCII mehr, nur noch illegales UTF-8. Diese Frage ist umstritten, wie die Diskussion bei stackoverow zeigt: http://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom UTF-8 hat den einzigen Nachteil, aus der Byteanzahl nicht die Textlänge berechnen zu können; man muss den gesamten Text Zeichen für Zeichen verarbeiten und die Zeichen einzeln zählen.

2gemeint ist nicht die Sprache sondern das verwendete Alphabet. Deutsch wird vorwiegend mit englischen Buchstaben geschrieben, die sieben Ausnahmen Ä Ö Ü ä ö ü ÿ sind relativ selten und verschwenden ebenfalls Speicher 8 1. ZEICHENSÄTZE, ZEICHENCODES UND ENCODINGS

Ansonsten hat UTF-8 nur Vorteile: 1. Alle Unicodenummern haben ein eindeutiges encoding. 2. Englische Texte und viele andere lateinisch geschriebene Texte verwenden meistens ein Byte pro Schriftzei- chen. 3. Reines ASCII-Text kann als UTF-8 gelesen werden. 4. In UTF-8 benötigt man keine endianess-Angabe3. 5. UTF-8 ist ein reiner Byte-Strom. 6. UTF-8-Texte können von links nach rechts und von rechts nach links verarbeitet werden. Von rechts nach links überspringt man zunächst die markierten Folgebytes bis zum ersten Byte einer Bytegruppe, um dann den ganzen Codepoint zu verarbeiten. 7. UTF-8 kann in C und C++ in den herkömmlichen char-Variablen gespeichert und verarbeitet werden. 8. Auch die Nullterminierung in C bleibt durchführbar. 9. Sortieren von Strings streng lexikalisch nach Unicode- nummern (z.B. mit UTF-32) führt zum selben Sortierergebnis wie byteweises Sortieren mit UTF-8-Strings. 10. Wenn ein Text in UTF-8 vorliegt und eine Textstelle nicht korrekt gespeichert wurde (z.B. 110xxxxx 110xxxxx, also kein Folgebyte), ist nur eine lokale Textstelle korrumpiert und nicht der gesamte Text. Man sucht vorwärts oder rückwärts das folgende Zeichen und verarbeitet den Text einfach weiter.

Wer sucht, ndet natürlich trotzdem Nachteile: Es kann als diskriminierend betrachtet werden, dass englische Texte nur ein Byte pro Zeichen belegen, andere Sprachen jedoch mindestens zwei, chinesisch, japanisch und koreanisch (CJK) sogar drei Byte pro Zeichen. Das verdoppelt den benötigten Speicherplatz in kyrillischen, hebräischen und arabischen Texten gegenüber einer direkten Speicherung; in CJK ist dieser Faktor 1, 5. Hier ist UTF-16 gerechter, auch englisch braucht zwei Byte pro Zeichen. Aber was soll`s - englisch ist halt eine imperiale Sprache.

6. UTF-16

UTF-16-Texte speichern alle Codepoints zwischen 0 und 65535 in einem Doppelbyte. Man bezeichnet diese Codepointgruppe als base plane oder plane 0. Das sind praktisch alle Zeichen aus denen vernünftigerweise ein normaler Text besteht und schlieÿt alle lebenden Sprachen ein (englisch, deutsch, russisch, chinesisch, japanisch uvam.) Texte mit anderen Codepoints sind sehr selten und andere Codepoints sind in solchen Texten ebenfalls selten. Die hoentlich sehr wenigen Codepoints, die nicht in der base plane liegen, werden in Doppel-Doppelbytes gespeichert, also in Vier-Bytegruppen. Dazu dienen die sog. surrogate pairs, das sind Codepoints, denen direkt kein Schriftzeichen zugeordnet wurde: U+D800 - U+DBFF (high) und U+DC00 - U+DFFE (low). High und low surrogate pairs müssen immer in dieser Reihenfolge stehen, ein low surrogate pair darf niemals einzeln oder vor einem high surrogate pair stehen. Alle Unicode-Codepoints aus der base plane zwischen 0 und 65535 werden in einem Doppelbyte gespeichert. Der Unicode ist so gestaltet, dass kein surrogate pair vorkommen kann. xxxx xxxx xxxx xxxx Bei allen anderen Codepoints zwischen 65536 und 2097151 wird ihr Bitmuster in zwei Teile uuuuu und xxxxxxxxxxxxxxxx mit fünf und 16 Bits zerlegt. Die erste Gruppe uuuuu hat einen Wert ≥ 1 (sonst wäre der Codepoint in der base plane!) Wenn man statt uuuuu nur wwww = uuuuu−1 betrachtet, kann man ein Bit einsparen. Die beiden Werte wwww und xxxxxxxxxxxxxxxx werden auf die freien Bits zweier aufeinanderfolgender surrogate pairs D800 = 1101 8000 0000 0000 (high) und DC00 = 1101 1100 0000 0000 (low) verteilt. Es gilt also: uuuuuxxxxxxxxxxxxxxxx = 1101 10 wwww xxxxxx 1101 11xxxxxxxxxx (logische Gliederung) = 1101 10ww wwxx xxxx 1101 11xx xxxx xxxx (big endian Byte Gliederung) UTF-16 hat zwei Nachteile: Aus der Bytezahl kann die Zeichenzahl nicht berechnet werden. UTF-16-Texte können als bigendian und als littleendian-Dateien gespeichert werden. In C und C++ ist ein weiterer Nachteil, dass zwei Datentypen zur Verfügung stehen: wchar_t und char16_t. wchar_t muss keinen Unicode speichern (tut dies aber mit Microsoft-C) und ist nicht portabel (MS-C: 16 Bit, UTF-16; gcc: 32 Bit, UCS-4). char16_t wurde erst 2011 eingeführt und wird nur von aktuellen Compilern verstanden (gcc -std=c11). Vorteile sind natürlich die Möglichkeit, den gesamten Unicode zu speichern und vor allem die weite Verbreitung. UTF-16 ist das Verarbeitungsformat von Java, JavaScript und ICU. ICU ist älter als C11 und deniert deshalb

3deshalb ist die BOM eigentlich verboten; sie soll nur die endianess, also ces festlegen und nicht das eigentliche encoding, also die cef! Entgegen der Spezikation wird die BOM oft benutzt, um auch UTF-8-Texte selbst zu kennzeichnen 6. UTF-16 9 einen eigenen Datentyp UChar (statt char16_t oder wchar_t). Die interne Stringverarbeitung erfolgt in UTF- 16-Strings mit UChar-code units.

KAPITEL 2

Problemgruppen

Eingabe, Verarbeitung, Ausgabe Languages : keyboard-Einstellungen; was ist char, wchar_t, string; was steht drin; Konversionen; Rendern und Glyphen

KAPITEL 3

Natürliche Sprachen und Unicode

1. International Phonetic Alphabet (IPA)

Mit dem IPA kann jede Sprache phonetisch eindeutig geschrieben werden. Im Unicode ist der Bereich U+0250 bis U+02AF für IPA-Zeichen reserviert. Für die Eingabe stehen Programme und Webseiten (z.B. http://ipa.typeit.org/) zur Verfügung. Der Unicode enthält auch Bereiche für weitere phonetische Schriften (Bopomofo, Katagana, Nikudot, Phonetic extensions. . . ).

2. Chinesisch, Japanisch und Koreanisch

Alle drei Sprachen (CJK) benutzen chinesische Schriftzeichen. Diese lassen sich nicht wie Latein mit einem pho- netischen System sortieren, sondern haben eigene Sortierprinzipien (Radikale und Strichzahlen). Um Unicode- Codepoints zu nden gibt es die folgenden Webseiten: https://en.wikipedia.org/wiki/CJK_Strokes_(Unicode_block) http://unicode.org/charts/unihan.html http://unicode.org/charts/unihanrsindex.html http://unicode.org/charts/unihangridindex.html

3. Hebräisch

Ein Codeblock für Hebräisch, Jidisch und Ladino. Kursivschrift und Satzschrift durch Fonts (wie bei Latein!). Nikudot vorhanden.

KAPITEL 4

Programmiersprachen

C, C++, Java, Javascript, Perl, PHP, Die meisten Sprachen legen sich auf ein internes encoding für jede Stringverarbeitung fest. Ausnahmen sind hier C und C++, wo diese Festlegung durch den Programmierer erfolgt und von Programm zu Programm oder sogar innerhalb eines Programms wechseln kann.

1. C gcc version 4.7.1 20120723 -std=c11/c1x/iso9899:2011 Raw strings: R"(bla)" R"delim(bla)delim" RL"bla" Ru8"bla" Ru"bla" RU"bla" Infos: http://www.evanjones.ca/unicode-in-c.html char : ASCII (UCS-1), UTF-8, 'A', "ABC", u8"e", u8"\u20ac\U0001d120" wchar_t : wint_t = char : int, L'A', L"e", L"\u20ac\U0001d120" char16_t : UTF-16, UCS-2 u'A', u"e", u"\u20ac\U0001d120" char32_t : UTF-32, UCS-4 U'A', U"e", U"\u20ac\U0001d120" http://www.gnu.org/software/libc/manual/html_node/Extended-Char-Intro.html // wcharint.c

#include #include int main (void) { wint_t ch; // wchar_t || WEOF wchar_t s [100]; int i; i = 0; for (;;) { ch = getwc(stdin); // wchar_t || WEOF if (ch == WEOF) break; // WEOF: loop ends s [i++] = ch; // store character if (i >= 100) break; // string exhaustet: loop ends } if (i >= 100) i = 99; s [i] = 0; // store terminating zero

wprintf (L"%ls (%d)", s, wcslen (s)); for (i = 0; i < wcslen (s); i++) wprintf (L" %lc/%d", s [i], s [i]);

return 0; }

15 16 4. PROGRAMMIERSPRACHEN

2. C++ gcc version 4.7.1 20120723 -std=c++11 http://stackoverflow.com/questions/3010739/how-to-use-unicode-in-c

// loc.cpp #include int main() { setlocale(LC_ALL, ""); std::cout << "What's your name? "; std::string name; std::getline(std::cin, name); std::cout << "Hello there, " << name << "." << std::endl; return 0; }

3. Java

4. JavaScript

JavaScript benutzt einheitlich für die interne Stringspeicherung UTF-16. Die .length Property speichert die Anzahl der Codeunits und nicht die Anzahl der Unicodezeichen. Wer die Anzahl der Unicodezeichen benötigt, muss das selbst programmieren am besten mit einem regular expression: var surrPairs = /[\uD800-\uDBFF][\uDC00-\uDFFF]/g; // RE catching one surrogate pair function countCodepoints(s) { // s should be string return string. // dot must be here to prevent js to return unmodied string replace(surrPairs, '#'). // replace surrogate pair by some other character length; // and count the resulting characters }

5. HTML, CSS

HTML und CSS sind sehr einfach, da der Unicode von Anfang an vorgesehen war. Die Codierung und das encoding wird mit zwei Zeilen in HTML möglichst früh im @charset "utf-8"; in CSS am Dateianfang angegeben. Weitere Informationen: http://www.w3.org/International/tutorials/tutorial-char-enc/Overview.en.php Handling character encodings in HTML and CSS (tutorial) http://www.w3.org/International/questions/qa-css-charset.en.php Declaring character encodings in CSS

Die Byte Order Mark (BOM) sollte in HTML eigentlich gar keine Rolle spielen, da alle TCP-Daten denitions- gemäÿ als Big-endian-Daten übertragen werden. http://www.w3.org/International/questions/qa-byte-order-mark.en.php The byte-order mark (BOM) in HTML 7. MYSQL 17

6. XML

7. mySQL

KAPITEL 5

Libraries

1. The International Components for Unicode: ICU

1.1. Allgemeines. Hervorragende Library; ICU (C, C++, Java) ICU verwendet als Verarbeitungsformat wie Java und JavaScript UTF-16. ICU ist älter als C11 und C++14 und deniert deshalb einen eigenen Datentyp UChar (statt char16_t oder wchar_t). Die interne Stringverarbeitung erfolgt in UTF-16-Strings mit UChar-code units. http://site.icu-project.org/home http://www-01.ibm.com/software/globalization/icu/index.html http://site.icu-project.org/download - Download http://icu-project.org/apiref/icu4c/ Documentation of functions http://userguide.icu-project.org/ User Guide

1.2. Installation. SuSE: Yast2 libicu-devel Debian: apt-get libicu-dev Cygwin: Dateien holen: icu4c-51_1-data.zip icu4c-51_1-docs.zip icu4c-51_1-src.tgz icu4c-51_1-src.zip Auspacken: icu4c-51_1-src.tar Verzeichnis: icu. Anleitung: http://www.icu-project.org/repos/icu/icu/tags/release-51-1/readme.html cd icu/source runConfigureICU make

1.3. Beispiele. Beispiel: http://userguide.icu-project.org/collation/examples Ist fehlerhaft mit C++. Geht mit Modikationenn in C: gcc -I ./source/common/ -I ./source/i18n/ test1.c -L ./source/lib/ -licudata -licui18n -licuio -licule -liculx -licutu -licuuc -L - ./source/extra/uconv/uconvmsg/ -luconvmsg Zum Start muss der Pfad auf die dlls gesetzt werden: export PATH=/home/brf09510/icu/icu/source/lib/:$PATH ./a.exe

1 /∗ t e s t 1 . c rrzvm034: gcc test1.c −l i c u d a t a −l i c u i 1 8 n −l i c u i o −l i c u l e −l i c u l x −l i c u t u −l i c u u c

3 pc58685: gcc test1.c −l i c u d a t a −l i c u i 1 8 n −l i c u i o −l i c u l e −l i c u l x −l i c u t u −l i c u u c pc58685:~/svn/doku/trunk/textproc/icu> ./a.out

5 ∗/

7 #include

9 #include #include

11 #include "unicode/ustring.h"

19 20 5. LIBRARIES

#include "unicode/utypes.h"

13 #include "unicode/uloc.h" #include "unicode/ucol.h"

15 #d e f i n e MAXBUFFERSIZE 100 #d e f i n e BIGBUFFERSIZE 5000

17 UBool collateWithLocaleInC( const char∗ locale , UErrorCode ∗ s t a t u s ) {

19 UChar dispName [MAXBUFFERSIZE ] ; int32_t bufferLen = 0;

21 UChar source [MAXBUFFERSIZE ] ; UChar t a r g e t [MAXBUFFERSIZE ] ;

23 UCollationResult result = UCOL_EQUAL; uint8_t sourceKeyArray [MAXBUFFERSIZE ] ;

25 uint8_t targetKeyArray [MAXBUFFERSIZE ] ; int32_t sourceKeyOut = 0 ,

27 targetKeyOut = 0; UCollator ∗ myCollator = 0;

29 i f (U_FAILURE(∗ s t a t u s ) ) {

31 return FALSE; }

33 u_uastrcpy(source , "This is a test ."); u_uastrcpy(target , "THIS IS A TEST.");

35 myCollator = ucol_open(locale , status); i f (U_FAILURE(∗ s t a t u s ) ) {

37 bufferLen = uloc_getDisplayName(locale , 0, dispName, MAXBUFFERSIZE, status ); /∗ Report the error with display name... ∗/

39 fprintf(stderr , "Failed to create the collator for : \"%s\"\n", dispName);

41 return FALSE; }

43 result = ucol_strcoll(myCollator, source , u_strlen(source), target , u_strlen(target)); /∗ result is 1, secondary differences only for ignorable space characters ∗/

45 i f ( r e s u l t != UCOL_LESS) {

47 fprintf(stderr , "Comparing two strings with only secondary differences in C failed .\n");

49 return FALSE; }

51 /∗ To compare them with just primary differences ∗/ ucol_setStrength (myCollator , UCOL_PRIMARY);

53 result = ucol_strcoll(myCollator, source , u_strlen(source), target , u_strlen(target)); /∗ r e s u l t i s 0 ∗/

55 i f (result != 0) {

57 fprintf(stderr , "Comparing two strings with no differences in C failed .\n");

59 return FALSE; }

61 /∗ Now, do the same comparison with keys ∗/

63 sourceKeyOut = ucol_getSortKey(myCollator , source , −1, sourceKeyArray , MAXBUFFERSIZE) ; targetKeyOut = ucol_getSortKey(myCollator , target , −1, targetKeyArray , MAXBUFFERSIZE) ;

65 r e s u l t = 0 ; 1. THE INTERNATIONAL COMPONENTS FOR UNICODE: ICU 21

result = strcmp(sourceKeyArray , targetKeyArray);

67 i f (result != 0) {

69 fprintf(stderr , "Comparing two strings with sort keys in C failed .\n");

71 return FALSE; }

73 ucol_close(myCollator); return TRUE;

75 }

77 int main ( void ) {

79 UErrorCode s t a t u s = U_ZERO_ERROR; fprintf(stdout , "\n");

81 s t a t u s = U_ZERO_ERROR; fprintf(stdout , "\n");

83 i f (collateWithLocaleInC("en_US", &status) != TRUE) {

85 fprintf(stderr , "%s: Collate with locale in C failed .\n");

87 } else {

89 fprintf(stdout , "Collate with Locale C example worked!!\n"); }

91 return 0 ; }

545 gcc −I ./source/common/ −I ./source/i18n/ test1.c −L ./source/lib/ −l i c u d a t a −l i c u i 1 8 n −l i c u i o −l i c u l e −l i c u l x −l i c u t u −l i c u u c −L ./source/extra/uconv/uconvmsg/ −luconvmsg

2 549 echo $PATH 550 find . | grep "\.dll"

4 551 export PATH=/home/brf09510/icu/icu/source/lib /:$PATH 552 echo $PATH

6 553 . / a . exe

1.4. Regular expressions.

1.5. Das ICU API. http://icu-project.org/apiref/icu4c/

1.6. Details. 1.6.1. Allgemeines. Anwendungen: Pattern matching, Suchen und Ersetzen in Strings. Komfortable String- bearbeitung. 1.6.2. Denition. Wie in allen Sprachen, die über regular expressions verfügen, müssen regular expressions in ICU in Variablen erzeugt und kompiliert werden. Die ICU spricht hier vom Erönen eines regular expressions. Die Variable ist opak und ein Zeiger auf ein URegularExpression. URegularExpression * p = uregex_open (const UChar *pattern, int32_t patternLength, uint32_t flags, UParseError *pe, UErrorCode *status) uregex_openUText (UText *pattern, uint32_t flags, UParseError *pe, UErrorCode *status) uregex_openC (const char *pattern, uint32_t flags, UParseError *pe, UErrorCode *status)

Wird der Reg 22 5. LIBRARIES

1.6.3. Verwendung. Properties und Methoden aus String und RegExp. var s = new String ("3 Chinesen mit dem Kontrabass"); var p = /[aeiou]/ig var r = "au"; p.test (s) Kommt Muster p in String s vor? (true) p.exec (s) Wende Muster p auf String s mit Objekt als Ergebnis an; Mehrfachaufruf möglich ([ 'i', index: 4, input: '3 Chinesen mit dem Kontrabass' ]) do { r = p.exec(s); console.log(r); } while (r !== null); [ 'i', index: 4, input: '3 Chinesen mit dem Kontrabass' ] [ 'e', index: 6, input: '3 Chinesen mit dem Kontrabass' ] [ 'e', index: 8, input: '3 Chinesen mit dem Kontrabass' ] [ 'i', index: 12, input: '3 Chinesen mit dem Kontrabass' ] [ 'e', index: 16, input: '3 Chinesen mit dem Kontrabass' ] [ 'o', index: 20, input: '3 Chinesen mit dem Kontrabass' ] [ 'a', index: 24, input: '3 Chinesen mit dem Kontrabass' ] [ 'a', index: 26, input: '3 Chinesen mit dem Kontrabass' ] null p.toString() Wandle Muster in String zurück s.search (p) liefert Position von Muster p in String s (4) s.replace (p, r) ersetzt Muster p in String s durch String r '3 Chaunausaun maut daum Kauntraubauss' s.match (p) liefert alle Treer von Muster p in String s [ 'i', 'e', 'e', 'i', 'e', 'o', 'a', 'a' ] s.split (p, l) liefert Array mit Strings aus s geteilt bei p mit max l Elementen [ '3 Ch', 'n', 's', 'n m', 't d', 'm K', 'ntr', 'b', 'ss' ]

1.6.4. Flags. Bei Konstruktoraufrufen sind die drei möglichen Flags ein zusätzliches Stringargument, bei direkter Schreibweise werden sie an den schlieÿenden Schrägstrich angehängt. g: globale Suche (nicht nur der erste Treer) i: case-insensitive Suche m: mehrzeilige Suche (Die Perlmodikationen ceosx fehlen) 1.6.5. Zeichen und Zeichenklassen. Fast alle Zeichen (Unicode!) stehen für sich selbst. Zeichen, die dies nicht tun (^$\.*+?()[]{}|), werden mit \ markiert. Hallo sucht freundliche Zurufe \^ sucht Zirkumex \. sucht Punkte

Eckige Klammern denieren Zeichenklassen und ihre Komplemente. [aeiou] sucht englische Vokale [abc] sucht die ersten drei Buchstaben [^abc] sucht alles andere [a-fA-F] sucht Sedezimalziern [-^] sucht Minuszeichen und Zirkumex 1. THE INTERNATIONAL COMPONENTS FOR UNICODE: ICU 23

Merke: − als Bindestrich steht immer als erstes. ^ als Zirkumex steht nie als erstes. Bei allen anderen Zeichen ist die Reihenfolge ohne Bedeutung

Für wichtige Zeichenklassen gibt es Abkürzungen. Groÿbuchstaben stehen jeweils für die Komplemente. . alles auÿer Zeilenende \w ASCII-Buchstabe wie in Programmiersprachen ([a-zA-Z0-9_]) \W \s Leerraum inclusive BOM,USP1(\n\r\u2028\u2029\t\v\f \u00A0\uFEFF) \S \d ASCII-Zier ([0-9_]) \D

Spezielle Positionen im String werden durch die Symbole ^$ bezeichnet. ^ Stringanfang oder Zeilenanfang $ Stringende oder Zeilenende

1.6.6. Wiederholung. Greedy (gierig) x Wiederholungen. Greedy heiÿt, der gefundene Bereich ist maximal. ? x = 0, 1 + x ≥ 1 * x ≥ 0 {n} x = n {n,} x ≥ n {n,m} n ≤ x ≤ m

Non-greedy: der gefundene Bereich ist minimal Fragezeichen hinter Wiederholungszeichen ?? 0, 1 +? ≥ 1 *? ≥ 0 {n}? n-mal {n,}? ≥ n {n,m}? n ≤ x ≤ m

Vorsicht: var s = "Drei Chinesen" var pg = /[aeiou]+/ig greedy var pn = /[aeiou]+?/ig non-greedy s.match(pg) ndet ei s.match(pn) ndet e und i getrennt

1.6.7. Alternativen. | trennt Alternativen Alternativen werden von links nach rechts ausgewertet. Also wirkt a|ab anders als ab|a Im ersten Fall ist schon a im String "ab" ein Treer. Regel: Vom speziellen zum Allgemeinen 1.6.8. Gruppen. Mit () werden Gruppen gebildet, die als einheitliche Produktionen betrachtet werden. Diese Gruppen dienen zusätzlich zur Bildung von Teilmustern. Bei Treern können die Teilmuster getrennt verwertet werden. \i (i > 0) verweist auf den Teiltreer der Gruppe Nummer i im Muster. Die Numerierung beginnt bei 1! Teilmusterbildung wird mit (?: ) abgeschaltet.

1Byte order mark, Unicode space separator, ES 7.2, 7.3 24 5. LIBRARIES

Gruppen ohne Speicherung von Teilmustern werden mit (?: ) gespeichert. var p = /([aeiou]+).*\1/ig; Vokalgruppe, die sich wiederholen muss "einerlei".match(p) Treer: zweimal ei "Drei Chinesen".match(p) kein Treer: erste Vokalgruppe ei wiederholt sich nicht

1.6.9. RegExp-Member. p.source Quell-String des RegExp p.global g-ag p.ignoreCase i-ag p.multiline -m-ag p.lastIndex Stringposition, wo die nächste Suche beginnen muss p.exec(s) Suche mit Array-Resultat p.test(s) Suche mit boolean-Resultat

1.6.10. String-Member. s.search(p) s.replace(p,r) s.match(p) s.split (p)Der String wird in ein Array von Substrings an den Mustergrenzen zerlegt

/body/ags Assertion | Atom | Atom Faktor Atom Bedeutung W Unicode auÿerˆ$\. ∗ +?()[] { } | . Unicode auÿer neuer Zeile Flag Property Bedeutung \0 \u0000 g global nach Treer weiter \n n > 0 nte gespeicherte Gruppe i ignoreCase \f\n\r\t\v m multiline ˆ$ Zeilen- statt Stringbezogen \cL SteuerzeichenˆL \xxx Codepoint xx16 \uxxxx Codepoint xxxx16 \ˆ\$ . . . \| verbotene Unicodes \ < ZW J > Unicode zero width joiner \ < ZW NJ > Unicode zero width non joiner W \d\s\w Zier/Leerraum/Wort Assertion Bedeutung \D\S\W keine Zier/Leerraum/Wort String- oder Zeilenanfang Menge Zeichenmenge aeiou ˆ [ ] [ ] $ String- oder Zeilenende Bereich Zeichenbereich A−Z [ ] [ ] \b Wortgrenze vor Position Komplementmenge aeiou [ˆ] [ˆ ] \B Nicht-Wortgrenze vor Position [−ˆ] Menge aus − undˆ A(?=group ) matches A only when followed by group (Gruppe ) zu speichernde Gruppe A(?!group ) matches A only when not followed by group (?:Gruppe ) Gruppe ohne Speicherung

/ Variable Programm Bedeutung U \ r.exec(s) 1 Treer Gruppe 1 1 [ ] Faktor non-greedy Bedeutung \ r.exec(s) 2 Treer Gruppe 2 2 [ ] ∗ ∗ ? ≤ ∞ ... 0 x < ? ≤ ∞ \ r.exec(s) 13 Treer Gruppe 13 + + 1 x < 13 [ ] ? ?? ≤ ≤ ... 0 x 1 {n} {n}? x = n {n,} {n,}? n ≤ x < ∞ {n,m} {n,m}? n ≤ x ≤ m

1.6.11. Übersicht.

2. ConvertUTF - Unicode KAPITEL 6

Regular expressions

Weil sie so wichtig sind, seien die wichtigsten Systeme mit Regex-Befähigung und mit oder ohne Unicode- Unterstützung hier aufgeführt: Regular expressions (1951), Stephen Cole Kleene, regular languages, regular sets. lex, ex, jex und yacc, bison, byacc, cup im Compilerbau (1970) Posix Portable Operating System Interface (1988) enthält eine (nicht-Unicode) regular expression library. Java ICU XML .NET framework Perl ab 5.6 PCRE (Perl compatible regular expressions) PHP Ruby ab 1.9 XRegExp (open source JavaScript library) JavaScript. RegexBuddy ab 2.0.0 PowerGREP EditPad Pro

1. unichars, uniprops und uninames

KAPITEL 7

Tools - Werkzeuge

1. unichars, uniprops und uninames

Nützliche Perl-Skripts: Wieviele Buchstaben in der base-plane? unichars '\p{Alphabetic}' | wc -l Wieviele Buchstaben in allen planes? unichars -a '\p{Alphabetic}' | wc -l Wieviele Buchstaben und Hanzeichen in allen planes? unichars -ua '\p{Alphabetic}' | wc -l siehe Perl Unicook.

2. iconv iconv --list

3. native2ascii native2ascii http://wap-pool.math.uni-bayreuth.de/prog/java_native2ascii.html Konvertierung von beliebigen Textdateien mit landes- und plattformspezischen Zeichensätzen in den Unicode- Zeichensatz und umgekehrt

4. Editoren

Auswahlkriterium: Editoren, die UTF-8 und ISO-8859 beherrschen, auf allen Betriebssystemen laufen, die nicht proprietär und deren Code quelloen (opensource) ist: AkelPad Aquamacs Bluesh CrimsonEditor gedit Geany Gnu-Emacs Gobby JED jEdit MinEd Notepad++ Notepad2 TextEdit Vim XEmacs BlueFish, Notepad++, gedit Windows Editor/Wordpad kann UTF-8 (3 Bytes am Anfang!) beim zweiten Önen sind viele cz Zeichen weg!!! joe kanns theoretisch auch, aber ich krieg die Tastatur nicht eingestellt Bluesh kann es unter Windows dafür kann der nicht drucken! Brauchbare Editoren mit Unicode: Jedit: läÿt kein Wünsche oen Bluesh (nur UTF-8; kein Druckbefehl)

5. Tastaturen

Fremdsprachige Tastatureinstellung direktes Schreiben von Unicode-Nummern Shift/Cntrl/u hexcode

Inhalt

Inhaltsverzeichnis

Kapitel 1. Zeichensätze, Zeichencodes und encodings 3 1. Webseiten über den Unicode 3 2. Geschichte 3 3. Begrie 4 4. ASCII, ISO-8859, Unicode 6 5. UTF-8 7 6. UTF-16 8 Kapitel 2. Problemgruppen 11 Kapitel 3. Natürliche Sprachen und Unicode 13 1. International Phonetic Alphabet (IPA) 13 2. Chinesisch, Japanisch und Koreanisch 13 3. Hebräisch 13 Kapitel 4. Programmiersprachen 15 1. C 15 2. C++ 16 3. Java 16 4. JavaScript 16 5. HTML, CSS 16 6. XML 17 7. mySQL 17

Kapitel 5. Libraries 19 1. The International Components for Unicode: ICU 19 2. ConvertUTF - Unicode 24 Kapitel 6. Regular expressions 25 1. unichars, uniprops und uninames 25

Kapitel 7. Tools - Werkzeuge 27 1. unichars, uniprops und uninames 27 2. iconv 27 3. native2ascii 27 4. Editoren 27 5. Tastaturen 27

Inhalt 29

31 32 INHALTSVERZEICHNIS

TTH-Seite: http://hutchinson.belmont.ma.us/tth/