nicht angemeldet
Halihallo Christian
Ach herje, mein Fehler. Ich hab's vorhin (doch) gerade ausprobiert.
Bei meinem Test lag es nicht am Flag 'b', sondern an dem Einlesen
von Perl, welches CRLF automatisch wieder in LF umgewandelt hat...
Das hat mir den Irrglauben aufgebunden, dass PHP \n automatisch mit
LF kodiert (obwohl ich eigentlich hätte merken müssen, dass es
eigentlich CR sein sollte, wenn man der Login von "\n\r" folgt)...
Stopp... Ich hab's doch in Perl mit binmode() eingelesen, Perl sollte
also jedes Byte genauso lassen, wie es ist.
test.php: (schreiben)
<?php
$fh = fopen("test.txt", "w");
fwrite($fh,"\n");
fclose($fh);
?>
test.pl: (einlesen und ASCII-Dump)
open( F, '<./test.txt' );
binmode(F);
my $t = '';
while ( read(F,$t,1) ) {
print ord($t)."\n";
}
close(F);
Nach Aufruf von test.php habe ich auf einem Windows-Rechner eine
Datei test.txt liegen, die genau ein Byte(!) aufweist (nach
Explorer). Der Perl-ASCII-Dump zeigt auch nur ein Zeichen, nämlich:
10 (\012). Obwohl die Datei a) zwei Bytes haben sollte und b) der
ASCII-Dump auf 10 13 lauten sollte.
Kann es sein, dass ich den Wald grad vor lauter Bäumen nicht mehr
sehe, oder habe ich einfach ein Unixisches PHP auf einem Windows-
Rechner?
Die Schlussfolgerung ist doch richtig, dass mein PHP anscheinend \n
mit dem ASCII-Wert 10 füttert, obwohl es eigentlich "\015\012" in die
Datei schreiben sollte (logisches Newline für Windows-Systeme).
Falls nicht, würde a) Perl das physikalische Newline (CRLF) in das
logische, interne LF umwandeln und Explorer(!) würde dasselbe machen.
Nun, M$ traue ich zwar einiges zu, aber eine Datei hat nunmal eine
eindeutig definierte Byte-Grösse, unabhängig von logischen Newlines
(gezählt werden die physikalisch vorhandenen).
? :-)
Viele Grüsse
Philipp