Seite 1 von 1
HTTP Ripper - Ein rippender HTTP Proxy [Neue Version 1.0.0]
Verfasst: Freitag 27. Juni 2008, 19:07
von veers
Was ist HTTP Ripper?
HTTP Ripper ist ein HTTP Proxy den ich für die Schule in Python geschrieben habe. Er ist dafür gedacht um Filme und Musik von Websiten zu downloaden (youtube, myspace, you name it). Wobei der HTTP Proxy Teil grundsätzlich generisch ist.
Website und download:
http://29a.ch/httpripper/
Source:
http://29a.ch/git/gitweb.cgi?p=httpripper;a=tree
Über Kommentare würde ich mich natürlich freuen
Gruss,
Jonas
Verfasst: Freitag 27. Juni 2008, 20:55
von Crazed
Gott...
Wie manche Leute sowas schaffen..
Funktioniert einwandfrei bei mir (Ubuntu 8.04) Installation ging auch völlig ohne Probleme, gut auch das man keine Admin Rechte brauch.
Danke für dieses geniale Tool!
MfG,
CracKPod
Auf deine TODO liste könntest du noch packen:
Live Filtern von Ergebnissen, d.h du gibst ein Teil des namens ein und dann werden nur noch alle Strings angezeigt die diesem entsprechen.
PS: Dürfte ich fragen wie lange du allgemein schon mit Python programmierst und wie lange du für den HTTPRIpper gebraucht hast?
Verfasst: Freitag 27. Juni 2008, 21:16
von veers
Crazed hat geschrieben:Live Filtern von Ergebnissen, d.h du gibst ein Teil des namens ein und dann werden nur noch alle Strings angezeigt die diesem entsprechen.
Ist bereits möglich - einfach tippen. Jedoch wird nur der Anfang geprüft. Könnte ich mal auf ein contains umbauen
Crazed hat geschrieben:
PS: Dürfte ich fragen wie lange du allgemein schon mit Python programmierst und wie lange du für den HTTPRIpper gebraucht hast?
Seit etwa 3 Jahren.
Wie lange ich daran hatte ist schwer zu sagen weil ich Primär nebenbei daran gebastelt habe. Die erste Version hatte ich nach einer guten Stunde. Vielleicht waren es auch zwei. Und dann wohl noch etwa 6 Stunden fürs Polieren, Dokumentieren, Website basteln etc.
Freut mich das es dir gefällt.
Gruss,
Jonas
Verfasst: Freitag 27. Juni 2008, 22:01
von nemomuk
Hab mal versucht es unter Windows zu installieren und bekomme immer folgenden Fehler auch nach mehrfacher Installation:
Code: Alles auswählen
Traceback (most recent call last):
File "httpripper", line 3, in <module>
File "httpripper\httpripper.pyo", line 54, in <module>
File "gtk\__init__.pyo", line 48, in <module>
File "gtk\_gtk.pyo", line 12, in <module>
File "gtk\_gtk.pyo", line 10, in __load
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.
Konnte das Problem auch schon lösen, indem ich die libpng12.dll in libpng13.dll umbenannt habe...
Verfasst: Freitag 27. Juni 2008, 22:14
von veers
Hi SchneiderWeisse,
Was für eine Windows Version verwendest du? Möglicherweise 98?
Verfasst: Freitag 27. Juni 2008, 22:15
von nemomuk
Konnte das Problem auch schon lösen, indem ich die libpng12.dll in libpng13.dll umbenannt habe...
Hab ich vorhin noch hinzugefügt...
Ich verwende XP,...
Verfasst: Freitag 27. Juni 2008, 22:24
von veers
SchneiderWeisse hat geschrieben:Konnte das Problem auch schon lösen, indem ich die libpng12.dll in libpng13.dll umbenannt habe...
Hab ich vorhin noch hinzugefügt...
Ich verwende XP,...
Das ist mutig
Die Änderung am Namen deutet nämlich stark auf ein geändertes Interface hin. Hab eine neue setup.exe erstell - die dll sollte nun enthalten sein.
Gibt es irgend einen weg (ala virtenv) das zu testen?
Verfasst: Freitag 27. Juni 2008, 22:29
von nemomuk
das war mir schon klar, aber "no risk, no fun"...^^
Das neue Setup funtkioniert nun einwandfrei, unterscheidet sich aber nicht von der Version mit verändertem Dateinamen...
Verfasst: Samstag 28. Juni 2008, 13:26
von Leonidas
veers, ich habe mir mal den Screencast angesehen und mich gewundert, warum er den Dateinamen nicht automatisch dekodiert.
Verfasst: Samstag 28. Juni 2008, 13:31
von veers
Leonidas hat geschrieben:veers, ich habe mir mal den Screencast angesehen und mich gewundert, warum er den Dateinamen nicht automatisch dekodiert.
Weil ich es für zu gefährlich empfand *g*. Aber du hast recht, das könnte ich noch sauber machen.
Verfasst: Sonntag 29. Juni 2008, 08:05
von sma
Hm, leider das falsche UI-Toolkit für OS X. Wäre wx keine Option gewesen? Extra nach einer GTK-Version suchen will ich auch nicht. So konnte ich mir nur den Screencast anschauen. Mein Vorschlag wäre, Ressourcen nach content type fillterbar zu machen, sodass man etwa alles was auf "text/*" oder "image/*" zutrifft ausfiltern zu können. Das macht die Liste der interessanten Ressourcen kürzer und man muss nicht argumentieren, dass meist das Längste das ist, was man sucht.
Stefan
Verfasst: Sonntag 29. Juni 2008, 12:08
von veers
sma hat geschrieben:Hm, leider das falsche UI-Toolkit für OS X. Wäre wx keine Option gewesen?
Nicht wirklich. Habe mal etwas mit WX gearbeitet und das ganze ist dabei des öfteren mit einer Speicherzugriffsverletzung gestorben. Aber ich denke er Erklärung warum ich GTK wx vorziehe würde den Umfang dieses Topics sprengen.
sma hat geschrieben:
Extra nach einer GTK-Version suchen will ich auch nicht. So konnte ich mir nur den Screencast anschauen.
Verständlich - GTK unter OS X ist machbar aber mühsam.
sma hat geschrieben:
Mein Vorschlag wäre, Ressourcen nach content type fillterbar zu machen, sodass man etwa alles was auf "text/*" oder "image/*" zutrifft ausfiltern zu können. Das macht die Liste der interessanten Ressourcen kürzer und man muss nicht argumentieren, dass meist das Längste das ist, was man sucht.
Die Idee gefällt mir. Wenn ich etwas Zeit dafür finde werde ich sie Umsetzen.
Vielen Dank für dein Feedback,
Jonas
Verfasst: Sonntag 29. Juni 2008, 15:40
von Leonidas
veers hat geschrieben:sma hat geschrieben:Hm, leider das falsche UI-Toolkit für OS X. Wäre wx keine Option gewesen?
Nicht wirklich. Habe mal etwas mit WX gearbeitet und das ganze ist dabei des öfteren mit einer Speicherzugriffsverletzung gestorben.
Ich muss zugeben, dass meine Erinnerungen auch so waren. Bei einigen Aktionen ist das Toolkit reproduzierbar gestorben. Es hieß dann immer dass es in der nächsten Version ausgebessert wird (leider hatten die damals sehr lange Releasezyklen), aber Freude stellt sich da leider trotzdem nicht ein.
Für platformunabhängige Sachen ist es ja nett, aber auch ich muss zugeben dass es unter Windows ausreichend gut läuft und Mac OS X einfach nicht meine Zielgruppe ist. Vielleicht wäre in dem Fall auch Qt vorzuziehen.
Verfasst: Sonntag 29. Juni 2008, 16:59
von lunar
Mehr als das Programm selbst (jamendo hat Torrents, und für youtube gibt's download helper
) interessiert mich gerade, wie du den Screencast aufgenommen hast ...
Verfasst: Sonntag 29. Juni 2008, 17:44
von veers
lunar hat geschrieben:Mehr als das Programm selbst (jamendo hat Torrents, und für youtube gibt's download helper
)
Waren auch nur Beispiele
lunar hat geschrieben:interessiert mich gerade, wie du den Screencast aufgenommen hast ...
Nach einigen fehlgeschlagenen versuchen mit xvidcap habe ich Istanbul verwendet
Verfasst: Montag 30. Juni 2008, 08:52
von Rebecca
ffmpeg kann auch screencasts, z.B:
Code: Alles auswählen
ffmpeg -r 10 -f x11grab -s 720x576 -i :0.0 -vcodec huffyuv -vtag HFYU capture.avi
Verfasst: Sonntag 31. August 2008, 20:11
von veers
Habe so eben eine neue Version veröffentlicht:
# 2008-08-31 New Version (Version 1.0.0)
* New Feature: Filtering (Filter by content type or file size)
* New Translation: Brazilian Portuguese by Alexandre Sapata Carbonell
* New Translation: French by Benjamin Kühnis
* New Translation: German by Jonas Wagner
* New Translation: Indonesian by Muhammad Zulfikar
* New Translation: Serbian by Vladimir Lazic
* New Translation: Spanish by Nicolas Giorgetti, Benjamin Kühnis
Für Kritik bin euch dankbar!
Jonas