Page 1 of 1

Nach SQL-Export wird aus "Hallo" "\r\nHallo&q

Posted: Sun 7. Oct 2007, 16:48
by spielplan
Hallo zusammen,

ich habe local eine 1.3.3 installiert und wollte nun die db zu 1und1 überspielen.

Local habe ich mit HeidiSQL exportiert und festgestellt, das die Steuerzeichen \r\n im Dump angezeigt werden.

Nach einem import bei 1und1 werden nun diese Steuerzeichen
als Klartext angezeigt.

Local habe ich MySql 4.1.1, Zeichencodierung: latin1, Kollation: nix
Bei 1und1 habe ich MySQL 4.0.27, Language: German(de-iso-8859-1)

Zeichencodierung und Kollation konnte ich bei 1und1 nicht finden.

Was muss ich tun, damit diese Steuerzeichen wieder verschwinden?

Viele Grüße!
Detlef

Posted: Sun 7. Oct 2007, 17:58
by juergen
Hallo

du kannst das sql File in einen reinen Texteditor (kein word, wordpad oder so n Zeugs) nehmen und das darin ersetzen lassen.

Für PHP und sql nuze ich http://www.crimsoneditor.com/

der kann dir die Stuerzeichen durch "nix" ersetzen o;)O

Posted: Mon 8. Oct 2007, 19:56
by spielplan
man, ich krieg echt die Krise...

Die Steuerzeichen per Editor zu entfernen ist eine Möglichkeit,
aber nicht die Lösung.

Jetzt habe ich ein bischen was in phpmyadmin umgestellt und
nun werden die Steuerzeichen korrekt dargestellt, dafür werden
jetzt die Umlaute nicht mehr interpretiert.

ö = ö

Mein lokaler phpmyadmin sagt:
Language: German (German de utf-8)
MySQL-Zeichensatz: UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: utf8_general_ci

conf.inc.php:
$phpwcms['charset'] = 'utf-8'; //default charset 'iso-8859-1'
$phpwcms['db_charset'] = 'utf8';
$phpwcms['db_collation'] = 'utf8_general_ci';

Mein phpmyadmin bei 1und1 sagt:
Language: German (German de utf-8)
MySQL-Zeichensatz: gibt es nicht
Zeichensatz / Kollation der MySQL-Verbindung: gibt es nicht

Quelltextauszug der index.php

Code: Select all

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
Local läuft alles auf utf-8. Auch das Setup habe ich danach angepasst.

Wieso wird dann in den Meta-Tags von iso-8859-1 gesprochen?

Wieso kann ich im phpmyadmin bei 1und1 weder den
"Zeichensatz / Kollation der MySQL-Verbindung" noch den
"MySQL-Zeichensatz" einstellen?


Viele Grüße!
Detlef

Posted: Mon 8. Oct 2007, 20:08
by flip-flop
Wieso kann ich im phpmyadmin bei 1und1 weder den "Zeichensatz / Kollation der MySQL-Verbindung" noch den "MySQL-Zeichensatz" einstellen?
Weil es eine 4.0.xx DB ist.
Die Standarteinstellung wäre dann charset: latin1 und (wenn überhaupt) collation latin1_swedish_ci mit dem system-charset iso-8859-1

Weshalb schaust du nicht vorher wie das Zielsystem aussieht?
Und weshalb utf8? Der Mittel/Nordeuropäische Sprachraum ist doch latin1 mit iso.
Das was in phpMyAdmin eingestellt wird, ist die Verbindung von phpMyAdmin zur DB.

Je nach 1und1 Account könntest du aber die 4.0.xx kicken und eine 5.x anlegen.

Knut

Posted: Mon 8. Oct 2007, 20:36
by spielplan
Super, vielen Dank!
Jetzt blicke ich etwas mehr durch.

Habe eine 5.x angelegt, Daten importiert und geht!

Vielen Dank und Grüße!
Detlef

Posted: Mon 8. Oct 2007, 20:50
by Till
Ich habe mit MySQLDumper recht gute Erfahrungen gemacht.
Habe damit meine Latin in ein UTF Format gebracht.

Posted: Tue 9. Oct 2007, 07:33
by spielplan
@flip-flop
Weil es eine 4.0.xx DB ist.
Die Standarteinstellung wäre dann charset: latin1 und (wenn überhaupt) collation latin1_swedish_ci mit dem system-charset iso-8859-1
Also mein xampp beinhaltet eine MySql-DB v. 4.1.12.
Bei 1und1 ist die v. 4.0.27 installiert.
Sind also beide 4.x Versionen. Trotzdem kann ich bei
meiner localen MySql-DB (4.1.12) den "MySQL-Zeichensatz"
und "Zeichensatz / Kollation der MySQL-Verbindung" einstellen.
Bei 1und1 ist diese Möglichkeit nicht vorhanden.
Oder ist ebend diese Einstellungsmöglichkeit mit dem Versions-
sprung von 4.0.x auf 4.1.x eingepflegt worden?
Weshalb schaust du nicht vorher wie das Zielsystem aussieht?
Stimmt, das hätte ich natürlich machen sollen. Aber ich bin davon
ausgegangen, dass man die besagten Parameter entsprechend
einstellen kann, um Kompatibilität herzustellen.
Und weshalb utf8? Der Mittel/Nordeuropäische Sprachraum ist doch latin1 mit iso.
Nun, zum Einen wusste ich das nicht und zum anderen war beim
Setup von phpwcms utf8 bereits eingetragen. Ich bin davon
ausgegangen, das diese Parameter ausgelesen werden und
entsprechend "automatisch" zur DB passen.


Viele Grüße!
Detlef

Posted: Tue 9. Oct 2007, 08:09
by Oliver Georgi
Bleibt IMMER bei phpMyAdmin. Die Dumps mit Heidi misslingen häufig! Ist ein gutes Teil zum Entwickeln und für Abfragen etc. - aber NICHT für Dumps. Da muss man teils zuviel Einstellen.

Bei phpMyAdmin darauf achten beim Export welche Zielkompatibilität man haben möchte - ob MySQL323 oder 4 oder höher.

Immer auf korrekte Kodierung achten - also ob UTF-8 oder Latin1/ISO-8859-1 bzw. Windows (ANSI).

Auf passenden Editor achten: http://www.pspad.com

Und oftmals ist es hilfreicher in phpMyAdmin den "Import" mittels Copy&Paste über das SQL Feld zu realisieren - bei größeren Imprten blockweise.

Immer möglichst die neueste Version von phpMyAdmin für Export- und Import nehmen. Macht Euch lieber die Mühe und spielt eine neue Version ein, als die teils gruselig alten Installationen der Provider zu benutzen.

Oliver

Posted: Tue 9. Oct 2007, 08:13
by flip-flop
@spielplan:
Oder ist ebend diese Einstellungsmöglichkeit mit dem Versions-
sprung von 4.0.x auf 4.1.x eingepflegt worden?
Genau so ist es.
New CHARSET() and COLLATION() functions to return the character set and collation of a string.
http://dev.mysql.com/doc/refman/4.1/en/news-4-1-0.html
Nun, zum Einen wusste ich das nicht und zum anderen war beim Setup von phpwcms utf8 bereits eingetragen. Ich bin davon ausgegangen, das diese Parameter ausgelesen werden und entsprechend "automatisch" zur DB passen.
Für irgendetwas musste sich Oliver ja entscheiden. Er hat eben utf8 voreingestellt. Ich würde es sicher anders machen aber das ist unwichtig.
Ein externes CMS kann keiner geschlossenen Anwendung gleich kommen bei der alles für den entsprechenden Sprachraum und der verwendeten Software-Technikplattform richtig voreingestellt ist. Hier gibt es scheinbar eine große Verwechselungsgefahr mit einem lokal laufenden Programm, das in einer exakt definierten Umgebung abläuft. (BS, DB, Schnittstellen ....)

Knut