Computer speichern alle Daten in Speicherzuständen, auch Texte, Bilder usw. Über das Binärsystem können wir diese Zustände mit Zahlenwerten identifizieren. Auch Texte werden gewissermaßen als Zahlenfolgen behandelt. Dazu wird jedem Schriftzeichen ein Zahlenwert zugeordnet. Eine der ältesten Zuordnungstabellen (im Bereich der Computertechnologie) ist der American Standard Code for Information Interchange ASCII, der schnell zu einem weltweiten Standard der Zeichencodierung wurde. Der ASCII-Code verwendet 7 Bit, kann also 128 Zeichen darstellen. Bei den ersten 32 Zeichen handelt es sich um Steuerbefehle, z. B. der Tabulatorvorschub oder das Zeilenende. Die weiteren beinhalten unter anderem die 26 Klein- und ebenso vielen Großbuchstaben des lateinischen Alphabets, die zehn Ziffern 0-9 sowie Leerzeichen und diverse Satzzeichen.

Selbstverständlich ist bei einem Zeichenvorrat von 128 Zeichen nicht genug Platz, um alle länderspezifischen Sonderzeichen wie etwa die deutschen Umlaute mit aufzunehmen. Sprachen, die nicht auf dem lateinischen Alphabet beruhen — als Beispiele seien nur einmal das griechische und das kyrillische Alphabet genannt — benötigen sogar eine beachtliche Menge an zusätzlichen Zeichen. Da sich allerdings schnell die Byte-Größe von 8 Bit durchsetzte und ein ASCII-Zeichen damit nur die Hälfte des Byte-Zahlenbereichs nutzte, lag es nahe, die restlichen 128 Werte mit den Zeichen zu füllen, die man gerade brauchte. Es entstanden eine Reihe an ANSI-Codepages² mit den national benötigten bzw. gewünschten Zusatzzeichen. Bei uns am bekanntesten sind die Codierungen ISO-8859-1 und ISO-8859-15, die unter anderem die deutschen Umlaute und eine Reihe an Vokalen mit Akzentzeichen enthält und den Zeichenvorrat eines großen Teils der westeuropäischen Sprachen abdeckt. ISO-8859-5 dagegen enthält sämtliche Schriftzeichen des kyrillischen Alphabets, ISO-8859-6 die arabischen Zeichen usw.

Konkret bedeutet das: Wenn Sie einen ANSI-codierten Text vorliegen haben, ohne die konkrete Codepage zu kennen, können Sie die Zeichen ab Nr. 128 nicht korrekt darstellen. Hierin liegt auch der Grund, warum es bei der Verwendung von Umlauten in FreeBASIC zu Problemen kommen kann. Im Gegensatz zum ASCII-Code ist der Begriff ANSI-Code nicht genormt. Und es gibt noch weitere Probleme: In manchen Sprachen gibt es deutlich mehr Schriftzeichen, als in der ANSI-Codierung Platz hätten. Die chinesische Schrift etwa kennt mehrere Tausend Zeichen, selbst wenn die selten verwendeten Zeichen nicht mitgezählt werden. Für eine international geeignete Codierung ist daher ein deutlich größerer Zeichenvorrat nötig. Deshalb wurde Unicode entwickelt, welches heute weit über 100 Schriftsysteme und über 120 000 Zeichen unterstützt.

Wir werden im Folgenden mehrfach auf den Begriff ASCII-Code zu sprechen kommen. Es sei noch einmal darauf hingewiesen, dass diese Codierung lediglich die Zeichen mit den Nummern 0 bis 127 beinhaltet. Der Einfachheit halber werden wir aber auch die Zeichen 128 bis 255 als „erweiterten ASCII-Code“ bezeichnen, um eine ständige Differenzierung zwischen den ASCII-Zeichen und den weiteren ANSI-Zeichen zu vermeiden.

Den ASCII-Code eines Zeichens können Sie mit ASC() ermitteln. ASC() erhält als Parameter eine Zeichenkette, es wird davon jedoch nur das erste Zeichen ausgewertet.

Um beispielsweise den ASCII-Code des dritten Zeichens eines Strings auszugeben, gab es früher nur die Möglichkeit, einen Teilstring ab dem dritten Zeichen zu erstellen und davon den ASCII-Wert zu bestimmen. Inzwischen geht das auch einfacher — ASC() erlaubt nämlich in FreeBASIC die Angabe eines zweiten Parameters, der die Position des gewünschten Zeichens bestimmt. Das dritte Zeichen des Strings "Hallo Welt" lässt sich also auch über ASC("Hallo Welt",3) ansprechen. Eine Alternative zu Quelltext 13.3 wäre damit:

Hier greife ich schon die in Kapitel 15.2.1 vorgestellte Funktion LEN() zur Ermittlung der Länge eines Strings voraus.

Für die tatsächlichen ASCII-Werte — also alle Zeichen bis zum Wert 127 — ist die Zuordnung eindeutig, Sie werden also immer, wenn Sie ASC("a") aufrufen, das Ergebnis 97 erhalten. Anders sieht es mit den Zeichen der ANSI-Erweiterung aus. Wenn Sie z. B. ASC("ä") ermitteln wollen, hängt das Ergebnis von der in Ihrer IDE verwendeten Codepage ab, also davon, nach welcher Code-Tabelle die IDE das Zeichen "ä" speichert. Erhalten Sie die Zahl 228, dann verwendet die IDE vermutlich ISO-8859-1 oder ISO-8859-15.

Die Konsole verwendet möglicherweise eine vollkommen andere Codepage als Ihre IDE. Am einfachsten sehen Sie das, wenn Sie den Schritt rückwärts gehen. Mit CHR() wird eine ASCII-Nummer in das zugehörige Zeichen umgewandelt.

Die Konsole unter Windows verwendet in der Regel Codepage 850; dort ist unter der Nummer 228 das õ gespeichert. Unter Linux hängt die Codepage von den System- und Konsoleneinstellungen ab. Viele Konsolen unter Linux arbeiten mit Unicode; in diesem Fall ist die Angabe 228 an dieser Stelle überhaupt nicht interpretierbar. Im Grafikfenster (darauf kommen wir in [KapGrafik] zu sprechen) kommt dagegen Codepage 437 zu tragen, diesmal unabhängig vom Betriebssystem.

Die verfügbaren Zeichen finden Sie in Anhang C aufgelistet; beachten Sie jedoch, dass die Zeichen im Konsolen-Modus von der dort eingesetzten Codepage abhängen und daher abweichen können. Wenn Sie selbst testen wollen, wie Ihr Konsolenfenster die Zeichen von 128 bis 255 interpretiert, kann Quelltext 13.5 helfen. Sollten Sie nur „undefinierte Zeichen“ erhalten, wird Ihre Konsole vermutlich gar keinen ANSI-Satz verwenden, sondern mit Unicode arbeiten.

Wenn Sie mehrere Nummern gleichzeitig in ihren ASCII-Code umwandeln wollen, können Sie die Werte als Parameterliste von CHR() angeben.

Zur Nutzung von Unicode ist CHR nicht geeignet, aber es gibt dafür eine Ersatzfunktion namens WCHR(). Diese gibt zu einer Unicode-Nummer das passende Zeichen zurück.

Sie können diese Ausgabe natürlich nur dann korrekt sehen, wenn die verwendete Konsole Unicode unterstützt.

ASC() und CHR() geben zwei verschiedene Interpretationen desselben Speicherzustandes wieder — einmal als UBYTE und einmal als STRING der Länge 1. Das lässt sich auch für größere Datentypen überlegen: Der Datenteil einer zwei Zeichen langen Zeichenkette belegt zwei Byte, genauso wie ein SHORT. Bei einer vier Zeichen langen Zeichenkette belegt der Datenteil denselben Speicherplatz wie ein LONG, usw. Da liegt es nahe, eine direkte Umwandlung von Zeichenketten in Zahlen zu definieren, die einer identischen Speicherbelegung entsprechen. Natürlich gibt es dazu auch eine Rückumwandlung. Sie können die Funktionen Tabelle 13.2 entnehmen.

Für CVI() kann auch explizit die Bit-Zahl angegeben werden, die verwendet werden soll. Erlaubt sind die Werte 16, 32 und 64, und die Angabe erfolgt in spitzen Klammern direkt hinter dem Befehl. Ohne eine solche Angabe wird die Größe eine INTEGER verwendet, also 32 Bit beim 32-Bit-Compiler und 64 Bit beim 64-Bit-Compiler.

Als Beispiel soll CVSHORT() dienen, da es mit den kleinsten Werten arbeitet und dadurch am leichtesten nachzurechnen ist.

"H" besitzt den ASCII-Code 72, "i" den ASCII-Code 105. Da das "i" an zweiter Stelle steht, hat seine Codenummer den 256-fachen Stellenwert. 72 + 105·256 ergibt den vom Programm ausgegebenen Wert 26952. Dasselbe hätte auch CVI<16>() ergeben:³

Eine Rückumwandlung erfolgt über MKSHORT():

PRINT MKSHORT(26952)     ' oder PRINT MKI<16>(26952)
SLEEP

UNION LongintString
  AS STRING*8 s
  AS LONGINT  i
END UNION

DIM AS LONGINT testZahl = 2410100309775106630
DIM AS LongintString testUnion
testUnion.i = testZahl 
PRINT testUnion.s
PRINT MKLONGINT(testZahl)
PRINT MKI<64>(testZahl)
SLEEP

FB4ever!
FB4ever!
FB4ever!