wunderlicher 500er Fehler - bereits gelöst

[Der Martin]

Hallo,

--- ist an sich mal 'ne feine Idee: mit MSWord als Editor zu programmieren... *ggg*

naja, dann kannste dir dein Syntax-Hilighting mit statischer Formatierung selbst machen. ;-)

Ich habe jetzt die beiden Versionen des Scripts abgespeichert:

• die DOS-Version hat 73 Bytes

Zeilenumbrüche CR/LF (0x0D, 0x0A).
Interessant: Wenn ich das Beispielscript aus deinem Originalposting im DOS/Windows-Format speichere, bekomme ich eine Datei mit 75 Bytes (3 Zeilen mit 18, 36 und 15 Nutzzeichen, 3 Zeilenenden à 2 Byte). Oder hast du das CR/LF der letzten Zeile weggelassen? - Dann käme ich auch auf 73.

• die MAC-Version hat 71 Bytes

Zeilenumbrüche nur CR (0x0D).
Damit komme ich auf 72 Zeichen (oder 71 wie du, wenn ich das CR der letzten Zeile weglasse).

• die MS-Word-Version bringt es aus dem Stand auf 24.064 Bytes...

Na klar. Word speichert ja auch die komplette Formatierung und einen Haufen von Metainformationen.

Ich war aus früheren C-64-Assembler und Maschinensprache-Tagen bisher fest davon ausgegangen, daß ein Texteditor keine Randnotizen geheim hält, sondern ALLE Zeichen anzeigt.

Nein, das ist nicht üblich.
Steuerzeichen, die im Editor eine definierte Funktion haben (Zeilenumbruch, Tabulator), werden interpretiert und normalerweise nicht nochmal sichtbar dargestellt; andere Steuerzeichen werden je nach Editor als Symbole, als Esc-Sequenzen, als Hexcodes oder auch gar nicht angezeigt.

So wie die Datei aufgebaut ist, egal was für Zeichen: Sonderzeichen, Steuerzeichen; jedes Byte wird angezeigt.

Das ist nur bei einem Hex-Editor so. Der zeigt dir wirklich Byte für Byte an, ohne den Dateiinhalt jedoch zu interpretieren.

Die 2 Bytes (BOM?), die die DOS-Version mehr hat, zeigt mir mein Editor nicht an.

Erstens: Die BOM hat 3 Byte, und die spielt hier keine Rolle; die gibt's auch nur bei UTF-Codierungen. Der Unterschied entsteht hier wirklich nur durch die unterschiedliche Repräsentation des Zeilenumbruchs.

Ciao,
 Martin