Hallo pl,
Es sorgt dafür, dass am IO Layer von Character- auf Byte-Semantic umgeschaltet wird.
Ach! Sieh an. Ist ja nicht so als hätte ich nicht genau das gesagt ;-)
Sicher gabs auch in Perl wesentliche Änderungen, bsp. ist mit 5.8 Encode in den Core gekommen und die Unicode-Unterstützung wird ständig verbessert.
Ja. Eine begrüssenswerte Entwicklung.
Aber IO (Sockets, Dateihandle, STDIN, STDOUT...) war schon immer Byte-Semantic und auf diesem Level gibt es keine Kodierung.
Das stimmt nicht (mehr). Klar, vor 10 Jahren hattest du recht. Heute nicht.
So gibt ein print "äöü" nicht etwa Zeichen aus sondern Bytes und zwar genauso, wie sie in derselben Datei gespeichert sind.
Das ist abhängig von der Implementation von print
. In C hast du recht, in Ruby und Perl nicht (mehr), denn da gibt es das Output Processing.
Ob das Bytes für UTF-8 sind oder ISO/ANSI-irgendwas ist dem Perl-Interpreter [… völlig Wurscht.]
Nein. Es kann ihm egal sein, es ist aber nicht zwangsläufig der Fall. Versuch mal etwa chinesische Schriftzeichen in eine Datei zu schreiben, die mit Latin1 geöffnet wurde:
→ ckruse@sunshine ~ % cat test.pl
#!/usr/bin/perl -w
use utf8;
open(my $fh, ">:encoding(ISO-8859-1)", "fasel.txt") || die("Could not open fasel.txt: $!");
print $fh "象形字";
close($fh);
# eof
→ ckruse@sunshine ~ % perl test.pl
"\x{8c61}" does not map to iso-8859-1 at test.pl line 7.
"\x{5f62}" does not map to iso-8859-1 at test.pl line 7.
"\x{5b57}" does not map to iso-8859-1 at test.pl line 7.
→ ckruse@sunshine ~ % cat fasel.txt
\x{8c61}\x{5f62}\x{5b57}
Beachte, dass in der Datei tatsächlich die Escape-Sequenzen stehen.
oder einem c-Compiler völlig Wurscht.
Dem C-Compiler ist es in der Tat völlig wurscht, denn der hat kein eingebautes Unicode-Handling.
LG,
CK