Soviel ich weiss ist der Standardzeilenumbruch in Windows
Chr$(13) + Chr$(10)
auf unix und linux:
Chr$(10)
http://www.oreilly.de/catalog/mcosxhksger/chapter/hack05.html
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.
Viele Windowsprogramme verstehen aber heutzutage auch chr$(10) -> z.B. Lotus Notes.
Windows Notepad meines wissens nicht. Wordpad aber schon.
\r -> 13 (CR)
\n -> 10 (LF)
public class Test {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
String test = "\r\n";
char[] someChars = test.toCharArray();
for (int i=0; i<someChars.length; i++) {
System.out.println((long)someChars[i]);
}
}
}
13
10
Hi Axel,
ich habe eben einer meiner Standardroutinen (man verwendet die ja - leider - irgendwann dann doch ohne weiteres Nachdenken) nochmal geprüft. Die Routine soll in bestimmten und hierfür relevanten Textfeldern die Eingabe einer Zeilenschaltung verhindern (Aufruf der Routine im Querysave, der Ausschnitt stammt aus einer Function namens ValidateMandatoryFields - der Function-Name sagt sicherlich alles):
'In the following fields carriage returns are not allowed:
For iLoop = 0 To Ubound (aNoCR)
szTemp = uidocCurrent.FieldGetText (aNoCR (iLoop))
If Instr (szTemp, Chr$ (10)) > 0 Or Instr (szTemp, Chr$ (13)) > 0 Then
Messagebox "Im Feld '" & aNoCR (iLoop) & "' sind keine Zeilenschaltungen erlaubt !", MB_ICONEXCLAMATION, "Eingabefehler"
Call uidocCurrent.GotoField (aNoCR (iLoop))
Exit Function
End If
Next
Egal, ob ich in der betreffenden Zeile jetzt den Check auf 10D oder 13D auskommentiere - die Prüfung schlägt immer zu.
Ich muss nochmal nachvollziehen, wie Notes in den einzelnen Situationen die Werte verwendet: In LS reicht für einen Zeilenumbrauch (auch in einem RTI) immer 10D, aber ich bin mir sicher, bei @functions braucht es statt dessen irgendwo ein 13D (@Prompt ?). Die Eingabe im FrontEnd erzeugt aber offensichtlich beide Werte (was ja auch "ASCII-mässig" korrekt wäre (LF + CR).
(Wirklich) Übel, dass irgendwann die Routine dazu führt, dass man nicht mehr genau weiss, wie es denn nun genau funktioniert ...
Bernhard
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.html
Zitat
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.
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. ;D
Axel