Seite 1 von 1
Formulare ausfüllen auf Webkit-Basis
Verfasst: Samstag 16. Mai 2009, 11:49
von 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)
Verfasst: Sonntag 17. Mai 2009, 12:00
von 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)
Verfasst: Dienstag 19. Mai 2009, 12:35
von 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?
Verfasst: Dienstag 19. Mai 2009, 16:01
von snafu
Es sagt: ISO-8859-1
Verfasst: Dienstag 19. Mai 2009, 16:11
von 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.
Verfasst: Dienstag 19. Mai 2009, 16:51
von 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?
Verfasst: Dienstag 19. Mai 2009, 20:47
von 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:
Gerade gefunden:
http://channel.debian.de/faq/ch-bugs.html Ist das vllt. die Ursache?
Verfasst: Dienstag 19. Mai 2009, 22:35
von 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.
Verfasst: Dienstag 19. Mai 2009, 22:53
von 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:
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.
Verfasst: Dienstag 19. Mai 2009, 23:01
von 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.

Verfasst: Samstag 6. Juni 2009, 20:43
von 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
Verfasst: Samstag 6. Juni 2009, 21:55
von Leonidas
Kompilieren vergessen?
Verfasst: Sonntag 7. Juni 2009, 13:47
von 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!

Verfasst: Sonntag 7. Juni 2009, 13:55
von 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.
Verfasst: Sonntag 7. Juni 2009, 17:44
von INFACT
Das würde auch funktionieren...
Aber bei allen dateien die ich downloade, ist nichtmal eine setup.py datei dabei

Verfasst: Sonntag 7. Juni 2009, 17:52
von Leonidas
Bei PyGtkWebKit müsste es wohl ``./configure``, ``make`` und ``make install`` sein, bei jswebkit ist doch eine ``setup.py`` drin.
Verfasst: Sonntag 7. Juni 2009, 17:57
von 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.

Verfasst: Freitag 12. Juni 2009, 10:05
von 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!
Verfasst: Freitag 12. Juni 2009, 16:42
von 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.
Verfasst: Samstag 27. Juni 2009, 17:52
von 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.