Alle guten Dinge sind dreist: Schon wieder Schei? Encoding...

[Jean-Max]

Bounjoun alle,

Die Aufgabe: aus dem Referrer-String (derzeit) sechs Suchmaschinen auswerten, den eingegebenen Suchbegriff extrahieren und die Ausbage nach Vorkommenshäufigkeit präsentieren.

Die Lösung: Perl-technisch kein großes Problem, vielleicht läßt sich das eleganter Lösen - das ist aber nicht das Problem, dieses wird danach beschrieben:

  
   my %se;  # search engines  
   my %kw;  # keywords, keyphrases  
   for (keys %ref) {  # %ref wird weiter oben im Programm mit Referrer-Strings befüllt  
     $se{Google}++ if $_ =~ /\.google\./;  
     $se{Yahoo}++ if $_ =~ /\.yahoo\./;  
     $se{bing}++ if $_ =~ /\.bing\.com/;  
     $se{'Web.de'}++ if $_ =~ /suche\.web\.de/;  
     $se{Altavista}++ if $_ =~ /\.altavista\./;  
     $se{'T-Online'}++ if $_  =~ /navigationshilfe|suche\.t-online\./;  
     if ( $_ =~ /(?<![a-z])(q=|r=|search=|query=|p=)(.+?)(&.*)*$/g ) {  
       my $query = $2;  
       $query =~ s/(%20)+/$1/g;   # durch Mehrfachleerzeichen enstandene Doubletten in der Ausgabe vermeiden  
       $query = $cgi->unescape($query); #URL-decoden  
       $kw{$query}++;  
     }  
   }  

Am Ende enthält %kw so was wie:

  'Atomic Eggs' => 4,  
  'Patrick Andrieu' => 2,  
  'Corel Draw kann keine templates öfnnen' => 1,

etc...

Die HTML-Ausgabe (UTF-8) sieht tabellarisch dann so aus:

| Anzahl | Suchwort/-begriff

1 |      4 | Atomic Eggs
2 |      2 | Patrick Andrieu
3 |      1 | Corel Draw kann keine templates öfnnen

Beispiel hier: http://www.pagecount.org/oae/counter/pv.pl?month=this&target=refs, unterste Tabelle (Daten zum Einloggen: atomic, eggs).

Das Problem: solange ich nur mit UTF-8-Encoding zu tun habe, gibt es keins. Doch, und der dritte Suchbegriff im obigen Beispiel habe ich nicht erfunden, sind immer wieder andere Daten zu finden.

Corel Draw kann keine templates öfnnen

Abgesehen davon, dass der oder die Suchende ein »f« zu wenig und dafür ein »n« zu viel im Wort »öffnen« in Google eingetippt hatte, sah der URL-Encodete »Rohbegriff« in der Logfile so aus:

Corel Draw kann keine templates %F6fnnen

Ausgegeben wird:

Corel Draw kann keine templates �fnnen

Da schauen wir uns mal den gesamten Referrer-String an:

http://www.google.de/custom?q=Corel Draw kann keine templates %F6fnnen&sa=Suchen&client=pub-4347119884249993&forid=1&channel=8272761113&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23008000%3BGL%3A1%3BDIV%3A%23336699%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3A336699%3BALC%3A0000FF%3BLC%3A0000FF%3BT%3A000000%3BGFNT%3A0000FF%3BGIMP%3A0000FF%3BFORID%3A1%3B&hl=de&meta=

Aha: &ie=ISO-8859-1&oe=ISO-8859-1

Die Frage: Da ich nicht wissen kann, wie User ihre Clients konfigurieren (genausowenig, wie sie sich vertippen *g*), was habe ich noch für Möglichkeiten, dass die Ausgaben immer korrekt ist:

Corel Draw kann keine templates öfnnen

Adiou.

[hotti]

hi,

Aha: &ie=ISO-8859-1&oe=ISO-8859-1

Richtig, %F6 ist ein 'ö' in ISO...

Was Du machen kannst: Nimm einen ganz normalen Parser für den QUERY_STRING, der steckt z.B. in

use URI::Escape;

ein uri_unescape('%F6'); liefert Dir ein 'ö', genauso wie ein
uri_unescape('%C3%B6'); Dir auch ein 'ö' liefert, nur halt in utf-8. Wie's kommt, kannst Du nicht beeinflussen, Dein Frontend zur Auswertung jedoch, das machst Du einfach so, dass Du zwischen utf8 und iso umschalten kannst. Die Referrer selbst sind schon zum klicken, so wie die sind.

Viele Grüße,
Horst Oppenheimer

[hotti]

Moin,

Was Du machen kannst: Nimm einen ganz normalen Parser für den QUERY_STRING, der steckt z.B. in

use URI::Escape;

Quatsch, ne, genau umgekehrt. Ein Parser verwendet Escape. Deine Freunde sind:

use URI::Split qw(uri_split);

($scheme, $auth, $path, $query, $frag) = uri_split($referrer);

für den Fall, Du willst $query selbst in die Parameter zerlegen. Oder Du nimmst gleich:

use URI::QueryParam; # Objekt über den Referrer erstellen

damit kommst Du ohne Umschweife an die gewünschten Parameter.

  
  
  
my $uri = 'http://www.google.de/custom?q=Corel Draw kann keine templates %F6fnnen&sa=Suchen&client=pub-4347119884249993&forid=1&channel=8272761113&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23008000%3BGL%3A1%3BDIV%3A%23336699%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3A336699%3BALC%3A0000FF%3BLC%3A0000FF%3BT%3A000000%3BGFNT%3A0000FF%3BGIMP%3A0000FF%3BFORID%3A1%3B&hl=de&meta='; # der Referrer  
  
use URI;  
use URI::QueryParam;  
  
my $u = URI->new($uri);  
  
my @keys = $u->query_param;  
  
print join("\n", @keys);  
  
q  
sa  
client  
forid  
channel  
ie  
oe  
cof  
hl  
meta  

So wirds gemacht, schönen Sonntag ;-)
Oppenheimer

[Jean-Max]

Bounjoun hotti,

use URI::Split qw(uri_split);
use URI;
use URI::QueryParam;

Interessante Module, für die ich sicher Verwendung finden werde. Es geht aber an der Frage etwas vorbei.

Es geht darum, aus einem URL-Encoded ISO-8859-1-Charakter ein UTF-8-Charakter zu machen. Oder auf diesem Beispiel gemünzt: aus %F6 %C3%B6 oder direkt ö machen.

Leider bin ich nach dem Posting erstmal mit anderem Zeugs beschäftigt, werde aber vielleicht heute abend, sonst irgendwann in der Woche weiter proggen können. Ich befürchte aber, dass so ein Konstrukt:

$data = encode("utf8", decode("iso-8859-1", $data));

nichts bringt.

Ich habe folgende Zeilen im Code:

##############################  
use Encode qw(encode decode);  
my $xyz = '%F6ffnen';  
$xyz = encode('UTF-8', decode('ISO-8859-1', $xyz));  
##############################

und lasse es unterhalb der letzten Tabelle ausgeben:

http://www.pagecount.org/oae/counter/pv.pl?month=this&target=refs Daten zum Einloggen: atomic, eggs.

Adiou.

[hotti]

hi,

Es geht darum, aus einem URL-Encoded ISO-8859-1-Charakter ein UTF-8-Charakter zu machen. Oder auf diesem Beispiel gemünzt: aus %F6 %C3%B6 oder direkt ö machen.

Das macht URI::Escape, also der Parser der genannten Module.

Bevor Du umkodierst, prüf erstmal, was Du vor Dir hast. Speichere die Daten als Rohdaten (binary, bytes) unabhängig von der Kodierung und mach lediglich das Frontend, den Betrachter, umschaltbar.

Hotti

[hotti]

hi,

Es geht darum, aus einem URL-Encoded ISO-8859-1-Charakter ein UTF-8-Charakter zu machen. Oder auf diesem Beispiel gemünzt: aus %F6 %C3%B6 oder direkt ö machen.

auf die Schnelle
 sub latin1_to_utf8{return(pack("U*", unpack("C*", shift)))}

wenn Du die Schablonen umdrehst, gehts auch andersrum (sauschnell).

Hotti

[Jean-Max]

Bounjoun hotti,

Das hilft alles nichts, Hotti.

Ich habe jetzt diese Zeilen Code:

#######################################################  
use Encode qw(encode decode);  
use URI::Escape;  
  
my $xyz = '%F6ffnen';  
my $cba = decode('ISO-8859-1', $xyz);  
my $abc = encode('UTF-8', decode('ISO-8859-1', $xyz));  
my $cde = l_t_u($xyz);  
sub l_t_u {  
  return pack("U*", unpack("C*", shift));  
}  
#my $fgh = uri_unescape($xyz);  
my $fgh = uri_unescape(decode('ISO-8859-1', $xyz));  
#######################################################  

Ausgabe:

$xyz = %F6ffnen $abc = %F6ffnen $cde = %F6ffnen $fgh = �ffnen $cba = %F6ffnen

Kann das sein, dass dieser »cas de figure« programmiertechnisch gar nicht vorgesehen ist? Dass man aus einem ISO-URL-endoded-String, oder wie man immer das nennen will, wieder ein UTF8-Dekodierbarer macht?

Verdammt, es muss doch eine Lösung geben!

Noch mal das Testcase gekürzt:

Der Hash %kw enthält zu 99% »gute Strings«, und zu etwa 1% Sonderlinge:

%C3%B6ffnen => 99
%F6ffnen => 1

Ich will nur die schlechten zu guten machen!

Adiou.

[Struppi]

#######################################################

use Encode qw(encode decode);
use URI::Escape;

my $xyz = '%F6ffnen';
my $cba = decode('ISO-8859-1', $xyz);

Das macht hier nichts.

my $abc = encode('UTF-8', decode('ISO-8859-1', $xyz));

Das auch nicht.

#my $fgh = uri_unescape($xyz);

erst das wandelt den kosierten String in eine normale Zeichenkette.

my $fgh = uri_unescape(decode('ISO-8859-1', $xyz));

Das macht hier wieder nichts.

Kann das sein, dass dieser »cas de figure« programmiertechnisch gar nicht vorgesehen ist? Dass man aus einem ISO-URL-endoded-String, oder wie man immer das nennen will, wieder ein UTF8-Dekodierbarer macht?

Natürlich, du musst nur die Reihenfolge richtig angehen.

1. uri_dekodieren
2. umkodieren.

[code lang=perl]my $xyz = '%F6ffnen';
my $fgh = encode('utf-8', uri_unescape($xyz));
print $fgh;

  
Struppi.

[Jean-Max]

Bounjoun Struppi,

Natürlich, du musst nur die Reihenfolge richtig angehen.

1. uri_dekodieren
2. umkodieren.

my $xyz = '%F6ffnen';

my $fgh = encode('utf-8', uri_unescape($xyz));
print $fgh;

  
  
Vielen Dank schon mal, das löst das Problem der »schlechten« Strings... macht aber die »guten« unleserlich:  
  
~~~perl
my $xyz = '%C3%B6ffnen';  
my $fgh = encode('utf-8', uri_unescape($xyz));  
print $fgh;  

Das Problem: Ich kann nicht beeinflußen, was in das Logfile 'reinkommt. Ich kann nur arbeiten mit dem, was da drin ist. Und da sind in der Regel Strings, die sich problemlos mit $cgi->unescape($query) in lesbare Charakter umwandeln lassen.

Jetzt die Frage, was habe ich für Möglichkeiten, die »schlechten« zu erkennen, um sie anders zu behandeln?

Adiou.

[Jean-Max]

Re!

Jetzt die Frage, was habe ich für Möglichkeiten, die »schlechten« zu erkennen, um sie anders zu behandeln?

Im Grunde sowas wie:

if ($blöderString wurde aus ISO-8859-1 url-encoded) {
  behandle ihn so;
}
else { behandle ihn anders; }

Adiou.

[hotti]

hi,

Jetzt die Frage, was habe ich für Möglichkeiten, die »schlechten« zu erkennen, um sie anders zu behandeln?

Im Grunde sowas wie:

if ($blöderString wurde aus ISO-8859-1 url-encoded) {
  behandle ihn so;
}
else { behandle ihn anders; }

Also nochmal: Alles was mit dem Referrer reinkommt ist us-ascii. %F6 ist ascii, %C3%B6 ist auch ascii. Mit dem Percent-Encodung sind lediglich die bytes umgeschrieben. URI::Escape::uri_unescape() stellt Dir diese bytes wieder her, erst dann hast Du bytes, die Zeichen darstellen. Wenn Du das speichern willst, nimm das so wie es ist, entweder den Referrer komplett oder geparst und umgewandelt in die bytes. Zum Speichern keine Zeichencodierung umwandeln, das kannst Du in der Darstellung immer noch machen. Den Referrer kannst Du, egal ob Dein Frontend mit iso oder utf8 erstellt wurde, als "a href" klickbar machen, denn der ist ja ascii und wird immer so aussehen, wie der reinkommt.

Wenn Du jedoch den Referrer erst zerlegst und das Percentencoding rückgängig machst, ja dann hast Du bytes, die Zeichen in unterschiedlicher Kodierung darstellen (könnten, das Meiste ist utf8). Mach die Umschaltung zur Darstellung einfach per Hand und entscheide optisch. Falls Du das automatisieren willst, musst Du ein bischen mehr tun, da ist anhand aufeinanderfolgender bytes feststellbar, welche Kodierung vorliegt. Ob sich dieser Aufwand lohnt, musst Du selbst entscheiden.

Hotti

[Struppi]

Vielen Dank schon mal, das löst das Problem der »schlechten« Strings... macht aber die »guten« unleserlich:

was heißt unleserlich?

my $xyz = '%C3%B6ffnen';

my $fgh = encode('utf-8', uri_unescape($xyz));
print $fgh;

  
Wieso willst du einen utf-8 String in einen utf-8 String umwandeln???? Du machst hier eine doppelte Kodierung.  
  

> Das Problem: Ich kann nicht beeinflußen, was in das Logfile 'reinkommt. Ich kann nur arbeiten mit dem, was da drin ist. Und da sind in der Regel Strings, die sich problemlos mit $cgi->unescape($query) in lesbare Charakter umwandeln lassen.  
  
Wenn sie in der Kodierung vorliegen, die du haben willst.  
  

> Jetzt die Frage, was habe ich für Möglichkeiten, die »schlechten« zu erkennen, um sie anders zu behandeln?  
  
erkennen geht nicht, nur raten <http://perldoc.perl.org/Encode/Guess.html>  
  
Struppi.

[Beat]

Die Frage: Da ich nicht wissen kann, wie User ihre Clients konfigurieren (genausowenig, wie sie sich vertippen *g*), was habe ich noch für Möglichkeiten, dass die Ausgaben immer korrekt ist:

wenn

use Encode qw(decode);
$string = decode("UTF-8", $octets ,1 );

croaked, lohnt sich ein anderes Encoding...

ISO-Encodings lassen sich aber nicht weiter aufschlüsseln.

mfg Beat

[CPAN]

TIMTOWTDI. Mir gefällt das dritte am besten, weil es außer ISO-8859-1 noch viele andere Legacykodierungen erkennt.

⓵

  
use Devel::Peek qw(Dump);  
use Encoding::FixLatin qw(fix_latin);  
use URI::Escape qw(uri_unescape);  
  
while (defined (my $u = <DATA>)) {  
    chomp $u;  
    $u = uri_unescape $u;  
    $u = fix_latin $u;  
    Dump $u;  
}  
  
__DATA__  
%C3%B6ffnen  
%F6ffnen  

⓶

  
use Devel::Peek qw(Dump);  
use Encode qw(decode);  
use Try::Tiny qw(try catch);  
use URI::Escape qw(uri_unescape);  
  
while (defined (my $u = <DATA>)) {  
    chomp $u;  
    $u = uri_unescape $u;  
    try {  
        $u = decode 'UTF-8', $u, Encode::FB_CROAK;  
    } catch {  
        $u = decode 'ISO-8859-1', $u, Encode::FB_CROAK;  
    };  
    Dump $u;  
}  
  
__DATA__  
%C3%B6ffnen  
%F6ffnen  

⓷

  
use Devel::Peek qw(Dump);  
use Encode qw(decode);  
use Encode::Detect qw();  
use URI::Escape qw(uri_unescape);  
  
while (defined (my $u = <DATA>)) {  
    chomp $u;  
    $u = uri_unescape $u;  
    $u = decode 'Detect', $u;  
    Dump $u;  
}  
  
__DATA__  
%C3%B6ffnen  
%F6ffnen  

[Jean-Max]

Bounjoun CPAN,

Du bist einfach GENIAL. Danke!

Adiou.

[Jean-Max]

Re!

Du bist einfach GENIAL. Danke!

Das ohne Zweifel... und die Änderungen lasse ich im Skript.

Mittlerweile frage ich mich allerdings, ob das Problem nicht »a weng« selbstverschuldet war, denn der JavaScript-Aufruf des Counters beinhaltet:

...&ref=',escape(document.referrer),'&...

Ersetze ich das allerdings durch:

...&ref=',encodeURIComponent(document.referrer),'&...

wird das »+«-Zeichen im Parameterwert nicht kodiert - entgegen der Behauptung:

Wie encodeURI(), aber mit dem Unterschied,
    dass auch folgende Zeichen kodiert werden:
    , / ? : @ & = + $

in SELFHTML zu encodeURIComponent()???

Auszug (Google-Suchbegriff: atömic eggs):

mit »escape()«:

http://www.google.de/search?q=at%C3%B6mic eggs&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

mit »encodeURIComponent()«:

http://www.google.de/search?q=at%C3%B6mic+eggs&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

Aber auch dieser Hinweis zu escape():

Diese Funktion hat ein problematisches Verhalten bei diversen Zeichen
   (das Pluszeichen wird z.B. nicht verändert, obwohl es dadurch in der
   URL als Leerzeichen interpretiert würde)

scheint nicht so richtig, denn:

Auszug (Google-Suchbegriff: atömic + eggs):

mit »escape()«:

http://www.google.de/search?q=at%C3%B6mic %2B eggss&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

mit »encodeURIComponent()«:

http://www.google.de/search?q=at%C3%B6mic+%2B+eggs&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

Bei escape wurde das eingegebene »+« zu »%2B«, die Trenn-»+« zu Leerzeichen.

Bei encodeURIComponent() wurde nur das eingegeben »+« zu »%2B«.

?? Oder verstehe ich was grundsätzlich falsch an den beiden Funktionen bzw. deren Erläuterungen in SELFHTML?

Adiou.

[Struppi]

Ersetze ich das allerdings durch:

...&ref=',encodeURIComponent(document.referrer),'&...

wird das »+«-Zeichen im Parameterwert nicht kodiert - entgegen der Behauptung:

Dann machst du etwas falsch:
javascript:alert(encodeURIComponent('+'));
Es wird kodiert

mit »encodeURIComponent()«:

http://www.google.de/search?q=at%C3%B6mic+eggs&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

Das ist nicht die Ausgabe, die ich erhalte.

Bei escape wurde das eingegebene »+« zu »%2B«, die Trenn-»+« zu Leerzeichen.

Was ist der Unterschied? escape kodiert nicht das Plus.

Bei encodeURIComponent() wurde nur das eingegeben »+« zu »%2B«.

Was heißt "nur", jedes Plus, dass du mit der Funktion kodierst wird so umgewandelt.

Struppi.

[Jean-Max]

Bounjoun Struppi,

Dann machst du etwas falsch:

Du bleibst Dir und Deinem »Spruch« treu, freut mich ;)

Dennoch nein, ich mache nicht etwas falsch.

javascript:alert(encodeURIComponent('+'));
Es wird kodiert

Ich meinte das +-Zeichen, das bei einer Google-Eingabe wie »Atomic Eggs« in einem Formularfeld anstelle des Leerzeichens in der URI erscheint:

google.com?q=Atomic+Eggs

Ich habe das in meinen Auszügen wohl deutlich gemacht, oder?

escape() macht daraus ein Leerzeichen, encodeURIComponent() eben nicht.

Adiou.

[Struppi]

Dann machst du etwas falsch:

Du bleibst Dir und Deinem »Spruch« treu, freut mich ;)

Dennoch nein, ich mache nicht etwas falsch.

Doch, die Beschriebung deines Problems.

javascript:alert(encodeURIComponent('+'));
Es wird kodiert

Ich meinte das +-Zeichen, das bei einer Google-Eingabe wie »Atomic Eggs« in einem Formularfeld anstelle des Leerzeichens in der URI erscheint:

Du sagst aber nicht, wie du es weiterverarbeist.

Für mich sind deine Schilderung nicht verständlich. escape wandelt das Zeichen nicht um encode encodeURIComponent() schon. Wenn es bei dir anders ist, dann machst du etwas falsch. Nur können wir nicht Wissen was.

var str = 'google.com?q=Atomic+Eggs';  
  
alert(  
'escape=' + escape(str) + '\n' +  
'encodeURIComponent=' + encodeURIComponent(str)  
  
);  

Struppi.

[Jean-Max]

Bounjoun Struppi,

javascript:alert(encodeURIComponent('+'));
Es wird kodiert

Na klar, das ist das Plus-Zeichen aus der Tastatur.

Nochmals:

Auszug (Google-Suchbegriff: atömic + eggs):

mit »escape()«:

http://www.google.de/search?q=at%C3%B6mic %2B eggss&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

mit »encodeURIComponent()«:

http://www.google.de/search?q=at%C3%B6mic+%2B+eggs&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

Du sagst aber nicht, wie du es weiterverarbeist.

Ich rufe den Counter auf mit so einem Konstrukt:

document.write('<img src="http://example.com/counter.pl?page=foopage&ref=',escape(document.referrer),'&nochwas=baz&auchnochwas=buzz" alt="">');

Für mich sind deine Schilderung nicht verständlich.

Was soll ich sonst noch schildern? Obige Auszüge aus der Logfile, einmal mit escape(), einmal mit encodeURIComponent(), zeigen doch, was bei mir ankommt!?

Du sagst aber nicht, wie du es weiterverarbeist.

Ich gebe in $Suchmaschine einen Begriff mit Leerzeichen ein, suche eine meiner Seiten aus den Treffern, rufe Sie auf und prompt schreibt das Programm die entsprechende Zeile in die Counter-Logfile. Einmal teste ich mit escape, das zweite Mal nehme ich encodeURIComponent, und erhalte Ergebnisse, die nicht sind wie sie m.E. sein sollten.

Adiou.

[Struppi]

javascript:alert(encodeURIComponent('+'));
Es wird kodiert

Na klar, das ist das Plus-Zeichen aus der Tastatur.

Ja was denn sonst????
Die Funktionen erwarten Zeichenketten als Parameter und document.referrer ist eine solche.

Nochmals:

Auszug (Google-Suchbegriff: atömic + eggs):

http://selfhtml.jstruebig.de/dokument.html?q=atöB6mic + eggs

mit »escape()«:

http://www.google.de/search?q=at%C3%B6mic %2B eggss&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

Da sehe ich bei mir was anderes.
http%3A//selfhtml.jstruebig.de/dokument.html%3Fq%3Dat%25C3%25B6mic%2520+%2520eggs

Das Pluszeichen wird nicht verändert.

mit »encodeURIComponent()«:

http://www.google.de/search?q=at%C3%B6mic+%2B+eggs&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:de:official&client=firefox-a

auch da:
http%3A%2F%2Fselfhtml.jstruebig.de%2Fdokument.html%3Fq%3Dat%25C3%25B6mic%2520%2B%2520eggs

Die Leerzeichen werden bei mir nicht in Pluszeichen umgewandelt.

Du sagst aber nicht, wie du es weiterverarbeist.

Ich rufe den Counter auf mit so einem Konstrukt:

document.write('<img src="http://example.com/counter.pl?page=foopage&ref=',escape(document.referrer),'&nochwas=baz&auchnochwas=buzz" alt="">');

Wie in meinem Beispiel.

Für mich sind deine Schilderung nicht verständlich.

Was soll ich sonst noch schildern? Obige Auszüge aus der Logfile, einmal mit escape(), einmal mit encodeURIComponent(), zeigen doch, was bei mir ankommt!?

Ja, aber irgendetwas läuft falsch. Da du eine andere Ausgabe hast, als ich.

Ich gebe in $Suchmaschine einen Begriff mit Leerzeichen ein, suche eine meiner Seiten aus den Treffern, rufe Sie auf und prompt schreibt das Programm die entsprechende Zeile in die Counter-Logfile. Einmal teste ich mit escape, das zweite Mal nehme ich encodeURIComponent, und erhalte Ergebnisse, die nicht sind wie sie m.E. sein sollten.

Wo? Bei der Anzeige mit document.write?

Struppi.

[Jean-Max]

Bounjoun Struppi,

Na klar, das ist das Plus-Zeichen aus der Tastatur.
Ja was denn sonst????

Nun ja, es gibt das »eingetippte« Plus-Zeichen, und das, das aus einem Leerzeichen gemacht wird (CGI, Formulardaten).

Da sehe ich bei mir was anderes.
http%3A//selfhtml.jstruebig.de/dokument.html%3Fq%3Dat%25C3%25B6mic%2520+%2520eggs

Tja, %2520 habe ich nie erhalten...

Ja, aber irgendetwas läuft falsch. Da du eine andere Ausgabe hast, als ich.

Denke ich auch, nur wie eruieren, was?

Wo? Bei der Anzeige mit document.write?

Jein. Das, was im Logfile ankommt.

Adiou.

[Struppi]

Wo? Bei der Anzeige mit document.write?

Jein. Das, was im Logfile ankommt.

Ist das Absicht, dass das URL kodiert gespeichert wird?
Wird das alles noch mal umgewandelt, mit CGI::param()?

Struppi.

[Jean-Max]

Bounjoun Struppi,

Ist das Absicht, dass das URL kodiert gespeichert wird?
Wird das alles noch mal umgewandelt, mit CGI::param()?

Es ist Absicht, dass irgendeine Form des Kodierens notwendig ist. Das hat die Erfahrung gezeigt, nachdem irgendein Garbage im Logfile ankam. Den Counter habe ich bereits mit null Kenntnissen 2000 entwickelt, damals hat mir Christian Kruse viel geholfen (im Chat).

Das hier ist die Neufassung, seitdem ich nun etwas mehr kann, als damals.

Kann die param()-Methode denn die Ergebnisse beeinflussen? Tatsächlich wird der Referrer mit $cgi->param('ref') abgefragt und in die Logfile geschrieben.

Adiou.

[Struppi]

Kann die param()-Methode denn die Ergebnisse beeinflussen? Tatsächlich wird der Referrer mit $cgi->param('ref') abgefragt und in die Logfile geschrieben.

Ja, ein Pluszeichen wird zu einem Leerzeichen.

Struppi.

[Jean-Max]

Bounjoun Struppi,

Ja, ein Pluszeichen wird zu einem Leerzeichen.

Und aus einem kodierten Pluszeichen wieder ein Pluszeichen? Das würde erklären, warum encodeURIComponent() nichts bringt...

P.S.: Bin erst morgen abend wieder online...

Adiou.

[Struppi]

Ja, ein Pluszeichen wird zu einem Leerzeichen.

Und aus einem kodierten Pluszeichen wieder ein Pluszeichen? Das würde erklären, warum encodeURIComponent() nichts bringt...

Wieso bringt es nichts? Du willst doch ein Pluszeichen und kein Leerzeichen?

Struppi.

[Jean-Max]

Bounjoun Struppi,

warum encodeURIComponent() nichts bringt...
Wieso bringt es nichts? Du willst doch ein Pluszeichen und kein Leerzeichen?

»nichts bringt« war falsch ausgedrückt. Ich war nur überrascht über die Ergebnisse, die wohl durch die Bearbeitung durch param() entstehen. Jetzt ist alles klar, Danke!

Aber eine andere Frage habe ich noch:

Warum übermittelt Firefox als einziger Browser eine Farbtiefe von 24Bit, obwohl alle meine Monitoren höchstmögliche Auflösung und höchste Farbtiefe eingestellt bekommen haben (32Bit), und während alle anderen Navis fleißig 32Bit übermitteln?

Adiou.

[Struppi]

Aber eine andere Frage habe ich noch:

Warum übermittelt Firefox als einziger Browser eine Farbtiefe von 24Bit, obwohl alle meine Monitoren höchstmögliche Auflösung und höchste Farbtiefe eingestellt bekommen haben (32Bit), und während alle anderen Navis fleißig 32Bit übermitteln?

Kein Browser übermittelt eine Farbtiefe, du musst schon sagen was du machst.

Struppi.

[Jean-Max]

Bounjoun Struppi,

Kein Browser übermittelt eine Farbtiefe, du musst schon sagen was du machst.

Dann meinte ich »ermittelt«:

javascript:alert(screen.colorDepth);

-> Firefox: 24
-> Safari: 32
-> Opera: 32
-> MSIE: 32
-> Chrome: 32

Adiou.

[Struppi]

Dann meinte ich »ermittelt«:

javascript:alert(screen.colorDepth);

-> Firefox: 24
-> Safari: 32
-> Opera: 32
-> MSIE: 32
-> Chrome: 32

Dann stimmt irgendetwas bei dir nicht. Ich bekomme in allen Browsern, die ich habe, 24Bit.

Ich wüßte jetzt auch nicht woran das bei dir liegen könnte, aber eher nicht am Javascript.

Struppi.

[Struppi]

javascript:alert(screen.colorDepth);

-> Firefox: 24

Das ist ein Firefox Bug.
s. Absch. colorDepth in Firefox

Struppi.

[Jean-Max]

Bounjoun Struppi,

Das ist ein Firefox Bug.
s. Absch. colorDepth in Firefox

Interessant, danke! Anscheinend arbeiten die bei FF mittlerweile wie bei Opera und tun Bugs älterer Versionen wieder mit rein ;)

Adiou.

[Struppi]

Das ist ein Firefox Bug.
s. Absch. colorDepth in Firefox

Interessant, danke! Anscheinend arbeiten die bei FF mittlerweile wie bei Opera und tun Bugs älterer Versionen wieder mit rein ;)

interessant dazu sind auch zwei Links aus den Kommentaren:
http://dev.w3.org/csswg/cssom-view/#dom-screen-colordepth
The colorDepth and pixelDepth attributes must both return the number of bits allocated to colors (i.e. excluding the alpha channel) in the output device. If the output device does not support colors these attributes must  return zero.

"Excluding the alpha Channel", heißt es zählen in deinem Fall nur die 24Bit.

https://bugzilla.mozilla.org/show_bug.cgi?id=424386
und in dem Bugthread dazu, wird dies auch kontrovers diskutiert.

Sieht so aus, als ob der Fx hier richtig liegt und du die Werte der anderen Browser anpassen musst.

Struppi.

[Jean-Max]

Bounjoun Struppi,

interessant dazu sind auch zwei Links aus den Kommentaren:
http://dev.w3.org/csswg/cssom-view/#dom-screen-colordepth
The colorDepth and pixelDepth attributes must both return the number of bits allocated to colors (i.e. excluding the alpha channel) in the output device. If the output device does not support colors these attributes must  return zero.

Ja, die zwei Kommentare und die Spec habe ich nach dem Posting gelesen. Dennoch:

"Excluding the alpha Channel", heißt es zählen in deinem Fall nur die 24Bit.

frage ich mich, warum das nun richtig sein sollte. Aber naja, ich habe die Specs nicht gemacht.

Sieht so aus, als ob der Fx hier richtig liegt und du die Werte der anderen Browser anpassen musst.

Nix da. Wenn 32Bit drauf steht, sind auch 32Bit drin. ;)

Statistiken sind doch zum Fälschen da (wie Opera 10, der sich immer noch als 9.80er ausgibt)...

Adiou.

[Struppi]

Ja, die zwei Kommentare und die Spec habe ich nach dem Posting gelesen. Dennoch:

"Excluding the alpha Channel", heißt es zählen in deinem Fall nur die 24Bit.

frage ich mich, warum das nun richtig sein sollte. Aber naja, ich habe die Specs nicht gemacht.

Weil 8Bit nichts mit der Farbe zu tun haben.

Sieht so aus, als ob der Fx hier richtig liegt und du die Werte der anderen Browser anpassen musst.

Nix da. Wenn 32Bit drauf steht, sind auch 32Bit drin. ;)

eben, es sind keine 32Bit drin. wikipedia listet z.b. auch keine Farbtiefe mit 32Bit.

Statistiken sind doch zum Fälschen da (wie Opera 10, der sich immer noch als 9.80er ausgibt)...

Naja, ich halte die Information colorDepth, heutzutage für ziemlich entbehrlich.

Mein Opera hat diese Kennung:
Opera/9.80 (X11; Linux x86_64; U; de) Presto/2.6.30 Version/10.62

Da steckt zwar die Version drin, aber die meisten parser() nehmen die 9.80.

Struppi.

[Jean-Max]

Bounjoun Struppi,

eben, es sind keine 32Bit drin. wikipedia listet z.b. auch keine Farbtiefe mit 32Bit.

Wird zumindest als 24+8 erwähnt...

Da steckt zwar die Version drin, aber die meisten parser() nehmen die 9.80.

Mein Counter auch. Diesen Punkt muss ich noch ändern.

Adiou.

[Jean-Max]

Bounjoun Struppi,

Mein Opera hat diese Kennung:
Opera/9.80 (X11; Linux x86_64; U; de) Presto/2.6.30 Version/10.62
Da steckt zwar die Version drin, aber die meisten parser() nehmen die 9.80.

Opera liefert auch die Erklärung, warum die appVersion nicht Opera/10.xx ist:

http://dev.opera.com/articles/view/opera-ua-string-changes/

Wie dem auch sei, der Counter berücksichtigt jetzt diesen Umstand.

Adiou.

[Jean-Max]

Bounjoun Struppi,

Dann stimmt irgendetwas bei dir nicht. Ich bekomme in allen Browsern, die ich habe, 24Bit.

Argh, klar, wenn Du eine Farbtiefe von 24Bit auf deinem Monitor vermutlicherweise eingestellt hast.

Ich habe aber 32Bit eingestellt, und Firefox ermittelt es falsch (24). Die anderen Navis geben als Wert richtigerweise: 32.

Ich wüßte jetzt auch nicht woran das bei dir liegen könnte, aber eher nicht am Javascript.

Adiou.

[Struppi]

Argh, klar, wenn Du eine Farbtiefe von 24Bit auf deinem Monitor vermutlicherweise eingestellt hast.

Du hast vermutlich nicht mein anderes Posting gelesen?

Struppi.

[Jean-Max]

Bounjoun Struppi,

Du hast vermutlich nicht mein anderes Posting gelesen?

Das hatte ich in der Tat zunächst übersehen, sorry.

Adiou.