LWP::UserAgent UTF-8-Mangling die 2991992ste (Fragen zu Perl-Modulen)

[thread]20519[/thread]

LWP::UserAgent UTF-8-Mangling die 2991992ste

Tags: perl5 Ähnliche Threads

Leser: 14

Articles: hide open all | hide show old branches

+25 replies
Gast Your_name

2018-10-23 14:29
Ich sitze an einem UTF-8-System, sage STDOUT und dem Interpreter, dass ich wirklich, nein, WIRKLICH UTF-8 in meinem Skript verwende:
Code (perl): (dl )

1 2 3 4 5 6

#!/usr/bin/perl use strict; use warnings; use utf8; binmode(STDOUT,':utf8'); print "Blahhhh, blah', blaaaÄÖÜäöüß!\n";
Dann rufe ich eine Funktion auf, die die Dämmlichkeit sämmtlicher Perl-Modulschreiber der Welt in einem eval-Block kapselt und mir stattdessen einen ordentlichen Error-Code plus einen HTTP-Response zurückliefert:
Code (perl): (dl )

1 2 3 4 5

my ($exit,$response) = &get_something ( $ua, $param );
"$ua->default_header('Accept-Encoding' => 'gzip');" setze ich manuell, und die Resource, die ich abfrage, ist in UTF-8. "decoded_content" verwende ich nicht, weil die Funktion viel zu fett und lahmarschig ist, Header durchgeht, Speicherallokationen macht und Haste nicht gesehen. Ich *weiß*, dass mir die Gegenseite entweder gar nix oder einen UTF-8-XML-String zurückliefern wird, der vorher vom Server gzipped wurde. Auf gar nix kann ich leicht prüfen, und sonst *müssen keine Header durchgegangen werden* - und daher sollte ich in der Lage sein, nach dem Empfangen des HTTP-Responses einfach das hier zu tun:
Code (perl): (dl )

1 2

gunzip \$response->content => \$content_decoded; $response->{_content} = \$content_decoded;
Und *trotzdem* halluziniert sich Perl irgendwo herbei, dass dieser UTF-8-String doch eigentlich ein ISO-8859-1-String ist, der nach UTF-8 konvertiert werden muss. Und daher bekomme ich hier auch die herrlichste Mojibake:
Code: (dl )

1 2 3 4

StraÃ<9f>e Ã¶ EmpfÃ¤nger Ã¼berweisen
Ein nachträgliches "decode('utf-8',$response->{_content})" fixt das zwar, und bei der Ausgabe (sowohl in Datei als auch Konsole, denen ich ':utf8' als binmode setze) fixt das auch - aber ahnt mal, *das ist hirnverbrannt*. Der Server sendet mir die Daten in UTF-8 zu, und das soll er auch! Das ist so gewollt! Ich habe hier eine Datenbank, die ich unter Schmerzen auf UTF-8 getrimmt habe, weil die MySQL-Spacken im Jahre 2018 nicht nur standardmässig latin1 für ihre Felder verwenden, sondern UTF-8 auch noch in einer kastrierten 3-Bytes-Max-Pro-Codepoint-Version ausliefern. Da würde ich gerne einfach meine UTF-8-Daten reinpacken, ohne Konvertierung! Hier braucht nie jemand irgendwas zu konvertieren!

Ach, und an der Stelle sollte ich auch sagen, dass es aber überhaupt mal gar keinen Unterschied macht, ob ich manuell den gzip-Header setze und dann über gunzip dekodiere, oder ob ich das einfach weglasse (vom einer Inflation des Payloads mal abgesehen). Selbst dann noch konvertiert mir LWP::UserAgent meinen wunderherrlichen UTF-8-String nochmal in UTF-8 um, weil's davon ausgeht, dass es doch ein ISO-8859-1-String ist.

Fragen:
1. Wie sage ich LWP::UserAgent, dass es den Scheiß lassen soll?
2. Wie sage ich IO::Uncompress::Gunzip, dass es den Scheiß lassen soll?

Disclaimer: ich komme aus der C-Ecke. Da konvertiert mir überhaupt gar keiner meine Strings, ohne dass ich das explizit ansage. Und genauso hätte ich das auch gerne in Perl.

modedit Editiert von GwenDragon: Justiziables in Codezeile 6 entfernt
Nochmals so was und du kannst dir woanders Hilfe suchen!

Last edited: 2018-10-23 16:27:33 +0200 (CEST)
- GwenDragon
  
  2018-10-23 16:25
  
  User since
  2005-01-17
  14542 Artikel
  Admin1
  
  Bei all deinem Ärger: um welches Perl und um welche Modul-Versionen handelt es sich denn?
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +17 replies
- rosti
  
  2018-10-23 16:28
  
  User since
  2011-03-19
  3199 Artikel
  BenutzerIn
  
  Mit binmode(STDOUT,':utf8'); teilst Du dem Layer mit, daß utf-8-kodierte Zeichenketten kommen. Pragma use utf8; hat auf die LWP Response überhaupt keinen Einfluß. Deine Response enthält zwar utf-8-Bytes, ist jedoch keine utf-8-kodierte Zeichenkette im Sinne von Perl.
  
  Lösung: Verzichte auf binmode(STDOUT,':utf8'); und auf use utf8;.
  
  MfG
  
  PS: Wenn die Response nicht gzipt werden soll, musst Du sie mit HTTP/1.0 anfordern, diese Version kennt noch keine Kompression.
  
  .
  Last edited: 2018-10-23 16:30:46 +0200 (CEST)
  - +16 replies
  - Gast Your_name
    
    2018-10-23 17:22
    Nee, nee, das ist es alles nicht. Ich habe inzwischen rausgefunden, was das Problem ist.
    
    Perl-Scalare haben ein internes Flag, welches angibt, ob es sich um einen UTF-8-String handelt oder nicht. gunzip kann nicht erkennen (und mal so gesagt: woher denn auch? Ich rufe die Funktion ohne Encoding-Kontext auf), dass es sich hier um einen UTF-8-String handelt und setzt das Flag halt nicht.
    
    Wenn ich dann "use utf8" verwendet habe, wurde der String (meiner Vermutung nach) bei Nutzung implizit nach UTF-8 promoted - was dann die Mojibake verursacht hat. Die Lösung: UTF-8-Flag setzen. Sagt dir sonst NIEMAND da draußen, außer, du suchst explizit nach "perl set utf8 flag scalar", und selbst dann nur im Kontext von "damit kannst du toll deine Scalare zerstören". Erstes Ergebnis ist dann:
    
    https://stackoverflow.com/questions/16467741/creat...
    
    , wo sie "_utf8_on" erwähnen. Genau das habe ich auf meinen String angewendet:
    
    Code (perl): (dl )
    
    _utf8_on(${$response->{_content}});
    
    Und was soll ich sagen? Die Mojibake ist verschwunden, ohne dass ich den String rückkonvertieren musste.
    
    @rosti: ? Gzip-Encoding ist noch optional in 1.1 meines Wissens und muss mit dem Accept-Encoding-Header verlangt werden. Wenn der Server das akzeptiert, sendet er einen Content-Encoding Header mit einem der vorgeschlagenen Kompressionsverfahren zurück.
    
    Und das hat ja auch überhaupt nichts mit dem eigentlichen Problem zu tun. LWP::UserAgent wie IO::Uncompress::Gunzip setzen beide das UTF-8-Flag nicht. Bei Gunzip kann ich's verstehen, bei UserAgent überhaupt nicht (wozu sendet jeder Server und sein kleiner Bruder denn heutzutage charset=UTF-8, wenn nicht, um zu signaliseren, dass es sich um UTF-8-Daten handelt?). Das Weglassen des Gzip-Headers diente zur Illustration, dass es *unabhängig* vom Modul auftritt.
    Last edited: 2018-10-23 17:25:53 +0200 (CEST)
    - +9 replies
    - GwenDragon
      
      2018-10-23 17:32
      
      User since
      2005-01-17
      14542 Artikel
      Admin1
      
      Nein, du interpetierts da was anders.
      Das utf8-Flag hat nix mit der Kodierung UTF-8 zu tun. Und man kann kein UTF-8-Flags setzen.
      
      Und use utf8 kodiert keine Strings um, auch nicht irgendwie hinterrücks. Es dient nur dazu dem Interpreter zu sagen, dass der Quellcode Unicode ist.
      
      Wozu Du _utf8_on brauchst, ist mir ein Rätsel. geht auch ohne wie mein Programm zeigte.
      Last edited: 2018-10-23 17:34:00 +0200 (CEST)
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
      - +8 replies
      - Gast Your_name
        
        2018-10-24 13:11
        
        GwenDragon
        Und man kann kein UTF-8-Flags setzen.
        
        Klaro. Deswegen bekomme ich auch keine Mojibake mehr in meine Dateien, die ich mit binmode(':utf8') setze, und in meine MySQL-Datenbank und und und ... also dafür, dass ich das nicht setzen kann, hat das bei mir gestern *w-u-n-d-e-r-b-a-r* funktioniert. Muss man halt nur wissen, dass Perl noch diese Altlasten aus ISO-8859-1 mit sich rumträgt.
        
        Man kann sogar das UTF-8-Flag abfragen, mit is_utf8. Das macht dann keine Prüfung, ob das Ding auch wirklich UTF-8-kompatibel ist, sondern fragt nur das laut deiner Aussage unsetzbare UTF-8-Flag ab.
        
        Und ich habe mich gestern auch noch mal hingesetzt und an meiner eigenen Box angesehen. Was macht "use utf8"? Setzt das UTF-8-Flag. Aber `IO::Uncompress::Gunzip` verwendet "use bytes", cleared das Flag also wieder. Dann dekomprimiert gunzip meine Daten binär-orientiert, setzt aber das UTF-8-Flag nicht.
        
        GwenDragon
        Wozu Du _utf8_on brauchst, ist mir ein Rätsel. geht auch ohne wie mein Programm zeigte.
        
        Dein Programm arbeitet ja auch nicht mit den Daten.
        Wenn du den binmode für dein Filehandle setzt, dann nimmt Perl automatisch ":raw" als Layer an - sprich, konvertiert nix. Perl ist zeichenorientiert. Wenn das UTF-8-Flag nicht gesetzt ist, sieht es die Bytes in deinem Scalar einfach nur als Bytes an, und da du ":raw" als Layer angibst, konvertiert er nix. Und da es sich bei deinen Bytes *zufälligerweise* um UTF-8-Daten handelt, schreibt es dir binär und ohne Konvertierung Daten rein. Typischer Fall von "ich habe zwei Kodierungsbugs, die sich gegenseitig aufheben".
        
        Probier als Layer für dein Filehandle mal ':utf8' anzugeben. Das Ergebnis wird herrlichste Mojibake sein.
        Last edited: 2018-10-24 13:33:06 +0200 (CEST)
        
        +7 replies
        
        rosti
        
        2018-10-24 15:29
        
        User since
        2011-03-19
        3199 Artikel
        BenutzerIn
        
        Liest Du eigentlich was wir hier posten?
        
        Quote
        Probier als Layer für dein Filehandle mal ':utf8' anzugeben. Das Ergebnis wird herrlichste Mojibake sein.
        
        Hab ich doch geschrieben was passier: Genau das schaltet die interne Kodierung ab. Und wenn es eine Solche nicht gegeben hat, ist das Ergebnis natürlich unbrauchbar.
        
        use bytes schließlich stellt die Bytesemantic wieder her, Und selbstverständlich ist diese zwingend erforderlich wenn ein Code bytesemantisch arbeiten soll, was gzip, deflate usw. nämlich tun: Sie arbeiten mit Bytes und nicht mit Zeichen, bspw. ist die Anzahl der Bytes nicht gleich der Anzahl der Zeichen!
        
        Wenn $s, intern utf-8-kodiert, eine Zeichenkette ist, liefert length($s) die Anzahl der Zeichen. Wurde die Kodierung jedoch entfernt, liefert length($s) die Anzahl der Bytes.
        
        Sieh auch: http://rolfrost.de/jsbinstr.html
        
        Und ja das kann man alles lernen. Man muss es aber selber machen!
        
        MfG
        
        +6 replies
        
        Gast Your_name
        
        2018-10-24 16:10
        
        2018-10-24T13:29:03 rosti
        Liest Du eigentlich was wir hier posten?
        
        Du meinst "Lass das doch einfach mit UTF-8, Unicode ist schwer, lasst uns shoppen gehen!"?
        Tatsache ist, dass ich ordentlichen UTF-8-Support haben will.
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        #!/usr/bin/perl use strict; use warnings; my $x = lc('ẞ'); print "$x\n";
        
        Gibt "ẞ" aus.
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9
        
        #!/usr/bin/perl use strict; use warnings; use utf8; binmode(STDOUT,':utf8'); my $x = lc('ẞ'); print "$x\n";
        
        Gibt 'ß' aus. Deine "Lösung" ist also gequirrlte Katzenkacke und hat hier aber auch mal überhaupt gar nix zu suchen. Vergib mir also, wenn ich darauf nicht eingegangen bin.
        
        Ich empfehle dir, dich mal in Unicode-Support in Perl einzulernen, denn es gilt: kann man alles lernen, muss man aber selber machen. Für dich machen kann ich nicht.
        
        2018-10-24T13:29:03 rosti
        Hab ich doch geschrieben was passier: Genau das schaltet die interne Kodierung ab.
        
        ...
        
        Wir reden hier vom Binmode des Filehandles in Gwen's Beispiel, nicht vom Binmode von STDOUT. GwenDragon hat nicht als UTF-8 markierte UTF-8-Daten ohne Textencoding in eine Datei gepackt und dann gesagt: seht her, es funktioniert auch ohne!!1!
        
        Siehe https://stackoverflow.com/questions/6162484/why-do...
        
        tchrist
        Code that assumes it can open a text file without specifying the encoding is broken.
        
        Und genau das ist das Problem. "Ich habe hier einen Sack UTF-8-Daten bekommen, aber weder sage ich Perl, dass das UTF-8-Daten sind, noch sage ich dem I/O-Layer, dass es UTF-8-Daten sind. Ich lasse die Daten einfach binär und packe die in die Datei. Einfach so. Ohne Encoding. Und damit wirklich arbeiten kann ich zwar nicht, aber seht her: mein Programm funktioniert, und DAS ist es ja, was zählt" (nur tut's das halt nicht, was ich auch geschrieben hatte. Weil mit den Daten nicht gearbeitet wird.)
        
        So, und was *du* meinstest, war der Binmode von STDOUT. Warum es eine dämliche Idee ist, einfach die Augen zu verschließen und UTF-8-Support zu deaktivieren, habe ich bereits oben behandelt. Herrschaftszeiten aber auch.
        
        2018-10-24T13:29:03 rosti
        Und selbstverständlich ist diese zwingend erforderlich wenn ein Code bytesemantisch arbeiten soll, was gzip, deflate usw. nämlich tun: Sie arbeiten mit Bytes und nicht mit Zeichen, bspw. ist die Anzahl der Bytes nicht gleich der Anzahl der Zeichen!
        
        ... äh, ja. Nix anderes habe ich auch geschrieben:
        
        Your_name
        Aber `IO::Uncompress::Gunzip` verwendet "use bytes", cleared das Flag also wieder. Dann dekomprimiert gunzip meine Daten binär-orientiert, setzt aber das UTF-8-Flag nicht.
        
        Ich habe mich darüber auch nicht beschwert, im Gegenteil:
        
        Your_name
        gunzip kann nicht erkennen (und mal so gesagt: woher denn auch? Ich rufe die Funktion ohne Encoding-Kontext auf)
        
        Also, was wolltest du jetzt genau sagen?
        Last edited: 2018-10-25 08:27:25 +0200 (CEST)
        
        rosti
        
        2018-10-25 08:34
        
        User since
        2011-03-19
        3199 Artikel
        BenutzerIn
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        #!/usr/bin/perl use strict; use warnings; my $x = lc('ẞ'); print "$x\n";
        
        Ist ja schon falsch. Weil Du im Bytemode bist! Richtig wäre, lc() auf Zeichenketten anzuwenden.
        
        Weiß Du, Unwissenheit kann man niemanden zum Vorwurf machen. Aber wenn Dich das was wir hier zu diesem Thema reichlich gepostet haben nicht interessiert und wenn Du hier weiterhin nur rumtrollst, dann machen diesbezügliche Diskussionen einfach keinen Seinn.
        
        Schade.
        Last edited: 2018-10-25 10:02:00 +0200 (CEST)
        
        +4 replies
        
        haj
        
        2018-10-25 10:59
        
        User since
        2015-01-07
        529 Artikel
        BenutzerIn
        
        Guest Your_name
        Tatsache ist, dass ich ordentlichen UTF-8-Support haben will.
        Den liefert Perl, spätestens seit Version 5.18, hinreichend unfallfrei.
        
        Guest Your_name
        Ich empfehle dir, dich mal in Unicode-Support in Perl einzulernen, denn es gilt: kann man alles lernen, muss man aber selber machen. Für dich machen kann ich nicht.
        Das gilt für jeden, auch für Dich. Aus Deinem Ausgangstext:
        
        Guest Your_name
        "decoded_content" verwende ich nicht, weil die Funktion viel zu fett und lahmarschig ist, Header durchgeht, Speicherallokationen macht und Haste nicht gesehen.
        
        Wenn Du das Decoding nicht von LWP erledigen läßt, dann musst Du es selber machen.
        
        Somit kommen wir zum Ausgangspunkt der Fragen:
        
        Guest Your_name
        1. Wie sage ich LWP::UserAgent, dass es den Scheiß lassen soll?
        LWP::UserAgent macht keinen Scheiß, sondern liefert wahlweise die unbehandelte Bytewurst in $res->content oder den nach Transfer-Encoding und gegebenenfalls Text-Encoding ausgepackten Wert in $res->decoded_content.
        
        Guest Your_name
        2. Wie sage ich IO::Uncompress::Gunzip, dass es den Scheiß lassen soll?
        IO::Uncompress::Gunzip macht keinen Scheiß, sondern wandelt eine Bytewurst in eine andere Bytewurst um.
        
        Du hast in Deinem Code nicht mit den korrekten Mitteln deklariert, dass der Inhalt der Response nach dem Auspacken ein UTF-8-codierter String ist. Die Tatsache, dass Du weißt, dass da nur UTF-8-codierte Texte kommen können, heißt nicht, dass Perl das weiß.
        
        Es sollte inzwischen angekommen sein, dass use utf8; nicht das richtige ist, und vom UTF-8-Flag läßt man am besten die Finger. Das Mittel der Wahl dafür ist Encode::decode nach dem Dekomprimieren.
        
        Guest Your_name
        Disclaimer: ich komme aus der C-Ecke. Da konvertiert mir überhaupt gar keiner meine Strings, ohne dass ich das explizit ansage. Und genauso hätte ich das auch gerne in Perl.
        
        Perl konvertiert gar nichts ohne Ansage. Wenn Du mit UTF-8-codierten Daten arbeiten willst, die von externen Quellen kommen, dann musst Du das Encoding angeben:
        Tom Christiansen, erweiterte Version
        Code that assumes it can open a text file or retrieve data over the web without specifying the encoding is broken.
        
        +3 replies
        
        rosti
        
        2018-10-25 11:10
        
        User since
        2011-03-19
        3199 Artikel
        BenutzerIn
        
        Danke haj, Du meintest wahrscheinlich 5.8.1 was die Unicodeunterstützung betrifft. Diese Entwicklung ist bis heute in Bewegung. Wenn ich mich recht erinnere ist das Modul Encode seit v5.8 im Core.
        
        MfG
        
        +2 replies
        
        haj
        
        2018-10-25 11:49
        
        User since
        2015-01-07
        529 Artikel
        BenutzerIn
        
        Oh, ich meinte tatsächlich 5.18. Das mag gut und gern zu defensiv sein, aber zum einen ist die Version schon alt genug, dass sie sich in fast allen produktiven Umgebungen durchgesetzt haben sollte, zum anderen gab es davor immer wieder mal grenzwertige Situationen und Änderungen im Verhalten (z.B. User Defined Case Mappings, use feature 'unicode_strings', Behandlung bei pack/unpack) und doch auch einige unangenehme Bugs. Das meinte ich mit "hinreichend unfallfrei": Bei einer Codebase, die in 5.8.1 entstanden ist, musste man doch hin und wieder mal hinfassen, wenn eine neue Perl-Version eingesetzt werden sollte, während ich seit 5.18 das "in Bewegung" vor allem in der fortlaufenden Unterstützung neuer Unicode-Standards sehe.
        
        In der Änderungsbeschreibung zu Version 5.10 steht zum Beispiel:
        
        https://perldoc.perl.org/perl5100delta.html#UTF-8-problems
        The handling of Unicode still is unclean in several places, where it's dependent on whether a string is internally flagged as UTF-8. This will be made more consistent in perl 5.12, but that won't be possible without a certain amount of backwards incompatibility
        
        rosti
        
        2018-10-25 12:15
        
        User since
        2011-03-19
        3199 Artikel
        BenutzerIn
        
        Danke Dir!
        
        Nun, 5.6, 5.8 und 5.10 waren Meilensteine in der Entwicklung der Unicodeunterstützung. Und ich habe viele Jahre unter 5.6 entwickelt, da war sie bereits hinreichend.
        
        Von daher ja auch meine Empfehlung: Benutze die interne Zeichenkodierung nur dann, wenn das wirklich erforderlich ist.
        
        Im vorliegenden Fall ist sie nicht erforderlich. Sie ist nicht einmal in Sachen MySQL Anbindung erforderlich solange man auf jegliche Collationen verzichtet und keine Stringoperationen in MySQL durchführt.
        
        In MySQL Tabellen die mit Latin getagged sind lassen sich die Binaries UTF-8-kodierter Zeichenketten einwandfrei speichern und auch wiederherstellen, sie benötigen allenfalls mehr Platz.
        
        MfG
        
        PS: Binary in LATIN1 Table, UTF-8 funktioniert da natürlich auch:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
        
        use strict; use warnings; use dbh; use IO::File; my $dbh = (bless{},'main')->dbh('myweb'); $dbh->do(q( CREATE TABLE if not exists images( id int(32) auto_increment primary key, image text )CHARSET=Latin1 )); #print $dbh->selectrow_array('SHOW CREATE TABLE images'); # eine Grafik einlesen my $fh = IO::File->new; $fh->open('768.jpg', O_BINARY|O_RDONLY) or die $!; read($fh, my $image, -s $fh); $fh->close; # Grafik in MySQL Textfeld einfügen $dbh->do("INSERT INTO images(image)values(?)", {}, $image); # Grafik aus MySQL auslesen my $binary = $dbh->selectrow_array('SELECT image FROM images WHERE id = (SELECT LAST_INSERT_ID())'); # Grafik zur Kontrolle ausgeben $fh->open('new.jpg', O_CREAT|O_TRUNC|O_BINARY|O_RDWR) or die $!; $fh->print($binary); $fh->close; $dbh->do('drop table images');
        
        .
        Last edited: 2018-10-26 08:27:48 +0200 (CEST)
    - +5 replies
    - rosti
      
      2018-10-23 17:56
      
      User since
      2011-03-19
      3199 Artikel
      BenutzerIn
      
      Kompression und Zeichenkodierung, das ist Bullshit³!
      
      .
      Last edited: 2018-10-23 18:04:29 +0200 (CEST)
      - +4 replies
      - GwenDragon
        
        2018-10-23 18:05
        
        User since
        2005-01-17
        14542 Artikel
        Admin1
        
        Er kommt von C her, vielleicht machen die K&R-C++-Leute das ganz anders.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +3 replies
        
        rosti
        
        2018-10-23 18:41
        
        User since
        2011-03-19
        3199 Artikel
        BenutzerIn
        
        C ist per Default Byteorientiert. Perl auch. Und was viele gar nicht wissen:
        
        Code (perl): (dl )
        
        binmode(STDOUT,':utf8');
        
        schaltet die interne Kodierung nicht ein sondern aus, stellt also die Bytesemantic wieder her. Und wenn es keine interne Kodierung gab, kommt Müll dabei raus. Fazit: Bei der hier vorgestellten Aufgabe ist eine interne Kodierung gar nicht notwendig. Also ist es auch nicht notwendig eine Solche abzuschalten. Aber das schrieb ich bereits.
        
        MfG
        Last edited: 2018-10-23 18:42:52 +0200 (CEST)
        
        +2 replies
        
        GwenDragon
        
        2018-10-23 18:45
        
        User since
        2005-01-17
        14542 Artikel
        Admin1
        
        Er hält es ja auch geheim welches Perl er nutzt und welche Modul-Version.
        
        Aber ich hatte ja schon mit meinem Programm gezeigt, dass seine Aussage, dass die Module bei Unicode Mist machen, das utf8 bei Zeichenketten zwangsgesetzt werden muss, so nicht stimmig ist.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        rosti
        
        2018-10-23 18:50
        
        User since
        2011-03-19
        3199 Artikel
        BenutzerIn
        
        Quote
        Er hält es ja auch geheim welches Perl er nutzt und welche Modul-Version.
        
        Das auch. Aber unabhängig davon: Nach STDOUT & Co. gehören keine kodierten Zeichenketten sondern Bytes. Das war schon immer so. Genauso wie eine HTTP-Response nur Bytes enthält dessen Länge ggf. im Responseheader Content-Length, soweit vorhanden, als Anzahl der Bytes und nicht als Anzahl der Zeichen angegben ist.
        
        Schöne Güße.
    - GwenDragon
      
      2018-10-23 18:03
      
      User since
      2005-01-17
      14542 Artikel
      Admin1
      
      Zu Zeichenkodierung und Perls interner Kodierung utf8 siehe auch https://perlgeek.de/de/artikel/charsets-unicode
      Dass du das nicht gefunden hast!?
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +2 replies
- GwenDragon
  
  2018-10-23 17:15
  User since
  2005-01-17
  14542 Artikel
  Admin1
  Folgendes klappt bei mir mit Perl 5.14 :P
  
  Quelldatei ist UTF-8 und XML.
  Konsole ist Unicode zu Testausgabe.
  
  get.pl
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
  
  #!/usr/bin/perl use strict; use warnings; use 5.010; use utf8; use LWP::UserAgent; use HTTP::Request; my $ua = LWP::UserAgent->new; $ua->agent("MyApp/0.1 "); $ua->default_header('Accept-Encoding' => 'gzip'); # Create a request my $req = HTTP::Request->new(GET => 'https://labs.gwendragon.de/test/data.xml'); # Pass request to the user agent and get a response back my $res = $ua->request($req); my ($content, $output); # Check the outcome of the response if ($res->is_success) { $content = $res->content; say $req->as_string; say $res->as_string; say '------------------------------'; } else { say $res->status_line; } say ""; say "===== Gunzpped ==============="; use IO::Uncompress::Gunzip qw(gunzip $GunzipError); my $status = gunzip(\$content => \$output) or die "gunzip failed: $GunzipError\n"; say $output; open my $FH, '>', 'get.data'; binmode $FH; say $FH $output;
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
  
  PERL-5.14 T:\>chcp Aktive Codepage: 65001. PERL-5.14 T:\>perl get.pl GET https://labs.gwendragon.de/test/data.xml Accept-Encoding: gzip User-Agent: MyApp/0.1 libwww-perl/6.04 HTTP/1.1 200 OK Cache-Control: max-age=84501 Connection: Upgrade, close Date: Tue, 23 Oct 2018 15:11:10 GMT Upgrade: h2,h2c Accept-Ranges: bytes ETag: "e4-578e65676f100-gzip" Server: Apache Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 200 Content-Type: application/xml Expires: Wed, 24 Oct 2018 14:39:32 GMT Last-Modified: Tue, 23 Oct 2018 14:39:32 GMT Client-Date: Tue, 23 Oct 2018 15:11:10 GMT Client-Peer: 213.133.110.246:443 Client-Response-Num: 1 Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 Client-SSL-Cert-Subject: /CN=labs.gwendragon.de Client-SSL-Cipher: ECDHE-RSA-AES256-GCM-SHA384 Client-SSL-Socket-Class: IO::Socket::SSL Content-Security-Policy: script-src 'self' Referrer-Policy: no-referrer Strict-Transport-Security: max-age=15768000; includeSubDomains X-Content-Type-Options: nosniff X-Download-Options: noopen X-Frame-Options: sameorigin X-LoadTime: D=489 us X-Powered-By: Perl X-Robots-Tag: noarchive, noodp, noimageindex X-XSS-Protection: 1; mode=block 5=@{N1X 0!1Qn-(ݞě^fcK xUUnHy|>M\B"`XhZTP4֏;p0.LDģy"YBk| )~)H8srA._±-R"-Ɇ ------------------------------ ===== Gunzpped =============== <?xml version="1.0" encoding="UTF-8"?> <person> <name>Jürgen Müller-Büßlich</name> <nick>Jört</nick> <comment>Möglicherweise ist das große ß doch ein ẞ. Prüfen Sie das bitte möglichst rasch.</comment> </person> PERL-5.14 T:\>file get.data get.data: XML 1.0 document, UTF-8 Unicode text, with CRLF line terminators
  
  get.data hat dann korrekte UTF-8-Zeichenketten.
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
  
  T:\>hd get.data /0 /1 /2 /3 /4 /5 /6 /7 /8 /9/ A /B /C /D /E /F 0123456789ABCDEF 0000 : 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 <?xml version="1 0010 : 2E 30 22 20 65 6E 63 6F 64 69 6E 67 3D 22 55 54 .0" encoding="UT 0020 : 46 2D 38 22 3F 3E 0D 0A 3C 70 65 72 73 6F 6E 3E F-8"?>..<person> 0030 : 0D 0A 20 20 3C 6E 61 6D 65 3E 4A C3 BC 72 67 65 .. <name>J..rge 0040 : 6E 20 4D C3 BC 6C 6C 65 72 2D 42 C3 BC C3 9F 6C n M..ller-B....l 0050 : 69 63 68 3C 2F 6E 61 6D 65 3E 0D 0A 20 20 3C 6E ich</name>.. <n 0060 : 69 63 6B 3E 4A C3 B6 72 74 3C 2F 6E 69 63 6B 3E ick>J..rt</nick> 0070 : 0D 0A 20 20 3C 63 6F 6D 6D 65 6E 74 3E 4D C3 B6 .. <comment>M.. 0080 : 67 6C 69 63 68 65 72 77 65 69 73 65 20 69 73 74 glicherweise ist 0090 : 20 64 61 73 20 67 72 6F C3 9F 65 20 C3 9F 20 64 das gro..e .. d 00A0 : 6F 63 68 20 65 69 6E 20 E1 BA 9E 2E 20 50 72 C3 och ein .... Pr. 00B0 : BC 66 65 6E 20 53 69 65 20 64 61 73 20 62 69 74 .fen Sie das bit 00C0 : 74 65 20 6D C3 B6 67 6C 69 63 68 73 74 20 72 61 te m..glichst ra 00D0 : 73 63 68 2E 3C 2F 63 6F 6D 6D 65 6E 74 3E 0D 0A sch.</comment>.. 00E0 : 3C 2F 70 65 72 73 6F 6E 3E 0D 0A </person>..
  
  //EDIT: Funktioniert auch unter Debian 9 mit Perl 5.24.1 so.
  
  Muss dein System sein, das "Scheiß" (wie du dich ausdrückst) macht.
  Also rück mal raus mit mehr Informationen.
  Last edited: 2018-10-23 19:00:21 +0200 (CEST)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - haj
    
    2018-10-24 18:34
    User since
    2015-01-07
    529 Artikel
    BenutzerIn
    
    Das Beispiel ist prima - danke auch dafür, dass Du auch die Testdaten auf Deinem Server bereitstellst!
    
    Ich nehme das zum Anlass, auf zwei Kleinigkeiten hinzuweisen:
    
    use utf8 schadet nicht, nutzt aber in diesem Beispiel auch nix.
    Perls Default-Encoding ist nur auf unixoiden Betriebssystemen Byte-orientiert. In Deinem Hexdump sieht man, dass Windows-Zeilenenden drinstehen (0D 0A). Strawberry Perl auf Windows erzeugt per Default diese zwei-Byte-Sequenz auch aus einem einzelnen "\n". Abhilfe, d.h. "richtige" Byte-Orientierung schafft binmode, was im Code-Beispiel auch drinsteht... so dass mich der Hexdump dann doch wieder etwas überrascht.
    
    Bei der Gelegenheit: Wenn man den LWP::UA machen läßt, dann liefert er in $res->decoded_content einen String aus 199 Perl-Characters. Aus dem Content-Encoding holt er das gzip, und aus dem Content-Type das Encoding UTF-8 - und streicht auch (Überraschung!!) gleich das encoding="UTF8" aus der ersten Zeile so wie das "\n" aus der letzten Zeile raus. Diesen String kann man nun tatsächlich mit open my $out,'>:encoding(UTF-8)','utf8out' in eine Datei schreiben, die sieht dann so aus:
    
    Code: (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
    
    haj@hajdesktop:~/data/test$ hd utf8out 00000000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 |<?xml version="1| 00000010 2e 30 22 3f 3e 0a 3c 70 65 72 73 6f 6e 3e 0a 20 |.0"?>.<person>. | 00000020 20 3c 6e 61 6d 65 3e 4a c3 bc 72 67 65 6e 20 4d | <name>J..rgen M| 00000030 c3 bc 6c 6c 65 72 2d 42 c3 bc c3 9f 6c 69 63 68 |..ller-B....lich| 00000040 3c 2f 6e 61 6d 65 3e 0a 20 20 3c 6e 69 63 6b 3e |</name>. <nick>| 00000050 4a c3 b6 72 74 3c 2f 6e 69 63 6b 3e 0a 20 20 3c |J..rt</nick>. <| 00000060 63 6f 6d 6d 65 6e 74 3e 4d c3 b6 67 6c 69 63 68 |comment>M..glich| 00000070 65 72 77 65 69 73 65 20 69 73 74 20 64 61 73 20 |erweise ist das | 00000080 67 72 6f c3 9f 65 20 c3 9f 20 64 6f 63 68 20 65 |gro..e .. doch e| 00000090 69 6e 20 e1 ba 9e 2e 20 50 72 c3 bc 66 65 6e 20 |in .... Pr..fen | 000000a0 53 69 65 20 64 61 73 20 62 69 74 74 65 20 6d c3 |Sie das bitte m.| 000000b0 b6 67 6c 69 63 68 73 74 20 72 61 73 63 68 2e 3c |.glichst rasch.<| 000000c0 2f 63 6f 6d 6d 65 6e 74 3e 0a 3c 2f 70 65 72 73 |/comment>.</pers| 000000d0 6f 6e 3e |on>| 000000d3
    
    Das ist ein bisschen viel der Automatik und hat schon manchen Tester in den Wahnsinn getrieben, weil beim Client was anderes ankommt als der Server schickt. Deswegen habe ich schon Verständnis für jeden, der so etwas byte-orientiert abarbeitet. Man muss es halt nur konsequent tun.
- pq
  
  2018-10-24 19:39
  User since
  2003-08-04
  12208 Artikel
  Admin1
  Lieber Gast,
  
  du möchtest bitte
  
  Deinen Programmierfrust nicht in diesem Forum auslassen und wie GwenDragon schon schrieb, so etwas wie den entfernten Text nicht nochmal hier schreiben
  respektvoller mit den Antworten anderer umgehen. Ich meine speziell hier deine Antwort auf rosti ("gequirrlte K*****k****"). Dann werden deine Beiträge auch freigeschaltet
  die Dokumentation von HTTP::Response lesen, denn da steht print $response->decoded_content gleich im ersten Beispiel (wie haj in seiner Antwort auch schon erwähnte)
  folgenden Artikel Zeichenkodierungen oder „Warum funktionieren meine Umlaute nicht?” von moritz lesen
  
  Vielen Dank!
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
- GwenDragon
  
  2018-10-25 11:17
  
  User since
  2005-01-17
  14542 Artikel
  Admin1
  
  @Gast Your_name
  Ich schrieb:
  
  2018-10-23T14:25:02 GwenDragon
  Bei all deinem Ärger: um welches Perl und um welche Modul-Versionen handelt es sich denn?
  
  Du meckerst weiter um, bleibst aber Informationen schuldig. Aber du erwartest, dass wir deine Programmierkünste und Interpretationen zu Perl+Unicode nachvollziehen können.
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- rosti
  
  2018-10-28 08:48
  
  User since
  2011-03-19
  3199 Artikel
  BenutzerIn
  
  Passend zum Thema: http://rolfrost.de/utf8dateiname.html
  
  Schönen Sonntag.
- rosti
  
  2023-05-16 11:07
  User since
  2011-03-19
  3199 Artikel
  BenutzerIn
  Ach Übrigens:
  
  Code (perl): (dl )
  
  1 2 3
  
  use strict; use warnings; print "Blahhhh, blah', blaaaÄÖÜäöüß!\n";
  
  Macht dasselbe wie
  
  Code (perl): (dl )
  
  1 2 3 4 5
  
  use strict; use warnings; use utf8; binmode(STDOUT,':utf8'); print "Blahhhh, blah', blaaaÄÖÜäöüß!\n";
  
  Und genauso wie STDOUT nur Bytesequenzen haben will bekommst Du über HTTP eben auch nur Bytesquenzen weil die aus STDIN gelesen werden. MFG

View all threads created 2018-10-23 14:29.