Das ist mal ein user-agent

Ich habe mich inzwischen daran gewöhnt, dass ein gutes drittel meiner normalen blogleser über tor kommt und nebenbei auch noch alle möglichen weiteren informationen unkenntlich macht. Dass die statistiken ihre aussagekraft verlieren, zeigt mir vor allem, dass die erbsenzählerei von zugriffen auf eine webseit nicht zum wichtigsten gehört. Aber wenn jemand besonders kreativ vorgeht, freue ich mich immer wieder darüber.

Heute hatte ich einen zugriff, dessen "brauser" (natürlich der proxy, ich weiß doch) als user-agent nicht "das übliche" über sich selbst angab, sondern sehr kreativ behauptete, er sei ein "ELV-LS50-Loetkolben".

Zum brüllen komisch, diese vorstellung…

Ein tag mit python und \w

Ich halte python ja für eine größtenteils gut brauchbare programmiersprache, aber manchmal möchte ich den ganzen schrott direkt in die hölle schicken. Zum beispiel gestern, als ich meinen tag verschwendete.

Gestern hatte ich eine etwas seltsame idee für ein künstlerisches projekt. (Es wird noch nichts verraten) Um diese idee umzusetzen, brauchte ich wortlisten, die ich aus den texten von webseiten erzeuge. Den allerersten prototyp habe ich noch in perl geschrieben (ohne ihn richtig auszuarbeiten), und um an die webseiten zu kommen, "missbrauchte" ich den treuen lynx, den besten brauser und reiniger des internetzes aller zeiten.

Nun, als ich sah, dass das konzept funktzjoniert, machte ich mich an die richtige umsetzung. Dafür nahm ich lieber python, weil ich davon ausgehe, dass ich das programm auch in einem jahr noch pflegen und deshalb auch noch verstehen muss. Perl ist zwar schön und unersätzlich für den schnellen häck, aber für etwas größere aufgaben nicht unbedingt die sprache meiner wahl, da die syntax nicht gerade unmittelbar verständlich ist. Ich habe sogar einmal geschrieben, dass ein perl-programm aussieht wie eine missglückte dateikonvertierung.

Und denn setzte ich mich daran, die ausgabe von lynx -dump in python zu parsen. Das erste problem bestand darin, URLs zu erkennen, was mit einem einfachen regulären ausdruck gut gelang. Denn URLs sind keine normalen texte und sollen deshalb auch nicht in der wortliste erscheinen.

Das zweite problem bestand darin, wörter zu erkennen. Wörter sind ja eigentlich zusammenstellungen von alfabetischen zeichen, was mich zur erkennung durch re.compile(r'\w+') brachte. Leider hatte ich meine rechnung ohne python gemacht, denn ein umlaut ist kein alfabetisches zeichen, \w meint also nichts anderes als [a-zA-Z].

Ein blick in die dokumentation offenbarte mir schnell, dass ich dem ausdruck beibringen kann, die aktuelle locale zu berücksichtigen. Dazu ist das flag re.LOCALE zu benutzen. Also habe ich flugs einen import locale und ein locale.setlocale(locale.LC_ALL, '') in mein gehäcksel eingefügt. Die folge war, dass \w immer noch [a-zA-Z] meinte, wofür soll da die locale gut sein. Ich saß beim Frank, als ich häckte, und er schaute beunruhigt nach mir, als ich böse verwünschungen gegen mir persönlich unbekannte programmierer aussprach.

Auch der nächste weg, den ich beschritt, brachte keinen erfolg. Ein regulärer ausdruck kann auch unicode verarbeiten, wenn man ihm das Flag rc.UNICODE gibt. Nun, unicode beherrscht ein ausgereiftes system, zeichen zu klassifizieren, das wird der ausdruck doch denn wohl anwenden können. Dachte ich…

Natürlich musste ich meiner eingabedatei (eine pipe auf lynx) noch ein codec spendieren, damit sie auch wirklich unicode erzeugt. Natürlich habe ich das beim ersten testlauf vergessen. Aber das ist normal, war schnell erkannt und leicht behoben. Und dann stellte ich zu meinem bitterem gallensaft fest, dass \w auf einmal deutlich erweitert war, sogar die umlaute gingen. Aber solche zeichen wie ein asterisk oder ein typografisches anführungszeichen galten auf einmal als alfabetische zeichen, als buchstaben. Und damit war auch dieser weg unbrauchbar.

Ich habe zwischendurch beim strokeln sogar auf das parsen mit einem regulären ausdruck verzichtet und die wörter mit einer kleinen funktion zu filtern gesucht, um die angaben aus der datenbank im modul unicodedata direkt zu verwenden. Das hätte funktioniert, wenn typografische anführungszeichen darin nicht als buchstaben aufgetreten wären. HASS!

Am ende meiner mühen, am ende meines tagesausfluges in die python-dokumentazjon und am ende des tages stand dann die blödeste lösung, die ich mir nur vorstellen kann. Ich habe eine zeichenkette mit erlaubten zeichen, die ich einfach in den ausdruck aufnehme. Und wenn einmal ein wirklich ungewöhnliches zeichen dazwischen kommt (zum beispiel so ein durchgestrichenes "ł" aus einem polnischen namen wie Stanisław), denn versagt meine jetzige implementazjon eben.

Denn fürs erste will ich diesen scheiß nicht mehr sehen!