Entries by Thomas Moenkemeier

Für alles mögliche verwende ich seit einige Zeit Serendipity. Das ist eigentlich ein Blog, aber ich verwende es mehr als CMS (Content Management System). Damit stelle ich ganz unterschiedliche Themen online, von den Notizen aus dem Geoinformatik-Studium bis zu POI in Berlin.

Wobei ich letztere gar nicht selbst eingebe, sondern über ein kleines PHP-Programm aus einer XAPI-Abfrage der OSM-Datenbank konvertieren lassen. Die meisten kennen nur die Karte von OpenStreetMap, aber da sind ja auch POI (Points Of Interest, Orte von Interesse) drin. Und da sind wir auch schon beim Thema SQL-Konvertierung.

Das war nicht schon immer so, dass ich alles mögliche mit S9y (wie die Software in Kurzform heißt) gemacht habe. Früher hatte ich auch mal eine Terminkalender-Software in Verwendung, deren Daten ich schon vor einiger Zeit mit ein paar SQL-Befehlen aus der mySQL-Datenbank-Tabelle in das Blog konvertiert habe.

Gestern war es mal wieder soweit. Das Update des FAQ-Systems phpMyFAQ ging schief und es tat sich gar nichts mehr. Wieder zurück zur alten Version, alles schick, nur das Update wollte nicht. Also schnell beschlossen: Die Geocaching-FAQ wird nun auch auf S9y umgestellt. Da weiß ich zumindest mittlerweile, wo welcher Knopf ist an dem ich drehen muss wenn mal was nicht will.

Ein Aufgabenstellung, die man öfter mal hat. Die Daten von einem System (hier wars nun eben zufällig phpMyFAQ) sollen in ein anderes (bei mir zumindest zur Zeit immer S9y) konvertiert werden - es gibt aber keinen fertigen Konverter.

Die Konvertierung von Daten auf dem SQL-Server ist dabei ziemlich einfach, wenn man sich die Datenbanken in den beiden Systemen anguckt. Und unter der Voraussetzung, dass bei beiden Systemen das Encoding richtig eingestellt ist, also ISO-Latin oder UTF8. Das ist dann der Fall, wenn man die Inhalte in den Tabellen einwandfrei lesen kann, sprich: Die Umlaute stimmen.

Für alle die es interessiert, gehe ich hier den Ablauf mal durch, der als Beispiel für alle Konvertierungen dieser Art dienen kann.

insert into serendipity_entries (id, title, body, extended, author, timestamp) SELECT id, keywords as title, thema as body, content as extended, author, links_check_date as timestamp FROM phpmyfaq_faqdata

Man fängt am besten hinter dem Select an zu lesen. Die Einträge aus der FAQ werden dazu ausgewertet, alle Felder die in dem Blog benötigt werden werden mit einem Alias ausgewählt, wie er in dem Blog heissen soll. Dort werden sie dann auch mit der Einfügeabfrage reingeschrieben.

insert into serendipity_authors (realname, username, email) select author as realname, author as username, email from phpmyfaq_faqdata group by email

Hier wird eine Benutzertabelle aufgebaut. Die brauche ich in den Blog zwar nicht, aber so kann man das machen. Einloggen können die sich mangels Passwort schon nicht. Die User-ID bekommen die Benutzer im Blog durch das Autoincrement, Benutzer gabs in der FAQ nicht, man konnte mit Name und E-Mail seinen Beitrag dort abliefern.

insert into serendipity_category (categoryid, category_name, category_description) SELECT id as categoryid, name as category_name, description as category_description FROM phpmyfaq_faqcategories

Die Kategorien aus der FAQ werden dann so 1:1 in das Blog konvertiert - sehr unspektakulär.

insert into serendipity_entrycat (categoryid, entryid) SELECT category_id as categoryid, record_id as entry_id FROM phpmyfaq_faqcategoryrelations

Bei wohl allen Systemen dieser Art gibts dann eine n:m-Relation zwischen Artikeln und Kategorien. Das kann auch so direkt konvertiert werden. Die Felder heißen nur unterschiedlich, aber dafür kann man ja den passenden Alias hinter "as" verwenden.

update serendipity_entries set authorid=1
update serendipity_entries set exflag=1
UPDATE serendipity_entries SET isdraft = 'false'

Damit die Beiträge auch angezeigt werden, müssen noch ein paar Felder in dem Blog gesetzt werden, die beim Füllen der Tabelle nicht berücksichtigt wurden. Hätte man auch gleich machen können, aber dann wäre die Einfügeabfrage etwas unübersichtlicher geworden.

insert into serendipity_comments (entry_id, author, email, body, timestamp) SELECT id as entry_id, usr as author, email, comment as body, datum as timestamp FROM phpmyfaq_faqcomments

Auch die Kommentar aus der FAQ sollen als Kommentare im Blog verwendet werden. Kein Problem, die Felder gibts in beiden Systemen. Sogar die Timestamps sind auf beiden Systemen Unix-Sekunden, falls das nicht so ist kann man schon beim Select die Timestamp-Funktion vom SQL verwenden um andere Datumsangaben zu konvertieren.

update serendipity_comments set type="NORMAL"
update serendipity_comments set status="approved"

Damit die Kommentare auch korrekt angezeigt werden, müssen nur noch ein paar Attribute korrigiert werden. Das wars dann auch schon.

So eine Sammlung von Abfragen kann man dann immer wieder verwenden, wenn man sie einmal erstellt und getestet hat, um Daten von einem System in ein anderes zu konvertieren. Wer lange genug mit Computern zu tun hat, wird wissen warum: Der Zeitpunkt, von einem System auf ein anderes zu wechseln wird immer kommen, die Frage ist nicht ob, sondern wann.

Schon in Gründerzeiten des WWW, also dem Teil des Internets mit den HTML-Seiten, haben sich die Erfinder von Netscape die Cookies (RFC2019) ausgedacht. Eine Profildatei, die der Browser lokal bei sich abspeichert. In dieser Datei sind kleine Datenmenge abgespeichert, die einer bestimmten Domain zugeordnet und von dem Webserver dieser Domain auch transparent wieder verwendet werden.

Der Cookie hat einen Namen und einen Inhalt, das kann sowas sein wie die Kundennummer oder eine Kombination aus Benutzer und Passwort. Da könnte man nun viel zu schreiben, aber es ist jedenfalls in den meisten Fällen so, dass einen der Server durch das Cookie wieder erkennt. Wozu das dann verwendet wird, ist der Kreativität der Programmierer überlassen.

Meist sind es Shops, die sich so an den vorigen Einkauf erinnern und passende Produkte vorschlagen, die einem noch interessieren könnten. Ein verbreiteter Mißbrauch dagegen ist es, Benutzerprofile über das Surfverhalten eines Benutzers zu erstellen. Zwar kann ein Shop nur das Surfverhalten innerhalb seiner eigenen Webseite verfolgen, aber in eine Website von einem anderen Server eingebundene Objekte setzen auch gern Cookies für fremde Werbepartner. Und da hört für viele der Spaß auf, insbesondere dann, wenn die Kekse ewig haltbar sind!

Als Gegenmaßnahme bieten Browser an, alle Cookies nur nach Genehmigung zu setzen oder nur für bestimmte Domains zu erlauben. Meist kommt man auch ohne sie recht gut aus. Allerdings ist es bei der verbreiteten Foren-Software phpBB so, dass die Cookies verwendet werden, um die Anmeldung (Benutzername und Passwort) zu speichern. So muss man sich nicht jedesmal wieder neu einloggen.

Dazu bekomme ich zu meinen beiden Communities Linux-Club und Geoclub regelmäßig Anfragen, wieso das Einloggen nicht mehr funktioniert. Genauer: Man kann sich zwar anmelden, aber bei der nächsten Seite ist man sofort wieder abgemeldet. Es sind unterschiedliche Browser (Firefox, Explorer, Opera...) mit denen das passiert, aber immer sind die Cookies anscheinend das Problem.

Ich habe noch nicht herausgefunden, worin das Problem genau besteht, vielleicht weiß da ja auch jemand besser Bescheid. Auf jeden Fall hilft es alle Cookies im Browser zu löschen und den Browser neu zu starten. In wenigen Fällen soll es erforderlich gewesen sein, auch den Browser-Cache zu löschen. Danach klappt auch wieder sofort alles: Einloggen und angemeldet bleiben.

Noch ein abschließender Hinweis: Wenn man an einem allgemein zugänglichen Computer arbeitet, kann es sein dass der Administrator mitgedacht hat und generell keine Cookies akzeptiert. So wird verhindert, dass ein Benutzer versehentlich angemeldet bleibt und der Nächste mit dem Konto des Vorgängers arbeitet. Weil man sich da aber nicht sicher sein kann, sollte man auf solchen Rechnern am Ende immer alle privaten Daten löschen (Firefox: Strg-Umschalt-Entf).

Das Video-CD-Format ist schon ziemlich alt und von der Qualität her so wie ein guter alter VHS-Videorecorder. Aber diese Scheiben haben einen großen Vorteil: Sie laufen auf jedem DVD-Player, den man sich an die Glotze anschließen kann. Die besseren Formate wie DivX oder H264 können meist nur die 50-Euro-Dinger aus dem Kaufhaus.

Ich hatte grad mal Bedarf ein YouTube-Video für jemand ohne Internet (das gibts auch noch) auf eine CD zu brennen, so dass es ohne viel Knöpfchendrücken abspielbar ist. Da kam mir diese nicht mehr ganz zeitgemäße Video-CD gerade recht. Keine Menüs auswählen, einfach CD rein und spielt ab, so wie man das von Audio-CDs auch kennt.

Als zertifizierter Linuxer natürlich Oldschool Commandline, und das geht erstaunlich einfach musste ich feststellen. Ich hatte mit umfangreichen Parameter-Orgien gerechnet, aber das ist nur bei der Formatkonvertierung erforderlich wenn man dem mencoder verwendet. Der hat dafür den Vorteil alles konvertieren zu können was der mplayer abspielt und das dürfte bei korrekter Installation so wirklich jedes Video sein, das man sich irgendwo runterladen kann.

Das bedeutet auch, dass man mit dem Weg, den ich hier in diesem Artikel notiere damit ich bei Bedarf noch mal drauf zurückgreifen kann so ziemlich jedes Filmchen auf Video-CD brennen kann. Das hätte ich bei meiner alten Digitalkamera auch schon gebrauchen können, die nämlich relativ exotisches (die Mac-User mögen es mir nachsehen) Quicktime-Video erzeugte. Eine Alternative für die Konvertierung wäre noch der ffmpeg, der einfach eine Option target=vcd hat, aber bei einigen Video-Formaten auch gern mal zickt.

Natürlich braucht man die bei YouTube übliche FLV-Datei auf der Platte, es kann auch die bessere MP4-Datei sein, dafür gibts schon diverse Tools um sich den Film von YouTube oder ähnlichen Video-Portalen herunterzuladen. Einige Portale bieten den Download sogar direkt an.

Die eigentliche Umwandlung macht ein etwas unhandlicher Aufruf von mencoder, den ich mir aus der mplayer-Doku kopiert habe:

mencoder -oac lavc -ovc lavc -of mpeg
-mpegopts format=xvcd -vf scale=352:288,harddup
-srate 44100 -af lavcresample=44100
-lavcopts vcodec=mpeg1video:keyint=15:vrc_buf_size=327:
vrc_minrate=1152:vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224
-ofps 25 -o videocd.mpg hirschhausen.flv

Damit (alles in eine Zeile natürlich!) wird eine Datei mit dem phantasielosen Namen videocd.mpg erzeugt. Wer kreativer ist oder mehrere Dateien konvertieren möchte sieht auch hier sofort was zu tun ist. Die Optionen stehen vorne um über die History der Shell schnell andere Dateien zu verarbeiten.

Danach wird ein Image für die Video-CD gebacken:

vcdimager videocd.mpg

Man kann dem vcdimager auch mehrere Videodateien im passenden Format vorwerfen. Bei den aktuellen Preisen für leere CDs mach ich das aber nicht. Die Defaults passen und weitere Optionen sind nicht erforderlich.

Das erstellte Image kann man dann mit cdrdao auf eine CD brennen:

cdrdao write videocd.cue

Auch hier sind in meinem Fall keine Optionen erforderlich, weil es einen symbolischen Link /dev/cdrecorder bei mir gibt, der korrekt auf /dev/sr0 zeigt.

Das wars schon. Die Dateien lassen sich danach mit rm videocd* einfach alle wegräumen. Ich hab mir die Schritte in ein Skript flv2vcd.sh geschrieben das auch im Downloadbereich bereitliegt. Nun hab ich von der Qualität eines YouTube-Videos auf dem Pantoffelkino keine Wunder erwartet, aber die Qualität ist für mich als aus der Generation Videorecorder sogar noch akzeptabel.