Ich behaupte nicht das das was mit LotusScript zu tun hat.
Ich weiss nur, dass ich mir in der Vor-Eclipse-Code viele Java Source Dateien in Notepad angeschaut habe. Notepad versteht nur den Microsoft Standard Carriage Return Linefeed als Zeilenumbruch. Je nachdem wie die Dateien ursprünglich erstellt waren, sah man da auf Notepad manchmal einfach keine Zeilenumbrüche.
Deshalb bin ich ein Anhänger dieser Theorie:
http://www.oreilly.de/catalog/mcosxhksger/chapter/hack05.htmlZitat
Es gibt drei verschiedene Arten von Zeilenumbrüchen, die ursprünglich jeweils einem der großen Betriebssysteme zuzurechnen waren: Windows/DOS, Macintosh und Unix. Ein Dokument mit Mac-Zeilenumbrüchen sieht auf einem Windows-System grässlich aus, und ein Dokument mit Windows-Umbrüchen wird von Unix auch nicht korrekt interpretiert. Der Grund dafür besteht darin, wie der Zeilenumbruch erstellt wird. Der Mac bedient sich standardmäßig eines einfachen Carriage Returns (<CR>), dargestellt als \r. Unix hingegen verwendet einen einfachen Zeilenvorschub (<LF> für engl. line feed), dargestellt als \n. Windows geht einen Schritt weiter und verbindet beide (<CRLF>) zu der Kombination \r\n.
Das hat sich natürlich mittlerweile ziemlich relativiert, da z.B. ein Programm wie Textpad oder Wordpad (ist nicht Notepad) natürlich auch unix/linux und Mac-Zeilenumbrüche versteht.
ASCII ist für mich einfach ein Mapping von 2 ^7 in Binärform dargestellter positiver natürlicher Zahlen (?) auf bestimmte Zeichen. In Ascii ist aber nicht definiert, ob jetzt ein Zeilenumbruch durch carriage return, line feed oder beides dargestellt wird. Vielmehr haben aus meinen Verständnisse verschiedene Betriebssysteme unterschiedliche "Haus"-Standards.
Ascii ist
0000 1101 ist carriage return
0000 1010 ist line feed
Betriebssystemstandard (eine Abstraktionsebene dadrüber) ist
Zeilenumbruch heisst:
carriage return + line feed (Windows)
carriage return (Mac)
line feed (linux/unix)
Das Programme wie TextPad, Wordpad, Eclipse, Notes auf Windows auch die Hausstandards von Mac und Linux/Unix mitunterstützen ist für mich ein Zugeständnis an Interoperabilität von Betriebssystemen.
Durch die zunehmende Verbreitung von unicode und xml/webservices tauchen in diesem Kontext auch aktuell immer wieder Fragen auf. Da spielt das encoding nämlich eine Rolle. Ich bin da manchmal auch am grübeln, hab das aber im Griff.
Wenn du dir ein txt file im Hex-Editor anschaust, da steht dort meines Wissens nirgendwo, ob dies im ASCII Standard, ISO-8859-1, UTF-8 oder in Unicode 4.0 encodiert ist. In UTF-8 sind manche Zeichen 16 bit, andere 8 bit. ASCII ist 7bit, ISO-8859-1 ist 8 bit, UTF-8 ist manchmal 8, manchmal 16 bit. Unicode 4.0 ist manchmal 16 bit, manchmal 32 bit.
Auf einer tiefen technischen Ebene enthalten ja Dateien rein nur binäre Zeichenfolgen. Die Programme, die txt-Dateien darstellen, machen eine reine Annahme, mit welchem Zeichensatz-Mapping die binäre Zeichenkette als characters angezeigt wird.
In xml steht aber z.B. das encoding direkt in dem xml declaration Element.
<?xml encoding="ISO-8859-1"?>
<root>
<element>value</element>
</root>
Manchmal haben Leute Probleme, wenn sie nicht die korrekte Vorstellung von Text-Dateien als binäre Zeichenfolgeketten. Die als korrekt (oder inkorrekt) empfundene Anzeige in Zeichen hängt dann rein von diesen impliziten oder expliziten byte -> character Mapping-Tabellen-Standards ab.
Axel
