Umlaute weg

[6legs]

Hallo Forum,

nachdem ich lokal mit MySQL5 arbeite, und versucht habe einen sql-dump auf einen webserver mit MySQL4 hochzuladen, sind die Umlaute verloren gegangen.
Ich weiss ja warum, aber gibt's da irgendeine Lösung, wie ich die 5er Umlaute doch noch in das 4er-System rüberholen kann 

Und gibt's zum Nikolaus eigentlich die nächste Beta? 

Gruß Bene

[HieblMedia]

Hallo,
ich denke mal du benutzt phpMyAdmin.
Hast du beim Export bei SQL-Export-Kompatibilität MYSQL40 ausgewählt? Wenn nicht dann versuchen.

[6legs]

Hallo und vielen Dank für die schnelle Reaktion.

php4 - Kompatibilität habe ich ausgewählt.

Wenn ich dann importiere komme ich mit den Zeichensätzen durcheinander.

Unter MySQL5 habe ich

  `type` varchar(10) collate latin1_general_ci

und unter 4 dann natürlich nur noch

  `type` varchar(10)

Ich muss doch irgendwie die Zeichensatzinfo rüberbringen könne, zur Not ja auch per Handeintrag, aber ich komme einfach nicht weiter.

Jetzt habe ich mir schon per suchen/ersetzen geholfen (wenn die Not am größten ist...), aber ich hätte gerne trotzdem eine Lösung für dieses dämliche Problem...

Wenigstens scheint mal gerade die Sonne 

Gruß Bene

[HieblMedia]

Code: Select all

php4 - Kompatibilität habe ich ausgewählt.

Ich meine nicht php4 sondern beim Exportieren vom MySQL Dump MYSQL40.
Oder hast dich da nur verschrieben?

Anbei mal ein Bild zur Verdeutlichung.

[6legs]

Ich war nur schreibfaul, meine aber das gleiche wie Du.

Beim dump muss ich ja MySQL4-Kompatibilität wählen, sonst kann ich unter MySQL4 garnix einlesen.

Mein Problem ist:

Beim Export einer MySQL5-DB ( UTF-8 mit Kollation latin1_general_ci ) ins 4er-Format gehen die Infos zum Zeichensatz verloren und damit meine Umlaute.
Wenn ich dann unter MySQL4 den dump importiere, sehe ich statt Umlaut die kryptischen UTF-8 Zeichen.

Gruß Bene

[HieblMedia]

Ok.
Kannst du den beim Importieren der SQL Datei die Zeichencodierung auswählen? Ich glaube das geht nicht immer je nach Provider und phpmyadmin Version.

[6legs]

Genau,

wenn der Provider noch kein MySQL5 anbietet, dann gibt es nach meiner Erfahrung auch keine Möglichkeit, in phpMyAdmin beim Import einen Zeichensatz auszuwählen.
Vielleicht einfach weil phpMyAdmin dann meist auch eine uralte Version ist.

Kann man das nicht manuell in der exportierten .sql-Datei nachtragen?
Oder den Export und die Format-/Zeichensatz-Umwandlung manuell und dafür korrekt statt mit Hilfe von phpMyAdmin durchführen.

Und wenn ja, wie geht das?

Mein Wissen von SQL geht leider stark gegen Null und vielleicht ist hier ja irgendjemand, der eine einfache Lösung hat.

Viele Grüße und schönes Wochenende,
Bene

[harryonline_at]

Hi!

Nebenbemerkung: Meistens kann das lokale, eigene phpMyAdmin mehr als das vom Webspaceprovider. 

Also, zum Transfer der eigenen, MySQL 5-Datenbank mit deutschen Sonderzeichen (Umlaute etc.) im Inhalt in die MySQL 4-Datenbank am Webserver folgende Einstellungen im lokalen phpMyAdmin tätigen:

1. MySQL 4 Kompatibilität auswählen
2. Zeichensatz iso-8859-1 auswählen
3. Für den Export auch die richtigen Anführungszeichen auswählen

Beim Einspielen auf den Webserver:

1. Wenn möglich, Zeichensatz iso-8859-1; läuft hier meistens auch unter Latin-1
2. Kann man überhaupt keinen Zeichensatz auswählen, geht das auch OK.

Das war's!

Beim Erstellen des DB Dumps für den Export immer den richtigen Zeichensatz auswählen, ansonsten hat man statt der deutschen Sonderzeichen kryptische Kasterln. Die MySQL 4/5-Kompatibilitätsfrage betrifft den MySQL-Befehlscode im DB Dump. Eine Fehleinstellung in beiden Angelegenheiten führt meistens dazu, dass sich der Datenbankinterpreter verhaspelt und primär irgendwo ein entscheidendes, falsch vorkommendes Anführungszeichen als Fehlerquelle behauptet, sofern nicht gleich die Fehlermeldung mit der falschen Syntaxversion kommt.

LG Harald

[kickme]

Guten Tag,
ich habe ein ähnliches problem.
wenn ich meine Homepage aufrufe ist erst alles i.o.
wenn ich die seite refreshe sind die umlaute weg.
in dem www ordner ist eine .htaccess da habe ich das AddDefaultCharset utf-8
eingetrage...half nix.
dann habe ich die database von kilu auf meinen pc exportiert, im notepad geöffnet und als utf8 gespeichert und hochgeladen. Auch ohne erfolg.
ich habe in der template.html <meta http-equiv="content-type" content="text/html; charset=UTF8" /> eingetragen. ohne erfolg.
ich habe das internet schon fast leergelesen und weiß nicht weiter.

ich brauche bitte hilfe

mfg Frank

[dietmarh]

Ohne zu sehen, welchen Header und welchen Code der Server ausliefert, kann man dir dabei nicht helfen.

[kickme]

wo finde ich das ?
www.sternwarte.kilu.de

[dietmarh]

Mit einem geeigneten Tool im HTTP-Header. Da kommt bei dir
Content-Type text/html; charset=iso-8859-1

Du bist hier im falschen Forenbereich. Hier ist 1.0, und mit 1.0 hätte das funktioniert, weil auch Joomla ISO geliefert hat. 1.5 liefert UTF-8 aus.

Vermutlich kann die Servereinstellung nur dein Hoster ändern.

[kickme]

verstehe ich das richtig, wenn ich mir den quelltext anzeigen lasse steht da
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de-de" lang="de-de" dir="ltr" >
<head>
<base href="http://www.sternwarte.kilu.de/" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="robots" content="index, follow" />

das schlimme ist, das es ja funktioniert hat, erst nachdem ich den www ordner runtergeladen habe und wieder hoch ist das mit den umlauten.
vorher lief alles wunderbar.
also denke ich nicht das der hoster was damit zutun hat.

was kann ich den nun tun ?

[kickme]

danke für eure hilfe.
habe das problem gefunden.
es war das plugin "cache", nachdem ich es abgeschaltet habe funzt es.

doofer fehler......

[harryonline_at]

Achtung:

Ein ähnliches Problem tritt auch auf, wenn Du Quellcode im UTF-8-Format mit einem ncht UTF-8-kompatiblen Editor bearbeitest!

Dazu genügt, einfach einmal einen SQL-Dump im Editor kurz ansehen und (versehentlich) auf Speichern klicken, oder nur ein bisschen Quellcode kurz editieren & abspeichern. Wenn der Editor nicht UTF-8 kann, sondern nur Latin1 / iso-8859-1, kann es in der Summe unvorhergesehene Konsequenzen geben, selbst wenn im Code gar keine dt. Sonderzeichen (selbst in maskierter Form) vorkommen. Wenn im HTML-Head zwar UTF-8 steht oder der Server auf UTF-8 eingestellt ist, aber die Datei physisch gesehen nicht UTF-8 ist, nützt einem das gar nichts.