Montag, 2. Juli 2012

@#*!

Absoluter Frust ist das hier:
(1440, 'gildu8c3b3rion', ' tu8c3a0r-gildu8c3b3rion aus dem hause handu8c3a9riad 912 vhk - 104 hk u8c3bcber ihn ist auu8c39ferhalb der archive der lathildru8c3a0na nur wenig bekannt er war der zweite der hu8c3bcter des ileandron 702 vhk - 92 hk seelenjuwel#aus_dem_nachla c3 9f_eburacons verschiedene quellen deuten an in seiner zeit habe eine erneuerung des ileandron stattgefunden category historische persu8c3b6nlichkeit '),
Ein zerschossenes Wiki, eine komplette Weltkonkordanz. Die Tabellenstruktur ist hinüber, auch im Back-Up, das ist jetzt amtlich. Nicht mehr rekonstruierbar, die Datenbank. 

Mehr als 3000 Einträge, teils mehrere Seiten Text lang, sind zwar nicht beim Teufel, aber zumindest in der Vorhölle. Umlaute im Eimer, Verlinkungen im Eimer, Kategorisierungen im Eimer... Alles was bleibt, ist ein großer, zusammengematschter Textfile, in dem wenigstens alle Infos erhalten sind.

Auf, auf zur Datenarchäologie. *Kotz*

Kommentare:

Dennis hat gesagt…

Und wie ist das passiert?

Stefan hat gesagt…

War das eine Datenbank oder schon von vornherein eine Textdatei? Sind in der vorhandenen Textdatei noch alle Umlaute vorhanden? Kann man diese Datei mal sehen?

Adrian hat gesagt…

Die Umlaute wurden durch ihre Unicode-8 Äquivalente ersetzt, das lässt sich einfach beheben. Öffne die Datei mal mit N++ und versuche verschiedene Codierungen...

TheShadow hat gesagt…

@Denis. Wenn ichs nur wüßte. Das Wiki hat ein Freund betreut, der konnte die Rücksicherung nicht vollziehen, und mein Bruder, auch nicht eben ein Anfänger im Geschäft, befand die Tabellenstruktur im SQL-File für korrupt.

Passiert ist das out of the blue, nachdem das Wiki nach PHP 5.3-Update eine ganze Zeit stabil gelaufen ist.Ich hab davon nun deutlich weniger Ahnung, hab jetzt aber mal einen Apache-Server (Tomcat 6.3) hier aufgesetzt und versuchs selber trotzdem nochmal.

@Stefan: Das ist ein direkter Ausschnitt aus der SQL-Datei. da sieht aus genauso aus.

@Adrian. Dachte ich zuerst auch, aber das ist weder Unicode noch UTF-8/Unicode 8. Die Codierung für ö z.B. müßte "&#246" oder "\u00F6" sein, im korrupten File wird "ö" durch "u8c3b6" ersetzt, und dazu gibt Google mir nur vier sehr esoterische Treffer aus.

Stefan hat gesagt…

Was für ein Datenbankserver lief denn da? Und dieses SQL-File, ist das ein Dump?

TheShadow hat gesagt…

Apache 5.1.49
Der File selbst ist ein phpMyAdmin SQL Dump. Offenkundig ist irgendwas mit dem Zeichensatz im Ar...gen. Ich versuch schon den ganzen Tag über über MySQL wieder einzulesen, aber das funktioniert nicht, egal welchen Zeichensatz ich angebe.

http://www.schalen-des-zorns.de/Dump01.jpg

Stefan hat gesagt…

Könnte es sein, dass jemand den Dump mit einem Texteditor geöffnet hat und danach mit einem falschen Encoding wieder gespeichert hat? Und das unter Umständen mehrmals? Ich würde mir das mal anschauen, aber dazu bräuchte ich die Datei.

TheShadow hat gesagt…

Halte ich für eher unwahrscheinlich; ich hab den sql-File direkt aus dem Sicherungsarchiv genommen. Was Dein Angebot angeht, vielen Dank. Mail mich doch an (Hueter bei gmail.com).

Adrian hat gesagt…

Und, wie bist Du zurecht gekommen? http://www.utf8-zeichentabelle.de/ ist Dein Freund, die Codierung stimmt schon, nur jeweils das führende u8 weglassen...

Adrian hat gesagt…

Und hier: http://mysqldump.azundris.com/archives/60-Handling-character-sets.html

Stefan hat gesagt…

Ist meine Mail angekommen?

Kommentar veröffentlichen

Kommentare werden moderiert. Sorry.