Formulare ausfüllen auf Webkit-Basis

[snafu]

Hi,

hier ein paar Zeilen, um bei Google eine Suchanfrage abzuschicken. Die API zum Ausfüllen der Felder werde ich noch verbessern. Ich habe auch noch nicht getestet, ob das bei Seiten, wo man sich einloggen muss, klappt.

Abhängigkeiten:

- PyWebKitGtk (z.B. in Debian Testing/Unstable als `python-webkit` oder von der Projektseite)

- jswebkit (gibt es hier)

[snafu]

Falls das jemand mal ausprobiert hat: Kann ich das Problem ab Zeile 61 besser lösen? Ein `encode('utf-8')`, wie ich es bei der Ausgabe des DOM-Trees mache, hatte nichts gebracht. Es wurde weiterhin der selbe Fehler geworfen:

Code: Alles auswählen

UnicodeEncodeError: 'latin-1' codec can't encode character u'\u25bc' in position 47: ordinal not in range(256)

[jerch]

Hm, sicher das die Fehlermeldung überhaupt mit dem encode('utf-8') korrespondiert? Der Fehlertext bezieht sich doch auf 'latin-1'.

Ich weiß nicht, wie PyWebKitGtk mit den Encodings umgeht, daher folgender Hinweis: Standardencoding des HTTP 1.1 ist latin-1, wird das zu keiner Zeit anders deklariert (via http-header, doc-head oder Festlegung wie bei XML), wird 'latin-1' angenommen. Da halten sich zumindest die "großen" Parser dran (der IE versucht wohl noch das encoding zu raten, wenn nicht definierte Zeichen ankommen).

Was spuckt denn ein sys.stdout.encoding bei Dir aus?

[snafu]

Es sagt: ISO-8859-1

[jerch]

Damit ist klar, das er bestimmte Zeichen garnicht ausgeben kann. Hier könnte Dir ein encode('latin-1', 'ignore') oder encode('latin-1', 'replace') weiterhelfen. Ersteres "vergißt" einfach das Zeichen, zweiteres setzt ein '?' an die Position des unbekannten Zeichens.

Welche Pythonversion nutzt Du und welches OS? In der Linuxwelt ist eigentlich schon länger 'utf-8' gebräuchlich, unter WindowsXP irgendeine Codepage (850 oder 1252, weiß ich grad nicht genau.) Wobei cp1252 sich stark an latin-1 anlehnt.

[snafu]

Python 2.5.4 auf Debian Testing.

EDIT: Ich habe jetzt mal in `Konsole` die Kodierung auf Utf-8 umgestellt, führt aber zum selben Fehler.

Aber vermutlich ist das eher von der Einstellung im Interpreter abhängig, oder? Wie stelle ich das denn um?

[jerch]

Was zeigt denn `locale` an?

Python setzt das encoding für stdout nach den locale-Einstellungen (LC_CTYPE). Das kannst Du testen, indem Du Python vor Aufruf an der Konsole einen anderen Typ unterschiebst. Daher reicht es nicht, die Konsole auf 'uft-8' einzustellen, sondern Du müßtest eine 'utf-8'-Charmap als LC_CTYPE setzen.

Mich wundert an dieser Stelle, daß das bei Dir nicht der Vorgabewert ist. Mit Deiner Einstellung dürften nämlich auch andere Programme Ausgabeschwierigkeiten an der Konsole haben, da 'utf-8' unter Linux als Quasistandard angekommen ist.

Falls was mit Deiner locales-Installation nicht stimmen sollte:

Code: Alles auswählen

dpkg-reconfigure locales

Gerade gefunden: http://channel.debian.de/faq/ch-bugs.html Ist das vllt. die Ursache?

[snafu]

Diese 3 Sachen waren schon vorher angewählt und ich hab sie so gelassen:



Danach habe ich als Standard das mit UTF-8 gewählt. Aber selbst nach einem Neustart der Shell spuckt `sys.stdout.encoding` das selbe Ergebnis aus.

`locale` sagt:

Code: Alles auswählen

LANG=de_DE
LC_CTYPE="de_DE"
LC_NUMERIC="de_DE"
LC_TIME="de_DE"
LC_COLLATE="de_DE"
LC_MONETARY="de_DE"
LC_MESSAGES="de_DE"
LC_PAPER="de_DE"
LC_NAME="de_DE"
LC_ADDRESS="de_DE"
LC_TELEPHONE="de_DE"
LC_MEASUREMENT="de_DE"
LC_IDENTIFICATION="de_DE"
LC_ALL=

EDIT: Hö? Ich habe auf jeden Fall utf-8 angewählt als Standard.

Naja, ich habe jetzt meiner `.bashrc` ein `LANG=de_DE.UTF-8` verpasst und die Kodierung in der Konsole auf UTF-8 umgestellt. Optimal ist das aber sicher nicht...

EDIT2: Gemäß diesem Abschnitt habe ich das ganze nochmal umgestellt, auch wenn es noch keine `/etc/environment` bei mir gab.

[jerch]

Dann weiß ich auch nicht weiter, es sollte eigentlich mit mit der Standardeinstellung auf 'de_DE.UTF-8' funktionieren. Welches encoding hast Du, wenn Du python mit:

Code: Alles auswählen

LC_CTYPE="de_DE.UTF-8" python

startest?

Meine `locale`-Ausgabe:

Code: Alles auswählen

LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Edit: Ja das 'de_DE' steht für das ISO Charmap. Da sollte eigentlich 'de_DE.UTF-8' stehen.

[snafu]

Dann klappt es. Es klappt aber auch mit der gerade erwähnten Einstellung. Naja, halt etwas blöd. Lieber wäre mir eine systemweite Umstellung, die zudem ohne händisches Gefummel funktioniert.

EDIT: Ach Quatsch. `/etc/profile` gilt ja systemweit.

Dann mal danke für die Hilfe. Sollte ja jetzt gehen.

[INFACT]

Ich habe mir das hier gerade durchgelesen und wollte das auch mal probieren.
Mein Problem liegt darin, dass ich windows nutze und dadurch das jswebkit nur mit winrar öffnen kann und nicht weiß wohin ich das entpacken kann.
Wohin muss ich das denn entpacken?

Edit: das selbe problem habe ich mit PyWebKitGtk,
wenn ich das in lib\site-packages entpacke klappt das nicht.
Habe ich was falsch gemacht?
Edit: Ich kann nichts davon downloaden.
Ich glaube ich bin zu doof

[Leonidas]

Kompilieren vergessen?

[INFACT]

Wie kompiliert man das denn?
Muss ich jede einzelne c datei SO kompilieren? Das dauert jahre. Zumal ich das mit 3 Modulen machen muss!

[Leonidas]

Bei richtig eingerichtetem Compiler sollte es mit einem ``python setup.py install`` für jedes zu installierende Package getan sein. Aber unter Windows ist eh alles unnötig kompliziert.

[INFACT]

Das würde auch funktionieren...
Aber bei allen dateien die ich downloade, ist nichtmal eine setup.py datei dabei

[Leonidas]

Bei PyGtkWebKit müsste es wohl ``./configure``, ``make`` und ``make install`` sein, bei jswebkit ist doch eine ``setup.py`` drin.

[snafu]

Ich bin jetzt etwas tiefer in die Materie eingestiegen (auf Webkit-GTK-Basis in C). Webkit nutzt wohl im Hintergrund eine SoupSession (gemeint ist natürlich libsoup und nicht BeautifulSoup).

Es gibt in einer aktuellen Version (die aus Debian unstable bzw dem nächsten Ubuntu -> `libwebkit-dev`) die Möglichkeit, die aktuelle Session zu erhalten (`webkit_get_default_session()`) und mit der Soup-Bibliothek weiterzuverarbeiten. Ich arbeite mich da gerade ein, weil ich darin eine hervorragende Möglichkeit sehe, einigermaßen sauber an den aktuellen Stand im Browser zu kommen.

Den umgekehrten Weg ("eigene" SoupSession in WebView ausführen) habe ich in der API nicht gefunden. Wenn ich soweit bin (das kann noch etwas dauern), werde ich die Entwickler aber eventuell mal diesbezüglich anschreiben.

Als Fernziel plane ich, `urllib2`-kompatibel zu sein. Es soll nicht die selbe API werden, aber das Modul soll dann in der Lage sein, bespielsweise einen `urllib2`-Request zu verstehen (nennen wir die Methode mal `from_urllib2()`) und durchzuführen (dabei kümmert sich Webkits (JS-)Engine um den Code) und den Response auf Wunsch wieder zurück in eine `urllib2`-Klasse zu konvertieren.

Wenn alles glatt geht, könnte man das dann prima mit `mechanize` kombinieren.

[INFACT]

Ich glaube ich bin einfach zu doof dazu.
Ich habe dann doch noch was anderes gefunden. Mir geht es ja nur darum forms auszufüllen.
http://wwwsearch.sourceforge.net/ClientForm/

Trotzdem danke!

[snafu]

Ja, falls du noch ein bißchen mehr machen willst, kannst du sogar besser auf mechanize zurückgreifen, welches ClientForm integriert und sein Projekt unter der selben Domain hat. Mir ging es vornehmlich darum, Javascript von Seiten ausführen zu können. Da ist Google natürlich kein gutes Beispiel.

[snafu]

Hier mal eine kleine Spielerei, die Zugriff auf `document.links` gibt, indem sie es einfach selbst implementiert. Derzeit noch relativ schwachsinnig, aber ein erster Schritt, um Webkits JSEngine in Verbindung mit Webseiten zu nutzen, ohne dass eine GUI laufen muss. (EDIT: Die LC in Zeile 15 macht man natürlich besser über einen Generator)

Das `jscore` gibt es hier.

Ich weiß jetzt nicht, wie umfangreich und performant es wäre, wenn man tatsächlich `document` komplett selbst einbaut. Praktisch wäre es ja schon irgendwie.

Fernziel soll u.a. sein, genauer herauszufinden, was einzelne Funktionen von Webseiten machen. Ich denke, es ist hiefür elementar, dass der JSCode eben auch auf Dinge wie `document` und `window` zugreifen kann.

Ich hoffe auch, dass der Autor von `jscore` noch ein paar weitere Features einbaut, damit man Dinge wie Arrays ein bißchen schöner erzeugen kann.