2 Die Codierung Sehen wir uns mal den vereinfachten Weg der Informationen von der Tastatur aus bis zum Filesystem an:

Transkript

1 Name Klasse Datum 1 Allgemeines Daten werden bekanntermaßen im Computer in einem flüchtigen Speicher, dem RAM verarbeitet. Insofern gehen sie verloren, sobald der Rechner ausgeschaltet wird. Weiterhin ist der RAM begrenzt, was in Summe eine weitere Möglichkeit fordert, Daten zu speichern. Wir alle wissen, dass uns diese Möglichkeit die Festplatte liefert, indem wir die Daten als Files speichern. Da der RAM nur Zahlen im digitalen Format ablegt liegt es also nahe, dass die Daten auf dem Filesystem ebenfalls in digitaler Form vorliegen. In den folgenden Kapiteln werden wir uns genau diesen Prozess etwas genauer ansehen und den Code kennen lernen, welcher in Java für den Umgang mit Files ermöglicht. Hierbei werden wir uns auf Textdateien konzentrieren, wobei es dem Filesystem erst mal egal ist, ob es sich gerade um ein Text- oder Binärfile handelt. Um dies zu verdeutlichen hier zwei Bytesequenzen. Eine Bytesequenz eines Binärfile (hier VLC.exe): D B5 E0 FD FF FF C A D8 Hier eine Bytesequenz eines Textfiles (hier AUTHORS.txt von VLC): F 4C 41 4E E Wie wir sehen, können wir als normaler Mensch erst mal keinen systematischen Unterschied erkennen. In der Tat kann das der Computer ebenfalls nicht. Man muss ihm erstmal mitteilen, was er mit diesem File machen soll. Wenn wir die Datei AUTHORS.txt mit einem Texteditor (bspw. Notepad++) öffnen, dann werden die Bytes als Zeichen interpretiert und können von uns gelesen werden. Wir können aber auch die Datei VLC.exe mit Notepad++ öffnen. Wir werden dann ein fürchterliches Durcheinander von Zeichen sehen und zwar solchen, die sinnvoll angezeigt werden können und solchen, welche nur durch irgendwelche Sonderzeichen angegeben werden. Dies liegt daran, dass die Bytes in VLC.exe nicht für das lesen in einem Texteditor geschaffen wurden, sondern durch die Interpretation durch das Betriebssystem Windows. Dies führt uns zu folgender Erkenntnis: Dateien müssen von einem Programm sinnvoll interpretiert werden. 2 Die Codierung Sehen wir uns mal den vereinfachten Weg der Informationen von der Tastatur aus bis zum Filesystem an: Zuerst geben wir die Buchstaben ein. Die Signale werden von der Tastatur über das Betriebssystem an den Texteditor gesendet. Die Tastatur schickt also Codes für die eingegebenen Zeichen. Im Texteditor wird nun eine Umsetzung gemacht. Mittels einer Art Tabelle dem Zeichensatz, oder der Zeichencodierung wird nun jedem gewünschten Zeichen ein neuer Code zugeordnet. Dieser Code ist nun der Text mit der verwendeten Zeichencodierung. Dieser wird auch 1:1 auf dem Filesystem abgelegt. Wollen wir das File nun wieder lesen, so wird mit der gleichen Zeichensatztabelle jedem Code wieder ein Zeichen zugeordnet der Text ist wieder lesbar. Wichtig ist also, dass die Codierung beim Lesen und Schreiben identisch ist zumindest für den Fall, dass es Zeichen mit einem Codewert über 127 gibt. ANPR_TextFiles_v01.docx Seite 1

2 Sollte dies nicht so sein, könnte bspw. folgendes passieren. Wir speichern den Text Straße mit der Codierung OEM 858 ab und lesen das File wieder mit ISO Hierbei werden alle Zeichen kleiner als 128 korrekt dargestellt, was die Zeichen S, t, r, a, s und e beinhaltet. Das Zeichen ß liegt bei E1 (also 225), was von ISO als á interpretiert wird. Der gelesene Text wird also falsch dargestellt. Dies kann bspw. mit Notepad++ nachgestellt werden, indem beim Menüpunkt Kodierung die entsprechenden Werte gewählt werden (Kodierung-> Zeichensatz -> Westeuropäisch). Gerade für Webanwendungen wird daher empfohlen auf ein Unicode Format zu gehen. Hier hat sich UTF 8 sehr weit verbreitet. (UTF8: Universal Character Set Transformation Format mit einer Staffelung von 8 Bits). Hierbei werden die ersten 128 Zeichen (also die 7 niederwertigsten Bits) 1:1 mit der ASCII Kodierung zugeordnet wodurch UTF8 mit ASCII kompatibel ist. Insofern ist für alle ASCII kompatiblen Zeichen das oberste Bit des ersten Bytes immer 0. Steht es auf 1, so indiziert dies dem interpretierenden System, dass es mindestens ein weiteres Byte gibt, welches für die Kodierung verwendet wird. Theoretisch kann ein UTF8 Zeichen mit bis zu 8 Byte codiert werden, wobei in der Praxis bis maximal 4 Bytes verwendet werden. Der große Vorteil von UTF8 ist, dass praktisch alle verfügbaren Zeichen abgebildet werden können. Nachteilig wirkt sich die Tatsache aus, dass alle Zeichen außerhalb des ASCII Zeichenraums auf jeden Fall mehr als ein Byte Speicherplatz benötigen. Wir nutzen in unseren Rechnern im Regelfall Latin 1 (bzw. ISO ), wobei für internationale Anwendungen UTF8 vorzuziehen ist was die hohe Nutzungszahlen bei Webseiten erklärt. 2.1 Sonderzeichen Alle Zeichen, welche in Texten vorhanden sind, müssen über das Charset definiert sein. Nun gibt es auch Zeichen, welche nicht zu einer Zeichendarstellung auf dem Bildschirm führen, sondern zur Steuerung der Ausgabe ( nicht druckbare Zeichen ). Wir gehen an dieser Stelle lediglich auf den Zeilenumbruch ein es sei aber darauf hingewiesen, dass es noch weitere Steuerzeichen gibt (bspw. Tabulator). Der Zeilenumbruch hat eine lange Geschichte schließlich waren die ersten Maschinen zur Textausgabe keine Computerbildschirme, sondern mechanische Schreibmaschinen. Bei diesen war es notwendig für einen Zeilenumbruch zwei Dinge zu tun den Wagen zurückzuschieben (carriage return) und den Zeilenvorschub durchzuführen (line feed). Die Datenübermittlung via Fernschreiber war der nächste Schritt, wobei die mechanische Notwendigkeit von Wagenrücklauf und Zeilenvorschub immer noch vorhanden war. Für diese Steuerung benötigte man entsprechend zwei Steuerzeichen CR (carriage return) und LF (line feed). Diese haben auch die Einführung der Computertechnik überlebt und finden sich somit immer noch in unseren Zeichensätzen. CR hat im ASCII Code den Wert 0D und LF den Wert 0A erhalten. Wenn wir mit Notepad++ eine Textdatei öffnen können wir diese Zeichen auch sichtbar machen: Seite 2

3 Textfiles lesen und schreiben Warum braucht der Computer denn immer noch zwei Zeichen für den Zeilenumbruch? Eines würde doch reichen! Antwort: Eigentlich reicht dem Computer auch ein Zeichen. In Unix und MacOS wird tatsächlich auch nur ein Zeichen, das LF verwendet (wobei bei älteren Macs bis zu einem gewissen Zeitpunkt nur CR verendet wurde). Bei Microsoft blieb man jedoch bei den beiden Zeichen CR LF. Dies bringt in der Tat einige Probleme mit sich. Wenn ich eine Datei in Unix erstelle und sie nach Windows kopiere, dann erkennt Windows den Zeilenumbruch nicht! Programme wie Notepad++ können dies aber korrigieren, indem unter Bearbeiten- > Format Zeilenende das gewünschte eingestellt werden kann. 3 Lesen von Text in Java Der Umgang mit Files wird in Java (wie auch in vielen anderen Programmiersprachen) mittels eigener Bibliotheksfunktionen erledigt. Diese liegen in Java meist unter java.io. Weiterhin bieten die meisten Programmierbibliotheken erweiterte Methoden an mit Files zu arbeiten, welche zum Teil die Schreibarbeit erheblich vereinfachen. An dieser Stelle wollen wir jedoch nur die gebräuchlichsten Methoden verwenden mit dem Hinweis, dass es noch viele weitere Möglichkeiten gibt. 3.1 Nutzung des FileReaders Beginnen wir mit einer recht einfachen Methodik unter Verwendung des FileReaders. Dieser erlaubt es uns einzelne Zeichen aus einem File zu lesen und abzulegen. Hierzu müssen wir den FileReader erst erzeugen, indem wir dem Objekt sagen, welches File zu öffnen ist. Anschließend lesen wir in einer Schleife Zeichen für Zeichen aus und geben es am Bildschirm aus. Die Zeichen werden allerdings nicht in einer char Variable übergeben, sondern in einer int Variable. Sehen wir uns dies mal in einem Codebeispiel an: Wie wir sehen, müssen wir hier einige Dinge beachten. Wir müssen die Objekte erzeugen, müssen die entsprechenden Exceptions abfangen und vor allem müssen wir den Stream wieder schließen, was wir nach dem try/catch Block im finally tun (finally wird immer durchlaufen, egal, ob eine Exception erfolgt oder nicht). Seite 3

4 Warum liefert mir der FileReader nicht gleich die Zeichen als char Werte an? Dann könnte ich mir den Typecast von int zu char sparen! Antwort: Das Problem ist, dass der Leseprozess dem Aufrufer irgendwie mitteilen muss, dass er am Ende angekommen ist, was durch die Zahl -1 indiziert wird. Für diese gibt es aber keinen char Wert. Insofern werden die Zeichen als int übergeben und müssen danach in char umgewandelt werden, sofern es sich nicht um die -1 handelt. Soweit funktioniert das Programm nun. Trotzdem ist das einzelne Lesen von Zeichen als Zahl und die Konvertierung in char irgendwie nicht das Gelbe vom Ei. Hier gibt es durchaus noch sinnvolle Alternativen. 3.2 Vereinfachung mittels BufferedReader Die Standardantwort auf das Puffern von Zeichen ist der BufferedReader. Dieser stülpt sich quasi über den FileReader und übernimmt den Zeichenstrom, damit wir über den Buffered Reader bequemer arbeiten können. Im Wesentlichen arbeitet der BufferedReader nun Zeilenweise und gibt uns pro Filezeile nun einen String zurück: Wie wir sehen ist der Code schon etwas schlanker geworden. In vielen Tutorials sieht man auch eine Kurversion dieses Codes, indem der FileReader direkt im Konstruktor des BufferedReaders erzeugt wird: brmyreader = new BufferedReader(new FileReader( C:/tmp/myFile.txt ); Dies ist noch kürzer wir müssen allerdings darauf achten, dass wir nun nicht mehr den FileReader schließen, sondern den BufferedReader: try { brmyreader.close(); } catch (IOException e) { e.printstacktrace(); } Seite 4

5 Textfiles lesen und schreiben Das Schachteln der beiden Konstruktoren birgt aber die Gefahr, dass wenn bei der Erzeugung des BufferedReaders etwas schief läuft, wir keine Referenz mehr auf den FileReader haben und ihn nicht schließen können. Zum Glück tritt diese Situation aber praktisch nicht ein. Woher weiß Java eigentlich, welches Charset zu verwenden ist? Antwort: Java weiß es schlichtweg nicht es wird vom Standard Charset des Systems genutzt. Wenn wir einen anderes Charset verwenden wollen, dann müssen wir einen anderen Weg gehen. 3.3 UTF8 Codierungen lesen Das bisherige Verfahren lässt eine Flexibilität in puncto Charset vermissen. Um dies nun in unserem Reader auch zu berücksichtigen, müssen wir zwischen den Bytes und den Zeichen einen Übersetzter einbauen, welcher flexibel konfigurierbar ist. Dies erledigt uns der InputStreamReader. Dieser ist jedoch nicht in der Lage auf das Filesystem direkt zuzugreifen. Also wird noch ein Objekt benötigt, welches in der Lage ist die Bytes vom Filesystem 1:1 zu laden. Hierfür verwenden wir den FileInputStream, der entsprechend den Pfad zur Datei erhalten muss. Sehen wir uns mal den Code an: Auch hier können die Konstruktoren direkt ineinander verschachtelt werden und nur den BufferedReader schließen wieder mit dem potentiellen Problem, dass wir einen Zugriff auf ein nicht existierendes Objekt haben. In Unix ist der String für die Separierung von Ordnern das / Zeichen in Windows allerdings das \ Zeichen. Da Java ja auf beiden Betriebssystemen läuft kommt es da nicht durcheinander? Antwort: Java ist in der Tat plattformübergreifend. Insofern kann der Pfadseparator tatsächlich problematisch werden. In aller Regel funktioniert aber das / aber auch bei Windows. Wer auf Nummer sicher gehen will, baut die Pfade aus Einzelstrings auf und nutzt als Pfadseparator File.pathSeparator, dort findet sich immer der richtige. Seite 5

6 4 Schreiben von Text in Java Wie beim Lesen auch, gibt es beim Schreiben mehrere Möglichkeiten. An dieser Stelle werden wir nur eine vorstellen, wer hier weitere Details wissen will, sei auf das Internet verwiesen (bspw. Die hier gezeigte Methodik ist prinzipiell der inverse Weg wie die Nutzung des InputStreamReades. Es werden über einen BufferedWriter die Strings an das File angehängt. Diese wiederum werden als Character Werte an den OutputStreamWriter geliefert, der wiederum verschiedene Charsets supported und die Bytes erzeugt. Die Kommunikation mit dem Filesystem wird von dem FileOutputStream übernommen. Drei Punkte sind hierbei neu. Zum einen kann man über einen boolean Parameter dem FileOutputStream mitteilen, dass er ein existierendes File verlängern (true) oder überschreiben soll (false). Zum anderen kann der Zeilenumbruch über die Funktion newline() eingetragen werden, wodurch er bspw. bei Unix Systemen CR ist und bei Windows CR LF. Schließlich fällt uns noch der flush Befehl auf, der dafür sorgt, dass die Daten in einem Rutsch an das File gehängt werden. Seite 6

7 Textfiles lesen und schreiben 5 Lizenz Diese(s) Werk bzw. Inhalt von Maik Aicher ( steht unter einer Creative Commons Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Seite 7