Seit wann kann nl2br() auch mac \r

[Janus]

Hi,
bisher dachte ich immer nl2br() könnte nur \r\n und \n
in <br /> umwandeln.

Siehe auch:
http://www.php-faq.de/q/q-string-html-umbruch.html

Im Php-Manual gibts bei den Kommentaren deshalb sogar eine
modifizierte Funktion, die auch die macs \r berücksichtigt.

http://de3.php.net/manual/en/function.nl2br.php#73440

Da dieser Kommentar erst vom: 23-Feb-2007 01:12  ist, wundert
mich, dass bei einem Versuch nl2br sehr wohl mac \r erkennt und umwandelt. Weiss Jemand was Genaues dazu?

Test:
$str ="hallo jetzt mac \r 1\r2\r3\r   \r\n  Jetzt unix \n 1\n 2\n 3\n \r\n jetzt windows \r\n1\r\n2\r\n3\r\n";

echo nl2br($str);

Janus

[rob]

Hi!

Da dieser Kommentar erst vom: 23-Feb-2007 01:12  ist, wundert

mich, dass bei einem Versuch nl2br sehr wohl mac \r erkennt und umwandelt.
Ich bin der Meinung, daß \r nicht erkannt wurde, als ich das das letzte Mal versucht hab.
Außerdem werden die Zeilenumbrüche gar nicht wirklich umgewandelt, sondern nur ein <br/> eingefügt. Die eigentlichen Zeilenumbrüche bleiben bestehen. Das <br/> wird nur davor eingefügt.

Und außerdem ist es nicht korrekt, wenn man sagt, beim Mac wäre der Zeilenumbruch ein \r.
Das war mal so - auf dem alten Mac OS.
Mittlerweile sind wir aber bei OS X, welches auf einem BSD-System aufbaut (also Unix) und da kommt nun auch \n als Zeilenumbruch zum Einsatz.
(Die meisten Mac-Editoren kennen beide Varianten und man kann es in den Optionen wählen.)
Naja und wenn man mit einem Mac arbeitet und dann seine Files per FTP auf einen Webserver lädt, überträgt man die Dateien normalerweise im ASCII-Mode, wo die Zeilenenden ohnehin konvertiert werden...

Schöner Gruß,
rob

[Janus]

Hi Rob,
du meinst das wäre nicht so?

Na wofür lege ich dann extra ein Beispiel bei, wenn
du es doch nicht probierst und deine Meinung als "Absolut" ansiehst.

Auch deine Argumente bezüglich FTP /Ascii usw.

Das war nicht meine Gegenstand meiner Frage.
Wenn es dich interessiert gehts hier eher um Formluareingaben,
die codiert abgespeichert werden, und wer da einen alten Mac nutzt,
der nutzt auch \r.

Janus

[Tom]

Hello,

Und außerdem ist es nicht korrekt, wenn man sagt, beim Mac wäre der Zeilenumbruch ein \r.
Das war mal so - auf dem alten Mac OS.

Ab Version 10.0 ist es auch "\r\n" oder ist es jetzt "\n"?

Außerdem hat der MAC-Browser mWn schon immer CRLF gelesen und produziert.
Das Format von HTML-Dokumenten hat ja nicht unbedingt etwas mit dem Format "normaler" Dateien zu tun.

Ist hier noch jemand mit einem alten MAC-OS, der mal probehalber etwas per action=POST versenden könnte?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[rob]

Hi!

Ab Version 10.0 ist es auch "\r\n" oder ist es jetzt "\n"?

Bei OS X ist es wie bei jedem Unixsystem \n.

Der Zeilenumbruch beim alten Mac OS ist \r.

Was allerdings ein Browser wie der IE auf OS 9 macht, wenn man was per POST verschickt, weiß ich nicht.

Ist hier noch jemand mit einem alten MAC-OS, der mal probehalber etwas per action=POST versenden könnte?

Nein. Momentan leider nicht. Aber ich könnte das in den nächsten Tagen mal probieren.

Schöner Gruß,
rob

[Tom]

Hello,

Ist hier noch jemand mit einem alten MAC-OS, der mal probehalber etwas per action=POST versenden könnte?
Nein. Momentan leider nicht. Aber ich könnte das in den nächsten Tagen mal probieren.

Nach Spezifikation müsste es "\r\n" sein, was da versendet wird.

Wenn man beim IE auf WinDOS eine Textarea im Affenformular betreibt, und reduziert das "\r\n" auf "\r" oder "\n", ergänzt der IE es jedesmal wieder auf "r\n".

Auf MAC müsste das genauso sein.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[rob]

Hi!

Auf MAC müsste das genauso sein.

Das könnte sein. Das muß aber nicht sein. Der Mac-MSIE ist eine andere Software als die Windows-Version und nicht nur einfach eine Portierung.
Der Mac-IE verhält sich in vielen Bereichen anders als die Win-Version und hält sich auf Mac OS sogar mehr an bestehende Standards.

Ich werde das die nächsten Tage zur Sicherheit einfach mal testen und poste dann die Ergebnisse.

Schöner Gruß,
rob

[Tom]

Hello,

Das könnte sein. Das muß aber nicht sein. Der Mac-MSIE ist eine andere Software als die Windows-Version und nicht nur einfach eine Portierung.

Das muss so sein, weil die RFC es so "vorschreibt".
Wenn es ein Browser auf MAC nicht so macht, verhält er sich falsch.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[rob]

Hi!

Das muss so sein, weil die RFC es so "vorschreibt".

Ja, aber du weißt ja selbst, wie genau die M$-Programmierer sich an Standards halten...
Ich vermute a auch mal, daß da kein \r gesendet wird. Aber wie gesagt: zur Sicherheit werde ich das mal mit verschiedenen Browsern auf OS 9 testen.

Ich mußte eine Zeit lang mit dem Mac arbeiten. Mit OS X hatte ich keine Probleme (auch wenn ich persönlich das System eigentlich nicht mag).
Aber ich weiß, daß es einige Male Probleme mit Zeilenumbrüchen auf OS 9 gab.
Das ist allerdings schon so lange her, daß ich nicht mehr weiß, was da los war. Ich kann mich nur noch erinnern, daß es irgendwelche Probleme mit den Umbrüchen gab und daß ich CGI-Scripte deswegen ändern mußte.

Ich werde irgendwann in der nächsten Woche die Möglichkeit haben, mich vor 'ne OS-9-Kiste zu setzen. Dann werde ich mal ein paar Versuche machen.
Wenn es sonst noch was gibt, was ich auf OS 9 testen soll, mußt du Bescheid geben.

Schöner Gruß,
rob

[Tom]

Hello,

Das muss so sein, weil die RFC es so "vorschreibt".
Ja, aber du weißt ja selbst, wie genau die M$-Programmierer sich an Standards halten...
Ich vermute a auch mal, daß da kein \r gesendet wird.

Nein, da wird ein CRLF --> 0D 0A also quasi "\r\n" gesendet.

Und das gehört laut RFC auch dort hinein!

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Janus]

Hi Rob,

Außerdem werden die Zeilenumbrüche gar nicht wirklich umgewandelt, sondern nur ein <br/> eingefügt. Die eigentlichen Zeilenumbrüche bleiben bestehen. Das <br/> wird nur davor eingefügt.

Das was du hier schreibst, habe ich nochmal getestet.

Soweit ich das sehe wird doch umgewandelt, allerdings
nur unix \n.

Das bedeutet Zeilenumbrüche bleiben in der Tat stehen,
allerdings nur als mac \r

Interessant dabei war festzustellen, dass der IE diese
automatisch wieder in \r\n im Quelltext umstellt.
Somit ließ sich der Quelltext problemlos speichern.

Aber wie gesagt, im Script sieht das ganz anders aus,
das macht sich dann schmerzhaft bemerkbar beim Speichern.

Also korregiere mich, falls ich mich irre:

Bei nl2br() werden alle \n zu <br /> "umgewandelt".
Bestehen die Zeilenumbrüche aus \r\n bleibt somit \r übrig.

Janus

[Mathias Brodala]

Hallo Janus.

Also korregiere mich, falls ich mich irre:

Bei nl2br() werden alle \n zu <br /> "umgewandelt".

Nein, allen LF (\n) wird die Zeichenkette „<br />“ vorangestellt.

Bestehen die Zeilenumbrüche aus \r\n bleibt somit \r übrig.

Nein, auch hier bleibt \r\n bestehen; nur wird die genannte Zeichenkette hier vor das CR (\r) gesetzt.

Einen schönen Montag noch.

Gruß, Mathias

[Janus]

Hi Mathias,

jo Ihr habt wohl recht.
Das Ganze hängt zusammen, weil ich nl2br und highlight_string
in einer neuen Funktion nutze.

Und bisher dachte ich der Übeltäter wäre nl2br(), aber es
ist definitiv highlight_string. Da kommen Sachen raus die
gibts nicht.

Also danke an alle.

Code zum testen:

  
<?php  
$str ="windows \r\n 1 \r\n 2 \r\n 3 \r\n";  
  
echo "<h1>Normal</h1>";  
echo '<br>Soviele Windows Zeilenumbrüche \r\n :'.substr_count($str, "\r\n");  
echo '<br>Soviele UNIX Zeilenumbrüche \n :'.substr_count($str, "\n");  
echo '<br>Soviele MAC Zeilenumbrüche \r :'.substr_count($str, "\r");  
  
echo "<h1>nl2br</h1>";  
$str2 = nl2br($str);  
echo '<br>Soviele Windows Zeilenumbrüche \r\n :'.substr_count($str2, "\r\n");  
echo '<br>Soviele UNIX Zeilenumbrüche \n :'.substr_count($str2, "\n");  
echo '<br>Soviele MAC Zeilenumbrüche \r :'.substr_count($str2, "\r");  
  
echo "<h1>highlight_string</h1>";  
$str3 = highlight_string($str,1);  
echo '<br>Soviele Windows Zeilenumbrüche \r\n :'.substr_count($str3, "\r\n");  
echo '<br>Soviele UNIX Zeilenumbrüche \n :'.substr_count($str3, "\n");  
echo '<br>Soviele MAC Zeilenumbrüche \r :'.substr_count($str3, "\r");  
  
 exit();  
  
?>  
Das Ergebnis ist:  
  
Normal  
Soviele Windows Zeilenumbrüche \r\n :4  
Soviele UNIX Zeilenumbrüche \n :4  
Soviele MAC Zeilenumbrüche \r :4  
  
  
nl2br  
Soviele Windows Zeilenumbrüche \r\n :4  
Soviele UNIX Zeilenumbrüche \n :4  
Soviele MAC Zeilenumbrüche \r :4  
  
  
highlight_string  
Soviele Windows Zeilenumbrüche \r\n :0  
Soviele UNIX Zeilenumbrüche \n :2  
Soviele MAC Zeilenumbrüche \r :4  

Gruss
Janus

[Tom]

Hello,

highlight_string
Soviele Windows Zeilenumbrüche \r\n :0
Soviele UNIX Zeilenumbrüche \n :2
Soviele MAC Zeilenumbrüche \r :4

Wie geht denn das?
Das muss ich mir im Hex-Editor ansehen.

Ergebnis:

in der Standardeinstellung von PHP ersetzt highlight_file() nur die "\n" also 0A gegen "<br />"
Die 0D also "\r" bleiben vollkommen unbeachtet, also auch im Ausgabetext erhalten. Für sie wird auch kein "<br />" eingefügt.

Teste mit der Einstellung

ini_set('auto_detect_line_endings',1);

Das macht keinen Unterschied.
Hat laut Manual ja auch nur Einfluss auf file() und fgets()

http://www.php.net/manual/en/ref.filesystem.php#ini.auto-detect-line-endings

auto_detect_line_endings boolean
When turned on, PHP will examine the data read by fgets() and file() to see if it is using Unix, MS-Dos or Macintosh line-ending conventions.

This enables PHP to interoperate with Macintosh systems, but defaults to Off, as there is a very small performance penalty when detecting the EOL conventions for the first line, and also because people using carriage-returns as item separators under Unix systems would experience non-backwards-compatible behaviour.

Note: This configuration option was introduced in PHP 4.3.0

Ich hoffe, alle Klarheiten sind nun wiederhergestellt

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Janus]

Hi Tom,

in der Standardeinstellung von PHP ersetzt highlight_file() nur die "\n" also 0A gegen "<br />"
Die 0D also "\r" bleiben vollkommen unbeachtet, also auch im Ausgabetext erhalten. Für sie wird auch kein "<br />" eingefügt.

Ich hoffe, alle Klarheiten sind nun wiederhergestellt

Nicht ganz.
Der String $str ="windows \r\n 1 \r\n 2 \r\n 3 \r\n";
wird also so umgewandelt, dass nur die \n ersetzt werden?

Ja das scheint so zu sein: Im Ergebnis 4 x \r bleiben übrig.

Aber wo kommen die 2 x \n dann noch her?

Denn der String selbst enthält ja keine physischen
Umbrüche sondern nur deklarierte. Können also auch nicht durch
PHP zeilenende Feststellungen entstehen.

Aber dann müssten doch lediglich 4 x \r übrig bleiben, aber keine \n.

Gruß
Janus

[Tom]

Hello,

in der Standardeinstellung von PHP ersetzt highlight_file() nur die "\n" also 0A gegen "<br />"
Die 0D also "\r" bleiben vollkommen unbeachtet, also auch im Ausgabetext erhalten. Für sie wird auch kein "<br />" eingefügt.

Nicht ganz.
Der String $str ="windows \r\n 1 \r\n 2 \r\n 3 \r\n";
wird also so umgewandelt, dass nur die \n ersetzt werden?

Sorry, ich habe mir higlight_file() angesehen.
Ich schau auch nochmal in highlight_string rein, wenn Du willst.

Bei Ausgabe in eine Variable machen beide das Gleiche.
Bei der Ausgabe an die Standard-Ausgabe ändert sich auch nichts.

Das Verhalten ist also ganz normal.
Es wird ausschließlich "\n" _ersetzt_ durch "<br />"

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom