beatovich: linefeed Überraschung

Beitrag lesen

hallo

Den vom Browser erhaltenen String einfach binär in eine Datei zu schreiben, ist jedenfalls FALSCH.

Also der String kommt aus dem HTTP Kontext und da haben wir immer \r\n zu erwarten.

Es spricht eigentlich nichts dagegen solche Daten auch etsprechend zu speichern.

Das konnte mit einer einfachen Angabe gelöst werden

open(my $fh, ">:raw", $data)...

Solange man weiss, was (aus welchem Kontext) man letztlich speichert, muss man die Betriebsspezifischen Zeilenden nicht mal respektieren.

Textdateien sind plattformabhängig. Perl möchte ein plattformneutrales Textdatei-API anbieten - was sinnvoll ist.

Plattform-neutral ist wohl nicht der korrekte Ausdruck dafür. Dazu müsste Perl ja seine eigene Plattform darstellen.

Diese Schicht wird durch binäres Schreiben umgangen. Will man das Script mal eben so auf einen Unix-basierenden Server übertragen, dann hat man auf einmal unerwünschte Umbrüche im Text.

Sobald man einen über HTTP gespeicherten Inhalt über andere Methode als HTTP ausliefert, dann ja. Anderseits heisst ja übertragen Dass eine Textdatei erst mal in die Plattform HTTP übersetzt wird.

Was mich aber wundert, ist eben dieses Verhalten, dass \r\n beim unmodifizierten Schreiben zu einem \r\r\n wird. Mit dem CGI Modul hat das nichts zu tun. Ich kann mir das nur so erklären, dass der dafür verantortliche Prozess ein simples s{\n}{\r\n}g vollführt, ohne weiter zu fragen. Das halte ich nicht für korrekt.