4. Kodieren von Daten (1)

Als erstes Beispiel für ein Dokument wollen wir eine einfache Text-Datei studieren. Unter Windows können wir Text-Dateien mit dem Text-Editor namens "Editor" erzeugen.

1. Aufgabe

• Erzeuge mit dem "Editor" eine kurze Text-Datei mit folgendem Inhalt:



• Speichere die Datei im Homeverzeichnis unter dem Namen "Beispiel.txt" ab.
  
  
• Lade die Datei "Beispiel.txt" in den Hex-Editor. Was fällt dir im Unterschied zu den im vorigen Abschnitt gemachten Beobachtungen auf?
  Vor dem Weiterlesen, sollten mindestens 2 Punkte dazu aufgeschrieben werden!

Text-Dateien tragen üblicherweise (aber nicht immer!) die Endung ".TXT". Sie haben ein recht einfaches, aber weit verbreitetes Dateiformat, das in vielen Fällen sogar den Datenaustausch zwischen verschiedenen Betriebssystem-Plattformen ermöglicht.

Im Hex-Editor wird die Datei "Beispiel.txt" etwa folgendermaßen dargestellt:

Bei genauerer Betrachtung dieses Beispiels kann man folgendes feststellen:

• Den meisten Bytewerten in dieser Datei entspricht eindeutig ein Zeichen. Z.B. wird jedes Byte 6Eh als "n" und jedes 65h als "e" interpretiert.
  
  
• Kleine Buchstaben werden offenbar in Bytewerten der Form 6Xh und 7Xh kodiert, große in solchen der Form 4Xh und 5Xh. (Das "X" steht dabei als Platzhalter für irgend eine jeweils passende Hex-Ziffer.)
  
  
• In einigen wenigen Fällen wird als zugehöriges Zeichen ein Punkt (".") dargestellt. z.B. bei den Bytewerten 0Dh, 0Ah, 2Eh, E4h. Offenbar hat der Punkt die Funktion eines "Dummy-Zeichens", wird also angezeigt, wenn der Hex-Editor zu einem Bytewert kein darstellbares Zeichen kennt.

Die wichtigste Erkenntnis ist, dass der Text offenbar so abgespeichert wird, dass jedem Zeichen eindeutig ein Bytewert entspricht. Die zugrundeliegende Zuordnung zwischen Zeichen und Bytewerten heißt ASCII-Code ("American Standard Code for Information Interchange"). Der ASCII-Code wurde schon 1963 vorgeschlagen; zehn Jahre später hat ihn schließlich die "International Standards Organisation" als internationale Norm festgeschrieben (ISO 636). Weitere historische Details findet man z.B. unter http://telecom.tbi.net/history1.html#ascii.

Zunächst wurden nur die ersten 128 der 256 möglichen Bytewerte mit je einem Zeichen belegt, also all diejenigen Bytewerte, deren höchstwertiges Bit den Wert "0" hat. Die 32 ersten Bytewerte wurden für sogenannte "Steuerzeichen" reserviert, Zeichen also, die normalerweise nicht am Bildschirm dargestellt oder ausgedruckt werden. Die folgende Tabelle zeigt den kompletten ASCII-Code. In jeder Spalte steht links die Hex-Darstellung des Bytes und rechts daneben das zugehörige Zeichen. Bei den Zeichen mit den Nummern 00h bis 1Fh sowie 7Fh ist lediglich eine Beschreibung angegeben, da es sich dabei um nichtdruckbare Zeichen handelt. Das Zeichen mit der Nummer 20h fehlt nicht etwa, sondern es ist das Leerzeichen, das man in der Tabelle (nicht) sieht ;-).

+---------------------------------------------------------------+
| 00 NUL| 01 SOH| 02 STX| 03 ETX| 04 EOT| 05 ENQ| 06 ACK| 07 BEL|
| 08 BS | 09 HT | 0A NL | 0B VT | 0C NP | 0D CR | 0E SO | 0F SI |
| 10 DLE| 11 DC1| 12 DC2| 13 DC3| 14 DC4| 15 NAK| 16 SYN| 17 ETB|
| 18 CAN| 19 EM | 1A SUB| 1B ESC| 1C FS | 1D GS | 1E RS | 1F US |
| 20    | 21  ! | 22  " | 23  # | 24  $ | 25  % | 26  & | 27  ' |
| 28  ( | 29  ) | 2A  * | 2B  + | 2C  , | 2D  - | 2E  . | 2F  / |
| 30  0 | 31  1 | 32  2 | 33  3 | 34  4 | 35  5 | 36  6 | 37  7 |
| 38  8 | 39  9 | 3A  : | 3B  ; | 3C  < | 3D  = | 3E  > | 3F  ? |
| 40  @ | 41  A | 42  B | 43  C | 44  D | 45  E | 46  F | 47  G |
| 48  H | 49  I | 4A  J | 4B  K | 4C  L | 4D  M | 4E  N | 4F  O |
| 50  P | 51  Q | 52  R | 53  S | 54  T | 55  U | 56  V | 57  W |
| 58  X | 59  Y | 5A  Z | 5B  [ | 5C  \ | 5D  ] | 5E  ^ | 5F  _ |
| 60  ` | 61  a | 62  b | 63  c | 64  d | 65  e | 66  f | 67  g |
| 68  h | 69  i | 6A  j | 6B  k | 6C  l | 6D  m | 6E  n | 6F  o |
| 70  p | 71  q | 72  r | 73  s | 74  t | 75  u | 76  v | 77  w |
| 78  x | 79  y | 7A  z | 7B  { | 7C  | | 7D  } | 7E  ~ | 7F DEL|
+---------------------------------------------------------------+

Gewisse Zeichen wie z.B. "ç", "å", "ß" oder die deutschen Umlaute fehlen im ASCII-Code. Sie werden durch Byte-Werte dargestellt, bei denen das höchstwertige Bit gesetzt ist, deren dezimaler Wert also größer als 127 = 7Fh ist. Der Hex-Editor stellt in der Text-Interpretation des Datei-Inhalts stets nur die druckbaren Zeichen des ASCII-Codes dar; alle anderen Zeichen werden durch einen Punkt (ASCII-Nr. 2Eh) angedeutet.

Eine besondere Rolle spielt die Bytefolge 0Dh 0Ah. Sucht man im Hex-Editor nach dieser Bytefolge und vergleicht mit der Darstellung der entsprechenden Textstelle im Text-Editor, dann wird der Schluss nahegelegt, dass mit dieser Bytefolge Zeilen-Umbrüche kodiert werden. Allerdings werden nur sogenannte "harte" Umbrüche in der Datei vermerkt, also solche, die der Benutzer bei der Eingabe durch Drücken der ENTER-Taste verursacht hat. "Weiche" Zeilenumbrüche, die der Texteditor auf dem Bildschirm selbständig macht, weil der Text dem rechten Rand des Fensters bedrohlich nahe kommt, werden offenbar nicht in die Datei geschrieben.

Ein Mangel des ASCII-Text-Formates ist es, dass keinerlei Textattribute wie Fettdruck, Unterstreichen usw. verfügbar sind. Solche "formatierten Texte" sind die Domäne der sogenannten "Textverarbeitungsprogramme".

2. Aufgabe

• Starte WORD mit einem neuen Dokument.
  
  
• Importiere die Datei "Beispiel.txt" (z.B. aus dem "Editor" über die Zwischenablage).
  
  
• Setze das Wort "doch" in Fettschrift.
  
  
• Speichere das Dokument im Homeverzeichnis unter dem Namen "Beispiel.doc" ab.
  
  
• Ermittle die Dateigrößen von "Beispiel.txt" und "Beispiel.doc".
  
  
• Lade dann "Beispiel.doc" in den Hex-Editor. Was fällt im Unterschied zu den beim TXT-Format gemachten Beobachtungen auf?
  
  Vor dem Weiterlesen, sollten mindestens 3 Punkte dazu aufgeschreiben werden!

Auffällig ist, dass die erzeugte DOC-Datei sehr viel größer ist, als die als Vorlage dienende TXT-Datei. Dies ist insofern erstaunlich, als der einzige Unterschied im Erscheinungsbild der beiden Texte darin besteht, dass das Wort "doch" im WORD-Text in Fettschrift erscheint. Betrachtet man die DOC-Datei nun mit dem Hex-Editor, dann stellt man folgendes fest:

• Die ersten 1536 Byte der Datei enthalten kaum druckbare Zeichen. Die meisten dieser Bytes haben den Wert FFh oder 00h.
  


• Ab dem Byte mit der Nummer 600h ( = 1536 [!!!]) steht eine ASCII-Darstellung unseres Textes, - interessanterweise ohne irgendeinen Hinweis auf die gewünschte Fett-Schrift des Wortes "doch". Die Informationen über die Formatierung müssen also woanders hinterlegt sein.
  


• Es folgt eine lange Serie von 00h-Bytes, gelegentlich unterbrochen durch einzelne Bytes mit anderen Werten.
  


• Ab dem Byte mit der Nummer 1200h ( = 4608 ) steht eine Byte-Folge, die eine Format-Beschreibung enthält. Für uns viel interessanter sind jedoch die anschließend aufgeführten Daten: es ist (in ASCII-Darstellung) der Name des Autors vermerkt, der Pfad zur Original-Datei sowie Daten über die Hardware-Ausstattung des Arbeitsplatzes, auf dem diese Datei erzeugt wurde. Speziell kann hier jeder nachlesen, was für einen Drucker der Autor hat!
  


• Der restliche Inhalt der Datei besteht zumeist aus langen Folgen von 00h- oder FFh-Bytes, unterbrochen von kurzen, informations-tragenden Byte-Sequenzen. Speziell wird die erste Zeile des Textes in ASCII-Darstellung mehrfach wiederholt, möglicherweise als Inhaltsangabe oder Kurzbeschreibung des Dokuments.
  

Natürlich ist das Format von DOC-Dateien für weit schwierigere Aufgaben vorbereitet als wir sie hier vorliegen haben. Es ist daher zu erwarten, dass viele der Abschnitte, die jetzt mit informationslosen Wiederholungen desselben Byte-Wertes angefüllt sind, bei einem komplexeren Dokument mit echten Informationen belegt werden. Bemerkenswert ist aber auch, dass WORD ohne unsere explizite Einwilligung recht eigenmächtig eine Menge zusätzlicher Daten in das Dokument packt.

Als weiteres Textformat untersuchen wir eine Beschreibungssprache für Postscript-Drucker. Hierbei wird eine Datei nicht in aufbereiteter Form (meist zur Ansteuerung im Grafikmodus) an den Drucker geschickt und von diesem direkt genutzt, sondern in einer Befehlsform, wie der beigefügte Text zu handhaben und auszugeben ist. Das hat den Vorteil, dass die druckerinternen Steuersequenzen nicht bekannt sein müssen. Allerdings muss der Drucker über ein Computerinteface verfügen, das die Befehle für den Drucker aufbereitet.

3. Aufgabe

• Lasse den Beispieltext "Beispiel.DOC" aus Word heraus mit einem Postscriptdrucker (Unter Druckereinstellung auswählen) in eine Datei "Beispiel" drucken.
  


• Die Datei erhält automatisch die Endung "PRN". Um festzuhalten, dass dies eine Postscript-Datei ist, benennen wir sie um in "Beispiel.PS".
  


• Überprüfe die Größe im Vergleich zur TXT- und DOC-Datei.
  


• Lade nun "Beispiel.ps" in den HEX-Editor. Interpretiere grob,was zu erkennen ist. Ist der Text irgendwo lesbar enthalten?

Wir erhalten die folgende Anzeige:

Wir stellen fest:

• Die Größe der Datei ist nur wenig kleiner als die DOC-Datei.
  


• Nach Dateibezeichnung, Datum etc. kommen eine große Anzahl Anweisungen zur Formatierung.
  


• Der Text steht erst gegen Ende (ab etwa Byte 2BE0h = 11232), wobei fast jedes Zeichen einzeln in Klammern aufgeführt ist und durch Anweisungen formatiert wird. Offensichtlich wird auch hier der schon bekannte ASCII-Code verwendet, da Hex-Edit die Bytes ja damit interpretiert:
  






• Der Fettdruck von "doch" wird nun direkt markiert, wobei vorher ein "Bold"-Font eingebunden wird.
  


• Zeichen außerhalb des 7-Bit-ASCII-Codes werden anders kodiert. Z.B. ä mit "\344".
  


• Der Text endet schließlich kurz vor dem Dateiende.
  

Dieses Format (Portable Document Format) ist ebenfalls eine Beschreibungssprache und kann von einem Interpreterprogramm (z.B. Acrobat-Reader) in eine Bilddarstellung umgesetzt werden, die dem entsprechenden Ausdruck gleicht.

4. Aufgabe

• Vergleiche die Dateigröße von "Beispiel.PDF" mit den anderen Formaten
• Lade die Datei "Beispiel.pdf" in den Hex-Editor udn suche den Text.

Wir erhalten die folgende Anzeige:

Wir stellen fest:

• Die Datei ist nur etwa halb so groß, wie die DOC-Datei aber deutlich größer als die TXT-Datei.
  


• Der Aufbau ist der PS-Datei ähnlich, wobei der Text gleich am Anfang steht.
  


• Auch in diesem Fall sind vor dem "doch" einige zusätzliche Zahlenfolgen eingefügt, die wohl die geänderte Formatierung angeben.
  


• Das "ä" wird mit E4h kodiert, wie das schon beim TXT-Format der Fall war.
  


• Am Ende stehen nur wenige zusätzliche Daten, unter anderem das Erstelldatum.
  

Ein Textformat, bei dem der Benutzer eine sehr viel bessere Kontrolle über den Inhalt seiner Dokument-Dateien haben kann, ist das HTML-Format (Hyper Text MarkUp Language). Dies ist derzeit das Standard-Format für Internet-Seiten.

Die Datei "Beispiel.html" enthält eine HTML-Version unseres kurzen Beispiel-Textes. Diese Datei ist zwar größer als die TXT-Datei, aber deutlich kleiner als die DOC-Datei. Wir laden "Beispiel.html" in den Hex-Editor und erhalten die folgende Anzeige:

Wir stellen fest:

• Die Datei ist nur geringfügig größer als die TXT-Datei.
  


• Die Datei enthält fast nur druckbare ASCII-Zeichen. Die einzige Ausnahme ist die Bytefolge 0Dh 0Ah, die schon früher als ASCII-Kodierung für harte Umbrüche erkannt wurde.
  


• Zeichen, die nicht im 7-Bit-ASCII-Code vorkommen, werden durch spezielle ASCII-Zeichen-Folgen dargestellt, z.B. das "ä" durch "ä".
  


• Auffällig ist die häufige Verwendung der Zeichen "<" und ">". Sie kommen stets paarweise vor und umschließen Zeichenfolgen, die nicht in unserem Text vorkommen. Daraus kann man schließen, dass es sich hierbei um Steueranweisungen oder Kommentare handelt.
  


• Auch in dieser Datei finden wir einen Hinweis auf den Autor sowie den Namen des Programms, mit dem diese Datei erstellt wurde.
  

Insgesamt erweist sich also eine HTML-Datei als eine "normale" Text-Datei, die demnach auch mit einem gewöhnlichen ASCII-Editor erzeugt und bearbeitet werden kann. Der Benutzer hat damit die totale Kontrolle über den Inhalt der Datei: wer z.B. seinen Namen nicht nennen mag, der braucht das nicht zu tun. (Es ist jedoch guter Stil, dass man in jede für die Veröffentlichung bestimmte Datei einen Vermerk über den Autor hineinschreibt.)

Wenn der Benutzer jedoch eine HTML-Datei mit einem ASCII-Editor erzeugt, dann ist er auch selbst dafür verantwortlich, dass sie syntaktisch korrekt ist, d.h. dass alle darin enthaltenen Steueranweisungen "richtig geschrieben" sind. Nur dann kann ein Browser sie verstehen und ausführen, wenn er den Text darstellen soll.
Dazu muß der Autor "HTML können", also z.B. wissen, mit welcher Folge von ASCII-Zeichen man Fettdruck ein- und ausschaltet, eine bestimmte Schriftgröße einstellt oder eine Textzeile zentriert.
Natürlich gibt es für diese Aufgaben auch spezielle Editor-Programme. Z.B. kann auch WORD HTML-Dokumente erzeugen. Allerdings weiß der Benutzer in diesem Fall wieder nicht, was dann alles in der Datei enthalten ist. Zumindest aber kann er es nachträglich kontrollieren, indem er die erzeugte HTML-Datei in einen ASCII-Editor lädt.

1. Eine Datei enthält die folgenden Bytes:

   57 65 6E 6E 20 53 69 65 20 6F 72 64 65 6E 74 6C
   69 63 68 20 75 65 62 65 6E 2C 20 6B 6F 65 6E 6E
   65 6E 20 53 69 65 0D 0A 76 6F 6E 20 42 65 72 75
   66 20 41 53 43 49 49 2D 45 64 69 74 6F 72 20 77
   65 72 64 65 6E 2E 20
   

   Stelle mit "HexEdit" eine solche Datei her, speichere sie unter dem Namen "Geheim.txt" ab und ermittle ihren Inhalt. (Beachte, dass "HexEdit" zwischen Einfüge- und Überschreib-Modus unterscheidet.)
   


2. Rufe die "Zeichentabelle" von Windows auf. Ein Vergleich mit der obigen ASCII-Tabelle zeigt, wie die Zeichen in ihr angeordnet sind. Die "Zeichentabelle" enthält aber zusätzlich noch Zeichen mit Nummern oberhalb von 127. Ermittle die Bytewerte, mit denen die deutschen Sonderzeichen dargestellt werden. Stelle dann mit "HexEdit" eine zweite Version "Geheim2.txt" her, in der echte deutsche Sonderzeichen verwendet werden, wo immer das nötig ist.
   Lade die geänderte Datei zur Kontrolle in den (Windows-Text-)"Editor".
   

[Index]

Autor: Roland Mechling
Überarbeitet: Jürgen Dehmer
Letzte Änderung: 18. November 2001