Menü

Login

Aktuelle Version

Forum > Keine Anzeige von Umlauten nach SQL Import *

DOTLAN Intranet / Portal >> Probleme und Fehler > Keine Anzeige von Umlauten nach SQL Import
Antwort erstellen
Autor Thema: Keine Anzeige von Umlauten nach SQL Import
ID744601
25.01.2006 um 23:15 QuoteProfileSend PM
NEW

Clan: sleepless-lan.net
Postings: 56

744601
bei unserer letzten Veranstaltung (http://www.dot-lan.at) war es leider der Fall, dass nach dem Übertragen der Daten aus dem Internet ins Intranet, keine Umlaute mehr angezeigt wurden.

Woran kann das liegen?
 
Griffon
25.01.2006 um 23:46 QuoteProfileSend PM

NEW

Clan: dotlan.net
Postings: 1252

Siehe Probleme beim DB Import

Das Problem ist bei phpMyAdmin zu suchen. Wenn ihr Daten im Format ISO8859-15 exportiert, beim Import aber angebt das es sich um eine UTF-8 Datei handelt, kommt es zu solchen Zuständen.

Der einfachste Weg ist es die Daten via Console zu importieren oder einfach beim Import die richtige Codepage zu wählen.
 
ID744601
26.01.2006 um 08:34 QuoteProfileSend PM
NEW

Clan: sleepless-lan.net
Postings: 56

744601
hm beim export kann ich gar kein Dateiformat auswählen und beim Import gibt es ziemlich alles, bis auf ISO8859-15
 
DerMega
26.01.2006 um 09:27 QuoteProfileSend PM
NEW

Clan: Mitten aus Deutschland e.V.
Postings: 438

Megaaaaa
griffon hat folgendes geschrieben:
Es ist kein Fehler beim Export der Daten sondern beim Import. Standardmäßig steht Zeichencodierung auf UTF-8 Importiert ihr jetzt eure Exporte, dann werden die Daten in UTF-8 umgewandelt was die Sonderzeichen zuerstört. Einfach beim Import via phpMyAdmin den Zeichensatz cp850 (Codepage 850, das ist der euro Standardzeichensatz von Windows/Dos), auswählen. Dann sollten die Daten unverändert hochgeladen werden. Besser wäre der Import über die Console mit dem mysql befehl.


 
ID744601
26.01.2006 um 11:43 QuoteProfileSend PM
NEW

Clan: sleepless-lan.net
Postings: 56

744601
danke sehr
 
Nick
06.02.2006 um 15:43 QuoteProfileSend PM
NEW

Clan: Kein Clan
Postings: 43

da der lösungsthread ja leider zu ist, poste ich das mal hier:
ich hab die datenbank (1.0.1a) exportiert und nacheinander in utf8, cp850, cp1250 und latin1 importiert - keine umlaute, nur fragezeichen...
(nach dem reimport hab ich noch das update auf 1.2 mit jeweils demselben zeichensatz drübergebügelt).

wobei bei latin1 nicht fragezeichen sondern irgendwelche sonstige zeichen kommen.

was kann da noch falsch sein?
 
Sorehead
06.02.2006 um 23:48 QuoteProfileSend PM
NEW

Clan: Gamesession Hannover
Postings: 348

Ich hab das Problem mit der Version 1.2.2 auch...
 
Sorehead
07.02.2006 um 11:31 QuoteProfileSend PM
NEW

Clan: Gamesession Hannover
Postings: 348

Hmm, schade kein "edit".. Naja..

Wie dem auch sei. Ich habe die Version 1.2.2 frisch aufgesetzt und nur die Daten importiert (das sql-dump war zwar älter, hat aber bei der vorherigen Version tadellos funktioniert).

Nun habe ich wie gesagt auch das Problem mit den Umlauten. Weder cp850 noch utf8 ändert was.

Weiß jemand Rat?
 
Sorehead
08.02.2006 um 07:31 QuoteProfileSend PM
NEW

Clan: Gamesession Hannover
Postings: 348

Hat sich erledigt...

Ein Import auf der Konsole mit anschließendem refresh hat funktioniert.
 
Nick
08.02.2006 um 18:17 QuoteProfileSend PM
NEW

Clan: Kein Clan
Postings: 43

konsole hab ich bei hosteurope nicht...

hab erstmal 1.0.1 zurückgespielt.

ich bruach ja zum glück nicht unbedingt die neuen funktionen.
 
Griffon
09.02.2006 um 01:29 QuoteProfileSend PM

NEW

Clan: dotlan.net
Postings: 1252

Um auf das Problem von Sorehead zurückzukommen. Nach mehrfachem Import hatte sich herausgestellt das der Cache nicht geleert wurde. So hatte sich die Startseite (News) in dem Falle nicht geändert und man hatte gedacht das sich nichts getan hat.

C.Z.I: Du kannst gerne downgraden. Aber ich betone nochmal meine Meinung dazu: DOTLAN ist selbst davon nicht betroffen. Das Problem liegt allein am Datenhandhabung. Sprich import/export. Der DOTLAN Version ist das egal in welcher Form die Daten vorliegen.
 
Nick
10.02.2006 um 15:48 QuoteProfileSend PM
NEW

Clan: Kein Clan
Postings: 43

hmm, am cache kanns eigentlich nicht liegen, weil wie gesagt die umlaute nicht immer "gleich falsch" dargestellt wurden, aber nie richtig.

und mit welcher codepage ich noch hochladen soll weiß ich wirklich nicht.

mit der alten gehts jetzt irgendwie auch nicht mehr.

bei ner anderen homepage, die auf demselben space läuft, gings auf anhieb.
 
Griffon
10.02.2006 um 21:36 QuoteProfileSend PM

NEW

Clan: dotlan.net
Postings: 1252

Klar läuft die alte Homepage nicht mehr, weil die Daten in der Datenbank durcheinander sind. Ich sag ja das es nicht am PHP Code liegt sondern an dem rumgefummel an der Datenbank beim mehrfachen export/import.
 
Nick
11.02.2006 um 20:20 QuoteProfileSend PM
NEW

Clan: Kein Clan
Postings: 43

also nochmal:

ich hab die daten EINMAL exportiert.
dann hab ich sie immer wieder importiert, um die codepages durchzuprobieren.

bei jedem reimport waren erstmal DROP TABLE IF EXISTS befehle drinn.

wie soll hier also was durcheinander geraten?
 
Griffon
12.02.2006 um 00:20 QuoteProfileSend PM

NEW

Clan: dotlan.net
Postings: 1252

Nächste Fragen. Waren die Daten OK als du die exportiert hast? Sind die Daten von deinem Export OK? Sind diese wirklich ANSI/ASCII oder etwa Unicode?

Hast du mal probiert die Daten via Console einzuspielen?

Code:
mysql -u username -p -D datenbankname < daten.sql


Das sollte definitiv funktionieren. Das hilft bei mir auch immer.
 
Nick
12.02.2006 um 14:30 QuoteProfileSend PM
NEW

Clan: Kein Clan
Postings: 43

also, wenn ich die SQL datei mit nem editor öffne, sind die daten alle ok.
der editor zeigt "ANSI" als kodierung an.

ich versuchs mal nochmal, damit hochzuladen.

ne konsole gibts bei hosteurope leider nicht


/EDIT:
das hochladen mit "ascii" hat auch nicht geklappt. ich hab jetzt einfach die gesamte datei als plaintext in den abfrageeditor kopiert, das hat hingehauen. (kein dateiupload)

beim request ist mit aufgefallen, dass es einen url-parameter bei phpmyadmin gibt, so in der art: utf8_connection=1 oder sowas.

das könnte allgemein das problem sein, dass nicht die abfrage oder der export schiefläuft, sondern der transfer der sql datei.

[Editiert von C.ZI am 12.Feb.2006 um 14:41]
 
[ Antwort erstellen ]