Opened by Your_name at 2018-10-23 14:29
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:
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)
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)