Arbeitet man in LiveCode mit externen Textdateien, mit Datenbanken oder mit Texten aus Webseiten, die man verarbeiten möchte, stößt man früher oder später immer auf das Problem der Zeichenkodierungen. Umlaute und Sonderzeichen, die im Originaltext noch ganz korrekt aussahen, verwandeln sich plötzlich in obskure Gebilde oder in falsche Buchstaben oder die verschwinden ganz. Das ist das typische Phänomen, wenn man es mit unterschiedlichen Zeichenkodierungen zu tun hat.

Wie vieles beim Programmieren hat das historische Gründe. In der Frühzeit der Computerkultur kam man noch mit dem sogenannten 7bit-ASCII-Zeichensatz aus. Das waren 128 Zeichen – und damals scheinbar alle, die man brauchte. Zumindest in Amerika. Deutsche Umlaute kamen ebensowenig vor wie Sonderzeichen, die man in den USA selten verwendet. Mitte der 1980er Jahre wurde die Zeichenauswahl durch 8-bit-Standards erweitert. In Westeuropa und den USA einigte man sich zumeist auf den Standard ISO-8859-1 mit 256 Zeichen, in dem das komplette westliche Alphabet sowie zahlreiche internationale Sonderzeichen und Umlaute enthalten waren. Zahlreiche – aber nicht alle. Von kyrillischen oder chinesischen Schriftzeichen ganz zu schweigen. Jahrelang war ISO-8859-1 (auch Latin-1) mit zahlreichen Varianten für Windows und MacOS der Standard und für englischsprachige oder deutschsprachige Anwendungen kommt man damit eigentlich meistens noch gut aus. LiveCode hat bis Version 6 auch diesen erweiterten ASCII-Standard intern verwendet (unterschiedlich je nach Plattform). Auch die meisten älteren Webseiten sind in diesem Zeichenformat kodiert,

Mittlerweile ist die Entwicklung aber noch um einiges weiter gegangen. Seit Ende der 1990er Jahre begann der neue Standard Unicode immer mehr an Bedeutung zu gewinnen. Hier war die Idee, ein Format zu schaffen, das alle auf der Welt existierenden Zeichen umfasst – es gibt dabei eine oder sogar mehrere 16-bit Ebenen von jeweils 65.536 verschiedenen Zeichen. Die konkrete Codierung, in der Unicode in Windows, OS-X, Linux und Unix umgesetzt wird, heißt UTF-8 und UTF-16. Heute ist Unicode Standard-Kodierung der allermeisten Webseiten, Datenbanken und Betriebssysteme.

LiveCode verwendet intern und in den Standard-Textelementen seit Version 7 ebenfalls ein auf Unicode basierendes Zeichensystem. Daher kann LiveCode souverän mit allen Arten von Unicode-Texten umgehen. Man muss nur wissen, wie man vorgeht, wenn man seine Texte fehlerfrei angezeigt bekommen möchte.

Ein ganz einfaches Beispiel zur Verdeutlichung:

Wir starten einen Stack und ziehen ein Scrolling Field hinein. Danach öffnen wir die deutsche Wikipedia Seite „LiveCode“ im Webbrowser und kopieren den ersten Abschnitt. Diesen setzen wir per Einfügen in das Scrolling Field (im Live-Modus von LiveCode).

In ein Scrolling Field hineinkopierter UTF-8-Text – Umlaute und Sonderzeichen erscheinen falsch.

Wie sorgen wir nun dafür, dass unser Text in LiveCode mit den korrekten Zeichen wiedergegeben wird und auch so verarbeitet werden kann?

Seit LiveCode 7 gibt es dafür eine ganz einfache Funktion, die einen Text von seinem ursprünglichen Format in das interne LiveCode-Unicode-Format konvertiert. Sie sieht folgendermaßen aus:

textDecode („Text“, „Ursprungskodierung“)

Da wir es hier mit einem UTF-8 Text zu tun haben (so wie die meisten Texte im Web), würden wir den Inhalt von field 1 so in LiveCode-Text konvertieren:

textDecode (field 1, „UTF-8“)

Konkret machen wir es einfach so: Setze einen Button neben das Textfeld und gib ihm folgendes Skript:

on mouseUp
   put textDecode(fld 1,“UTF-8″) into normalText
   put normalText into fld 1
end mouseUp

Ein Klick auf den Button, und schon verwandelt der fehlerhafte Text sich in einen wunderbar lesbaren.

Dieses Beispiel funktioniert ebenso gut wenn Du einen kyrillischen oder chinesischen Text in das Textfeld kopierst (vorausgesetzt der Font des Textfeldes enthält diese Zeichen). Du musst LiveCode mit der textDecode-Funktion nur sagen, aus welchem Format es den Text in sein internes Format übersetzen soll.

Die textDecode-Funktion benötigst Du immer, wenn Du einen Text aus einer externen Quelle, der in UTF-8 oder UTF-16 kodiert ist, als Text in Livecode importieren willst und ihn betrachten oder verarbeiten möchtest.

Wenn Du also einen Text aus einer externen Unicode-Datei einliest und umwandelst, dann sieht das etwa so aus:

put url („binfile:datei.txt“) into UTFtext
put textDecode(UTFext,“UTF-8″) into LCtext

UTF-8 ist das am häufigsten verwendete Unicode-Format, aber LiveCode kann natürlich auch mit UTF-16 und anderen Formaten umgehen. Eine Liste der Formate, die LiveCode in sein eigenes Textformat umwandeln kann, findest Du im Dictionary, wenn Du „textDecode“ eingibst.

Unicode in Datenbanken

Wenn Du mit SQlite oder mySQL-Datenbanken arbeitest, wirst Du sehr häufig mit der Zeichenkonvertierung zu tun haben, denn standardmäßig sind diese Datenbanken heutzutage auf UTF-8 (oder manchmal UTF-16) Format voreingestellt (sie lassen sich auch bei der Erstellung auf ISO-8859-1 setzen, aber das wird nicht mehr wirklich empfohlen). Greifst Du jetzt mit einer Datenbankabfrage auf eine bestehende Datenbank im UTF-8-Format zu, dann musst Du das Ergebnis der Datenbankabfrage erst einmal decodieren, bevor Du es in LiveCode-Tabellen oder Textfeldern korrekt anzeigen kannst. Das sieht dann zum Beispiel so aus:

put „SELECT vorname,nachname,telefon FROM personendaten“ into sql
put revDataFromQuery(tab,return,dbid,sql) into ergebnis
put textDecode (ergebnis, „UTF-8“) into ergebnis
set the dgtext of group „tabelle“ to ergebnis

(Um die dazugehörigen Grundlagen von Datenbank und DataGrid zu verstehen, empfehle ich die beiden zugehörigen Artikel hier im Blog: Keine Angst vor Datenbanken und DataGrid eine vielseitige Tabelle.)

In Unicode-Datenbank schreiben

Solange Du aus einer Datenbank nur liest und das Ergebnis anzeigst, reicht das aus. Was aber, wenn Du in diese Datenbank auch Daten hineinschreibst? Dann musst Du genau umgekehrt vorgehen, denn schließlich müssen die Texte aus LiveCode jetzt wieder ins Unicode-Format gewandelt werden, bevor sie in die Datenbank geschrieben werden. Das geschieht mit der Funktion:

textEncode („Text“, „Zielkodierung“)

Diese Funktion wandelt den Text aus dem internen LiveCode-Format in die gewünschte Zielkodierung (meist ist das UTF-8).
Um Daten ohne Probleme korrekt in eine Unicode-Datenbank zu schreiben, muss jeder einzelne Texteintrag vorher kodiert werden und dann in den SQL-Befehl eingefügt werden (Reine Zahlen müssen nicht kodiert werden, die sind intern und in Unicode gleich). Also zum Beispiel so:

put textEncode (field „vorname“, „UTF-8“) into vorname_utf
put textEncode (field „nachname“, „UTF-8“) into nachname_utf
put „INSERT INTO personendaten (nachname,vorname,telefon) VALUES (‚“&nachname_utf&“‚,'“&vorname_utf&“‚,'“&telefon&“‚)“ into sql
revExecuteSQL dbid, sql

Damit werden die Daten dann auch wieder korrekt in die Datenbank geschrieben, und alles funktioniert in beide Richtungen.

Ebenso müssen wir LiveCode-Text kodieren, bevor wir ihn ihn eine externe Datei schreiben wollen, die im Format UTF sein soll.

put textEncode (meinText, „UTF-8“) into url („binfile:C:/datenliste_utf.txt“)

Mac und Windows

Wenn Du Programme entwickelst, die sowohl für Mac als auch für Windows umgesetzt sollen, stellt sich die Frage, in welchem Zeichenformat Du externe Textdateien (wenn welche benötigt werden) speichern sollst. Früher war es klar, dass die Mac-Textdateien in MacOS-Roman (8-bit ASCII) und Windows-Textdateien in WIndows-1252 oder in ISO 8859-1 gespeichert wurden. Diese Dateien kann LiveCode nach wie vor ohne Konvertierung auf der jeweiligen Plattform einlesen und verarbeiten – aber wenn die Datei auf der einen Plattform (zum Beispiel Mac) erstellt wurde und dann auf der anderen Plattform (zum Beispiel Windows) gelesen werden sollte, gab es schon Probleme, und es kamen falsche Zeichen heraus. Dafür gibt es in LiveCode seit langer Zeit die Funktionen

isoToMac(„text“)   und   macToISO(„text“) .

Sie wandeln einen mit Mac erstellten Text in das in Windows verwendete Format um und umgekehrt. Im Skript musste man dann die Plattform abfragen und dementsprechend den Text umwandeln oder auch nicht.

Es gibt diese Funktionen zwar noch immer in LiveCode, aber sie sind jetzt nicht mehr wirklich sinnvoll oder notwendig. Viel sinnvoller ist es, Textdateien, die auf mehreren Plattformen verwendet werden sollen, gleich im Format UTF-8 anzulegen und sie beim Einlesen immer mit textDecode in das interne LiveCode-Format umzuwandeln. Das gibt die größte Flexibilität bei der Zeichenverwendung – und die Programme laufen auf Windows wie Mac ohne weitere Eingriffe gleichermaßen korrekt.

Die Gegenwart basiert auf Unicode – und dies tut auch LiveCode. Also sollten wir es auch verwenden.

Wie immer sind Feedback, Fragen (im Forum) und Diskussion hierzu willkommen.