Heiner Kücker

Codierung von Texten / Strings

Home

Java-Seite

Alaska-XBase++-Seite

Projekte

Philosophien
Techniken


Konzepte

   Artikelsystematik

   Semantisches_Netz

   Flexible_Columns

   Weiterentwicklung_Java

   Fehlerquellen

   Längencodierung

   Encoding

   Programming_by_Contract

   TimelineStructure
   Datenstruktur für
   Kalender oder
   Terminplaner

Sudoku

Kontakt /
Impressum


Links

SiteMap





Letzte Aktualisierung:
19.02.2004

Encoding

In Java kann man spezielle Zeichen (Meta-Zeichen) in String-Literalen durch Escape(Flucht)-Zeichen codieren.

  • \n - Zeilenumbruch
  • \t - Tabulator
  • \"e; - Apostoph
  • \\ - Backslash (dieses Encoding ist durch die obere Lösung notwendig geworden)
habe ich welche vergessen? Egal, Sie wissen was ich meine

Historie

Nach meinen ersten Gehversuchen mit dBase II (1987) lernte ich die Programmiersprache Turbo Pascal. In Turbo-Pascal wurden Strings durch einen Längenmerker am Anfang (ein Byte) und anschliessend den Inhalt des Strings im Speicher abgelegt.

Erst danach lernte ich das MS-DOS-API und die Programmiersprache C kennen.

Mit Schrecken musste ich feststellen, dass hier Strings ein Nullbyte/ als Ende-Kennzeichnung bekamen. Also konnte ein String niemals ein Null-Byte enthalten.(Nullcharacter, Null Character,Nullzeichen, Null Zeichen)

Mit dem professionellerem Arbeiten lernte ich Unix und seine Tools, die Shell und reguläre Ausdrücke kennen. Überall Encoding.

Dies zieht sich bis in moderne Technologien wie HTML und XML fort.

Alternative

Das oben beschriebene Verfahren nenne ich innenliegendes Encoding.

Bei den encodeten Zeichen handelt es sich um Zeichen, die im Text eine spezielle Bedeutung (Metazeichen) haben und deshalb nicht in einem Text dargestellt werden können.

Die von mir vorgeschlagene Alternative ist aussenliegendes Encoding.

Statt
abc\ndef
'abc'+newline+'def'

Statt
abc\"def
"abc"+quote+"def"

Die Metazeichen werden statt durch ein reserviertes Zeichen durch ein reserviertes Wort codiert. Die Lesbarkeit steigt erheblich an.

Erkennung encodeter Texte

noch nicht fertig

mehrfaches Encoding

noch nicht fertig

Beispiele

hierarchische Datenstrukturen

a {
  b {
    c1 = "a/b/c1";
    c2 = "a/b/c2";
  }
}
oder alternativ
begin a
  begin b
    c1 = "a/b/c1";
    c2 = "a/b/c2";
  end b
end a
statt
<a>
  <b>
    <c1>a/b/c1</c1>
    <c2>a/b/c2</c2>
  </b>
</a>

Kommandos

Auf der Shell und in Script-Sprachen werden oft Komandos wie
mv file1 file2
notiert.

Irgendwann hat man das Problem, dass statt der fest codierten Stringliterale variable Werte benötigt werden:

var1 := 'file1'
var2 := 'file2'
mv ${var1} ${var2}

Besser ist es, von vornherein String-Expressions für die Befehlsparameter vorzusehen:

mv( 'file1' , 'file2' )

a = 'file1'
mv( a , 'file2' )

reguläre Ausdrücke

noch nicht fertig

Protokolle

Hier tendiere ich zu den klassischen Header-Längen-Angaben vor binären Datenblöcken (eventuell mit Prüfsummen am Ende) statt der aus dem e-Mail-Bereich bekannten Multipart-Encodings.
Hier kommen noch die Vorteile einer besseren performance durch den Wegfall des Umwandelns und durch die Möglichkeit für das lesende Programm, den erfoderlichen Speicherplatz von vornherein zu reservieren hinzu.
Die aus dem C-Bereich bekannten Pufferüberläufe sind bei einem solchen Protokoll auch kein Problem mehr. Zu grosse Blöcke werden sofort erkannt.

Probleme

Bei Template-Technologien wie Java Server Pages oder dem Eclipse Modeling Framework (JET-Engine) würde umschliessendes Encoding zu weniger Übersichtlichkeit führen. Hier ist innenliegendes Encoding sinnvoll und dazu fällt mir auch keine Alternative ein.

Das jeweils günstigere Verfahren muss also von Fall zu Fall entschieden werden. Einflussnehmendes Kriterium ist scheinbar die Dominanz/Anzahl der zu encodenden Zeichen im Verhältnis zum Gesamtdokument.