Auswertung Logfile: Umlaute werden merkwürdig umgewandelt

[Charles]

Hi, ich habe ein kleineres Perl-Script geschrieben, um die Logfiles für die eigene Website nach bestimmten Kriterien auszuwerten, die mir in der Logfile-Analyse des Servers so nicht angezeigt werden.

Das Script analysiert auch, welche Suchbegriffe bei Google&Co in den Referer-Angaben auftauchen. Dabei habe ich jetzt das Problem, dass bei etlichen Suchbegriffen die Umlaute zu seltsamen Zeichen führen. Ich verwende für die gefundenen Suchbegriffe die übliche Ersetzung:
$suchbegr =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

Und dann kommt für etliche (nicht alle, aber vielleicht 20%) der Suchbegriffe heraus, dass Umlaute in der Ausgabe als Zeichen erscheinen wie "ältere Menschen" statt "ältere Menschen", "rückenschmerzen" statt "Rückenschmerzen" usw.

Nun könnte man meinen, die Suchanfrage kam von jemand, der im Ausland einen anderen Zeichensatz verwendet. Ist aber nicht so, fast durchweg handelt es sich um IPs von deutschen Servern. Der im Logfile angezeigte Suchbegriff von einem deutschen Server heisst z.B.: "%C3%BCckenschmerzen", im Google-Suchstring erscheint auch noch explizit "&cr=countryDE".

Woran liegt das? Dass jemand in Deutschland auf seinem Browser einen sehr exotischen Zeichensatz verwendet? Oder stimmt die Perl-Ersetzung nicht?

[MudGuard]

Hi,

Und dann kommt für etliche (nicht alle, aber vielleicht 20%) der Suchbegriffe heraus, dass Umlaute in der Ausgabe als Zeichen erscheinen wie "ältere Menschen" statt "ältere Menschen", "rückenschmerzen" statt "Rückenschmerzen" usw.

UTF-8-codierte Umlaute, die als ISO-8859-1 interpretiert werden.

cu,
Andreas

[Charles]

UTF-8-codierte Umlaute, die als ISO-8859-1 interpretiert werden.
cu, Andreas

Hi Andreas,
danke für Deine Antwort. Zwei kleine Nachfragen:

• Heißt das für den Absender der Suchanfrage bei Google, er hat in seinem Browser ganz bewußt UTF-8 als Zeichensatz eingestellt? Oder gibt es Browser, die (in Deutschland) UTF-8 und nicht "Westlich" bzw, "ISO-8859-1" als Standardeinstellung haben?
• Kann ich die Zeichensatz-Einstellung des Browsers noch aus dem Logfile erkennen, gibt's da in der User-Agent-Angabe irgendwelche Hinweise, so dass man im Perl-Script eine korrekte Umkodierung vornehmen könnte?
  Charles

[Henryk Plötz]

Moin,

• Heißt das für den Absender der Suchanfrage bei Google, er hat in seinem Browser ganz bewußt UTF-8 als Zeichensatz eingestellt? Oder gibt es Browser, die (in Deutschland) UTF-8 und nicht "Westlich" bzw, "ISO-8859-1" als Standardeinstellung haben?

Zumindest für GET-Parameter ist das keine besonders seltene Einstellung.

• Kann ich die Zeichensatz-Einstellung des Browsers noch aus dem Logfile erkennen, gibt's da in der User-Agent-Angabe irgendwelche Hinweise, so dass man im Perl-Script eine korrekte Umkodierung vornehmen könnte?

Speziell bei Google wird die verwendete Zeichencodierung (zumindest von der in Firefox eingebauten Suche, und auch der von Opera) in ie im GET-String übertragen, müsste also in deinem Refererlog auftauchen. Ansonsten: Bei POST kann man die Codierung wohl im Content-Type:-Header angeben, bzw. verwendet die Codierung die im Formular angegeben wird, die aktuellen Browserimplementierungen bekleckern sich da aber meist nicht wirklich mit Ruhm.

Was du machen kannst, wenn kein ie-Parameter (oder äquivalent) übergeben wird, ist raten: Was sich als UTF-8 interpretieren lässt ist meist auch UTF-8 (oder ASCII, aber das ist ja eh egal). Was vom UTF-8-Dekoder nicht geschluckt wird ist (hierzulande) ISO-8859-15 oder ISO-8859-1. (Und was kein ISO-8859-* ist, ist Windows-1252 oder Mac Roman.) Das ist hässlich und stinkt alles, aber meist good enough.

[Ingo Turski]

Hi,

• Heißt das für den Absender der Suchanfrage bei Google, er hat in seinem Browser ganz bewußt UTF-8 als Zeichensatz eingestellt?

Nein. Google liefert seine Seiten standardmäßig als UTF-8 aus, wie Du leicht selbst feststellen kannst. Folglich sind auch alle Umlaute in den Referrern UTF-8-kodiert - mir sind jedenfalls noch keine anderen aufgefallen. Theoretisch könnte zwar auch eine andere Kodierung verwendet werden, entweder wenn der Browser kein UTF-8 unterstützt (welcher sollte das sein?) oder wenn dies über den ie-Parameter angegeben wird (welcher Browser bzw. welches Plugin macht dies?).

• Kann ich die Zeichensatz-Einstellung des Browsers noch aus dem Logfile erkennen, gibt's da in der User-Agent-Angabe irgendwelche Hinweise, so dass man im Perl-Script eine korrekte Umkodierung vornehmen könnte?

Normalerweise nicht. Aber das brauchst Du auch gar nicht. Gehe bei den Referrern grundsätzlich von UTF-8 aus; sollten doch mal anders kodierte Zeichen vorhanden sein, ist das auch nicht schlimm. In meiner UTF-8-Dekodierungsroutine suche ich in den Referrern einfach nach "\x" bzw. "%" und wandle die folgenden Zeichen um. Mir ist jedenfalls noch kein Zeichensalat in meinen Auswertungen aufgefallen.

freundliche Grüße
Ingo

[Rolf]

Und dann kommt für etliche der Suchbegriffe heraus, dass Umlaute in der Ausgabe als Zeichen erscheinen wie "ältere Menschen" statt "ältere Menschen", "rückenschmerzen" statt "Rückenschmerzen" usw.

UTF-8-codierte Umlaute, die als ISO-8859-1 interpretiert werden.

Ich habe jetzt auch mal in meine Logfiles geschaut und finde da bei den Google-Suchstrings z.B. die Vercodung: "B%C3%BCrger" für "Bürger".
%BC dürfte der Hex-Wert für das "ü" im UTF-Zeichensatz sein, aber wofür steht das "%C3" ?

[MudGuard]

Hi,

"rückenschmerzen" statt "Rückenschmerzen" usw.
UTF-8-codierte Umlaute, die als ISO-8859-1 interpretiert werden.

Ich habe jetzt auch mal in meine Logfiles geschaut und finde da bei den Google-Suchstrings z.B. die Vercodung: "B%C3%BCrger" für "Bürger".
%BC dürfte der Hex-Wert für das "ü" im UTF-Zeichensatz sein, aber wofür steht das "%C3" ?

Nö, die beiden Bytes C3 und BC ergeben zusammen die UTF-8-Darstellung des ü.

C3 ist das à und BC das ¼ - siehe oben bei den Rückenschmerzen.

cu,
Andreas