Open Source im professionellen Einsatz
Linux-Magazin 05/2013
© Fotograf, 123RF.com

© Fotograf, 123RF.com

Der Weg zu Unicode am Beispiel von Datenbanken

Zeichen des Wandels

Moderne Linux-Distributionen benutzen in Zeiten der Globalisierung Unicode, meist in der Ausprägung UTF-8. Vor dieser Ära entstandene ISO-Textdateien lassen sich noch relativ einfach konvertieren. Eine ganze Datenbank ins Heute zu bringen, erfordert Fingerspitzengefühl.

850

Ob die große Verbreitung von Unicode auf Linux- und anderen Systemen Fluch oder Segen ist, darf dahingestellt bleiben – die Realität ist nun mal wie sie ist. Für den Admin heißt es, seine Daten den Gegebenheiten anzupassen. Glück hat, wer das Stück für Stück tun kann. Für alle anderen bedeutet eine Migration Stress, wenn sie beim Umzug von einem alten Produktivsystem auf ein neues unvermittelt feststellen, dass beispielsweise Umlaute kaputt sind.

Datei-Inhalte konvertieren

Das Problem: Beim Weiterarbeiten schreibt das neue System frisch erzeugte und geänderte Daten mit UTF-8. Nach kurzer Zeit sammelt sich so ein Mischmasch aus Latin und Unicode an, welchen automatisch zu reparieren unmöglich erscheint. Wer in eine solche Zwickmühle gerät, sollte erwägen, schnell auf das alte System zurückzukehren und einen Versuch erst wieder zu wagen, wenn er einen Migrationsplan ausgearbeitet hat. Zur Einstimmung ein paar Fingerübungen: Relevant für die Zeichenkodierung in Linux ist die Variable »LC_CTYPE« ., fuer ISO-8859-15-Systeme etwa:

LANG=de_AT@euro
LC_CTYPE="de_AT@euro"

Auf einem UTF-8-System hingegen materialisiert sich etwas wie

LANG=de_AT.utf8
LC_CTYPE="de_AT@utf8"

Der erste Teil des Wertes »de« gibt die Sprache an und verwendet Codes, die der ISO-639-1-Standard festlegt [1]. Der folgende Abschnitt gibt nach ISO-3166-1 das Land an, im Beispiel »AT« für Österreich [2].

Der dritte Teil definiert die Zeichenkodierung, hier »@euro« für die europäische Erweiterung von ISO-8859-15 oder »@utf8« für die häufigste Kodierung von Unicode ([3],[4]). Die Kodierung nach UTF-8 sorgt dafür, ein Unicode-Zeichen in einer Folge von 1 bis zu 4 Bytes abzubilden (Abbildung 1). Andere Kodierungen bilden die Zeichen aus Unicode in einer anderen Weise ab, beispielsweise UTF-16 immer in Paaren von 2 Bytes.

Abbildung 1: Durch die Kodierungsregeln von UTF-8 sind bestimmte Bytes nicht zulässig. Die Tabelle fasst die 256 Möglichkeiten zusammen. Bytes in roten Zeilen sind unzulässig, grün beschreibt zulässige Bytes, welche unmittelbar ein Zeichen darstellen. In blau sind jene Werte hinterlegt, die eine Sequenz von 2 oder mehr Byte starten und sich als Sequenz mit den Bytes aus orange hinterlegten Zeilen fortsetzen. (Quelle: Wikipedia)

Um die Korrektheit der Dateinamen kümmern sich aktuelle Linux-Distributionen normalerweise selbst. Wer beispielsweise von einem externen Datenträger oder übers Netz Dateien, die aus einem Latin8-basierten Betriebssystem stammen, ins neue System kopiert, braucht nichts weiter tun. Bei den Datei-Inhalten trifft das jedoch nicht zu.

Mit dem »file« -Kommando kann sich jeder Anwender eine Liste von Kandidaten zusammenstellen (siehe Listing 1), die er umzuwandeln hat. Es empfiehlt sich, mit einem Texteditor zu überprüfen, ob alle vorgeschlagenen Kandidaten zu Recht auf der Liste stehen. Auch hier bietet sich zur Sicherheit ein Backup an. Die Kommandos »iconv« und »recode« können Dateien zwischen vielen gängigen Kodierungen hin und her konvertieren. Eine Liste der verfügbaren Kodierungen zeigen »iconv -l« und »recode -l« an. Im folgenden Beispiel, das auf die mit Listing 1 erkundeten Daten zurückgreift, bezeichnet »latin9« die ISO-Kodierung inklusive Euro-Zeichen, »utf8« ist die Schreibweise für die Zielkodierung:

xargs -l1 recode latin9..utf8 < kandidaten

Wer mutig ist, lässt durch diesen Aufruf alle Kandidaten zugleich umwandeln.

Listing 1

Ascii-Dateien suchen

01 #!/bin/sh
02
03 if [ -z $1 ]
04 then
05     startdir=$HOME
06 else
07     startdir=$1
08 fi
09
10 find . -exec file {} ; | grep 'ISO-8859 text$' | sed 's/: ISO-8859 text$//' > kandidaten

Datenbank-Applikation umschreiben

Die Inhalte der vermutlich meisten im deutschsprachigen Raum betriebenen Datenbanken liegen in ISO 8859-15 kodiert vor. Ob man eigene auf Unicode umstellt, hängt ganz sicher von der Middleware und/oder der Applikation ab, welche auf die Datenbank zugreifen. Neue Datengräber, so viel lässt sich pauschal empfehlen, sollte man im Sinne der Zukunftssicherheit gleich unicodiert anlegen.

Den größten Teil des Umstellungsprojektes nimmt sicher die Applikation ein. Der Programmierer muss einkalkulieren, dass er die Quellen Zeile für Zeile durchgeht, um nach unmittelbaren und mittelbaren Datenbankoperationen Ausschau zu halten. Die hat er zu untersuchen und gegebenenfalls zu ändern, wenn Variablengrößen für Unicode nicht mehr ausreichen, API-Funktionen ungeeignete Parameter oder Rückgabewerte aufweisen, Checks auf Werte oder Vergleichsoperationen auf zu kleine Ranges lauten oder zu simpel arbeiten und so weiter.

Gerne übersehen werden nach dem Alphabet sortierte Listen: Hier ist nicht nur der viel größere Umfang zu erwartender Buchstaben zu beachten, sondern die Sortierreihenfolge selbst, beispielsweise an welcher Stelle Umlaute und Buchstaben mit Akzenten auftauchen sollen.

Aus der Komplexität ergibt sich fast zwingend die Notwendigkeit, die Applikation im stillen Programmierstübchen abseits des Produktivbetriebs umzubauen. Dazu legt sich der Entwickler eine Testdatenbank gleicher Struktur wie die produktive an, achtet dabei aber darauf, dass sie von Anfang an mit Unicode arbeitet. Dann klont er den Entwicklungszweig für die vorhandene DB-Applikation, biegt sie auf die Testdatenbank um und schreibt sie Stück für Stück auf Unicode um. Erst, wenn das geschafft ist, gehts ans Konvertieren der Produktivdatenbank und Freischalten der neuen Applikation.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Umlaute auf Umwegen

    Kommen Umlaute in Programmtexten oder Daten ins Spiel, ist der Perl-Programmierer gefragt. Denn ohne seine Mithilfe entstünde ein Kodierungskauderwelsch.

  • Zeichenkünstler

    Das globale Dorf ist seit dem 1. März ein Stück weltoffener geworden: In Domainnamen sind jetzt deutsche Umlaute sowie asiatische und arabische Schriftzeichen erlaubt. Damit eröffnen sich für Entwickler und Benutzer neue Möglichkeiten, es ergeben sich aber auch neue Probleme.

  • Superseriousstats 4.0 behebt Unicode-Probleme

    Superseriousstats, ein Programm zur Auswertung von IRC-Logfiles, ist in Version 4.0 mit einigen Verbesserungen erhältlich.

  • Abschrift

    Immer mehr Linux-Systeme nutzen UTF-8 statt ISO-8859 für die Zeichenkodierung. Beim Update einer Distribution entsteht ohne Konvertierung schnell Datenmüll. Ein Migrationsleitfaden.

  • Maria-DB-Replikation

    Sind die Datenbankinhalte so wichtig, dass sie auch zwischen periodischen Datensicherungen nicht verloren gehen dürfen, dann ist Replikation ein Ausweg. Dieser Artikel beschreibt, wie sich die Doppelung mit Maria DB unter Zuhilfenahme von Xtra Backup bequem einrichten lässt.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.