Probleme mit Kollation

[Klaus]

Hallo,

Ich hab leider noch immer dicke Probleme mit den Kollationen.
Vielleicht hab ich es auch einfach nicht richtig verstanden.

Vor einigen Tagen hab ich die Webseiten (und DBs) auf einen neuen Server gebracht.

Das heisst, ich hab auch gleich den Apache, PHP und MySQL aktualisiert, hab aber die Webseiten und die DBs schlicht auf den neuen Server kopiert.

Nach ersten Tests lief alles problemlos, nach und nach stellen sich aber doch einzelne Probleme auf, die wohl größtenteils mit der Kollation zu tun haben.

Zunächstmal kann ich mit dem Phpmyadmin nicht mehr suchen, der hängt mir bei jeder Suche ein Convert dran:

SELECT * FROM wissen WHERE titel LIKE CONVERT( _utf8 'fixup'
USING ) LIMIT 0 , 30

Ich weiß nicht, warum er überhaupt convert benutzen möchte und warum überhaupt _utf8?? Bei der Tabelle steht latin1_general_ci, das wohl standardmäßig genommen wird, da die Info bisher nicht in der Tabelle steht.

Ohne Convert funktioniert die Suche. Allerdings auch wieder nicht bei BLOB-Feldern, die LIKE-Suche liefert einfach nei ein Ergebnis.

Lasse ich mir den Inhalt der Tabelle anzeigen, werden in den BLOB-Feldern die deutschen Umlaute nicht korrekt dargestellt.

Kann ich das korrigieren, indem ich die Tabelle und alle Felder auf Kollation latin1_german_ci umstelle?

Macht es Sinn, wenn ich alles auf UTF8 umstelle? Geht mir dabei eventuell der Inhalt verloren?

Ich hoffe, das war nicht zuviel Text und mein Problem ist nachzuvollziehen.

Klaus

[dedlfix]

echo $begrüßung;

Ich hab leider noch immer dicke Probleme mit den Kollationen.
Vielleicht hab ich es auch einfach nicht richtig verstanden.

Die Kollation beschäftigt sich mit der Sortierung. Du meinst die Kodierung bzw. Zeichensatz (character set).

Vor einigen Tagen hab ich die Webseiten (und DBs) auf einen neuen Server gebracht.
Das heisst, ich hab auch gleich den Apache, PHP und MySQL aktualisiert, hab aber die Webseiten und die DBs schlicht auf den neuen Server kopiert.

Genauere Angaben, über dein Vorgehen als du den MySQL-Server mit den alten Daten versorgt hast, wären schon hilfreich, denn daraus kann man eventuell erkennen, was du richtig oder falsch gemacht hast.

Zunächstmal kann ich mit dem Phpmyadmin nicht mehr suchen, der hängt mir bei jeder Suche ein Convert dran:

Was zeigt der PMA auf seiner Startseite an, welche Kodierung er verwendet? Was ist im Server eingestellt (Was zeigt die Seite System-Variablen für die "character set ..."-Werte an?)

SELECT * FROM wissen WHERE titel LIKE CONVERT( _utf8 'fixup' USING [???]) LIMIT 0 , 30

Da fehlt doch sicher was.

Ich weiß nicht, warum er überhaupt convert benutzen möchte und warum überhaupt _utf8?? Bei der Tabelle steht latin1_general_ci, das wohl standardmäßig genommen wird, da die Info bisher nicht in der Tabelle steht.

Vermutlich will er das, weil es Unterschiede zwischen ihm und dem Server in der verwendeten Kodierung gibt.

Lasse ich mir den Inhalt der Tabelle anzeigen, werden in den BLOB-Feldern die deutschen Umlaute nicht korrekt dargestellt.

Es gibt viele Arten von "nicht korrekt". Wie genau sieht deine aus?

Kann ich das korrigieren, indem ich die Tabelle und alle Felder auf Kollation latin1_german_ci umstelle?

Ohne Ursachenermittlung halte ich eine Beantwortung dieser Frage nicht für besonders sinnvoll.

Macht es Sinn, wenn ich alles auf UTF8 umstelle? Geht mir dabei eventuell der Inhalt verloren?

Das kommt darauf an, was bisher schon kaputtgegangen ist. Wenn derzeit alles richtig ist/wäre, kann man die Kodierung/Kollation der Felder umstellen, und MySQL nimmt gegebenenfalls eine Konvertierung der Daten vor.

Vielleicht hast du auch nur nicht beachtet, die auf deinen Datenbankverbindungen zu verwendende Kodierung explizit auszuhandeln (SET NAMES ... oder besser mit der Funktion mysql_set_charachter_set() bzw. deren Pendant in der verwendeten Umgebung (beispielsweise mysqli in PHP5)).

echo "$verabschiedung $name";

[Klaus]

Hallo,

vielen Dank für Deine Unterstützung.

Vor einigen Tagen hab ich die Webseiten (und DBs) auf einen neuen Server gebracht.
Das heisst, ich hab auch gleich den Apache, PHP und MySQL aktualisiert, hab aber die Webseiten und die DBs schlicht auf den neuen Server kopiert.

Genauere Angaben, über dein Vorgehen als du den MySQL-Server mit den alten Daten versorgt hast, wären schon hilfreich, denn daraus kann man eventuell erkennen, was du richtig oder falsch gemacht hast.

Ich hab den neuesten XAMP installiert. Hab die httpd angepasst. Ich  hab die Dateien (Webseiten) in das htdocs kopiert. Ich hab die Datenbanken und Tabellen als Dateien ins MySQL-Data-Verzeichnis des neuen Servers kopiert.

Zunächstmal kann ich mit dem Phpmyadmin nicht mehr suchen, der hängt mir bei jeder Suche ein Convert dran:

Was zeigt der PMA auf seiner Startseite an, welche Kodierung er verwendet? Was ist im Server eingestellt (Was zeigt die Seite System-Variablen für die "character set ..."-Werte an?)

SELECT * FROM wissen WHERE titel LIKE CONVERT( _utf8 'fixup' USING [???]) LIMIT 0 , 30

SELECT * FROM wissen WHERE titel LIKE CONVERT( _utf8 'fixup'
USING latin1 ) LIMIT 0 , 30

Ich weiß nicht, warum er überhaupt convert benutzen möchte und warum überhaupt _utf8?? Bei der Tabelle steht latin1_general_ci, das wohl standardmäßig genommen wird, da die Info bisher nicht in der Tabelle steht.

Vermutlich will er das, weil es Unterschiede zwischen ihm und dem Server in der verwendeten Kodierung gibt.

In der My.cnf steht
character-set-server = latin1
collation-server = latin1_general_ci
Die Tabellen stehen alle auf latin1_general_ci.

Lasse ich mir den Inhalt der Tabelle anzeigen, werden in den BLOB-Feldern die deutschen Umlaute nicht korrekt dargestellt.

Es gibt viele Arten von "nicht korrekt". Wie genau sieht deine aus?

Die deutschen Umlaute werden mit Sonderzeichen dargestellt (das 'ü' ist beispielsweise eine kleine schwarze Raute mit einem Fragezeichen drin)

Vielleicht hast du auch nur nicht beachtet, die auf deinen Datenbankverbindungen zu verwendende Kodierung explizit auszuhandeln (SET NAMES ... oder besser mit der Funktion mysql_set_charachter_set() bzw. deren Pendant in der verwendeten Umgebung (beispielsweise mysqli in PHP5)).

Die meisten meiner Tabellenabfragen funktionieren wunderbar und anstandslos. Lediglich der Phpmyadmin bei der 'LIKE'-Suche und meine Php-Scripte bei der Suche innerhalb von BLOB-Feldern.

Ich hoffe, der Beitrag ist nicht bereits zu weit runtergerutscht und findet noch Beachtung.

Klaus

[dedlfix]

echo $begrüßung;

Vor einigen Tagen hab ich die Webseiten (und DBs) auf einen neuen Server gebracht.
Das heisst, ich hab auch gleich den Apache, PHP und MySQL aktualisiert, hab aber die Webseiten und die DBs schlicht auf den neuen Server kopiert.

Genauere Angaben, über dein Vorgehen als du den MySQL-Server mit den alten Daten versorgt hast, wären schon hilfreich, denn daraus kann man eventuell erkennen, was du richtig oder falsch gemacht hast.

Ich hab den neuesten XAMP installiert. Hab die httpd angepasst. Ich  hab die Dateien (Webseiten) in das htdocs kopiert. Ich hab die Datenbanken und Tabellen als Dateien ins MySQL-Data-Verzeichnis des neuen Servers kopiert.

Wenn du vorher eine Version kleiner als 4.1 hattest, dann ist beim Übernehmen der Datenbank-Dateien zu beachten, dass die Default-Einstellung des neuen MySQL-Servers zunächst einmal wieder genauso eingestellt werden muss wie beim alten. Hierzulande wird das latin1 gewesen sein. Nun muss man mindestens einmal für jedes Feld die Kodierung/Kollation ändern. Dabei ist es fast egal, wohin man umstellt, Hauptsache die neue Kodierung kann alle verwendeten Zeichen aufnehmen. Es reicht, wenn man innerhalb der Kodierung bleibt und nur die Kollation eine andere ist. Man kann es auch gleich wieder zurückstellen. Die Änderung führt dazu, dass diese Information in die Tabellendateien eingetragen wird. Bis einschließlich Version 4.0 stand sie nicht drin, da es nur eine generelle Kodierung für den gesamten MySQL-Server gab. Hat man das für die Felder getan, kann man das auch noch für die Tabellen und Datenbanken machen. Danach kann man auch problemlos die Defaulteinstellung des Servers ändern.

In der My.cnf steht
character-set-server = latin1

Es ist empfehlenswert, die eben beschriebene Vorgehensweise anzuwenden, auch wenn man derzeit noch nicht daran denkt, die Server-Default-Kodierung zu wechseln. Später hat man es garantiert vergessen :-)

Was zeigt der PMA auf seiner Startseite an, welche Kodierung er verwendet? Was ist im Server eingestellt (Was zeigt die Seite System-Variablen für die "character set ..."-Werte an?)
In der My.cnf steht
character-set-server = latin1
collation-server = latin1_general_ci
Die Tabellen stehen alle auf latin1_general_ci.

Du hast den ersten Teil der Frage nicht beantwortet. Davon ausgehend, dass der PMA UTF-8 verwendet, kann ich mir schon vorstellen, dass er Grund für eine Konvertierung hat. Bisher hatte er immer Recht und der Fehler lag woanders.

Lasse ich mir den Inhalt der Tabelle anzeigen, werden in den BLOB-Feldern die deutschen Umlaute nicht korrekt dargestellt.
Die deutschen Umlaute werden mit Sonderzeichen dargestellt (das 'ü' ist beispielsweise eine kleine schwarze Raute mit einem Fragezeichen drin)

BLOB-Felder werden als Binärdaten behandelt. Wenn du darin Text stehen hast, solltest du einen der TEXT-Feldtypen verwenden.
"Kleine schwarze Raute mit einem Fragezeichen" bedeutet, dass die Bytefolge in der gewählten Kodierung fehlerhaft ist. Beispielsweise ist das Byte für ein ISO-8859-1 kodiertes ü in einer UTF-8-Zeichenfolge ungültig, wenn es sich zwischen "normalen" Buchstaben befindet.

Vielleicht hast du auch nur nicht beachtet, die auf deinen Datenbankverbindungen zu verwendende Kodierung explizit auszuhandeln (SET NAMES ... oder besser mit der Funktion mysql_set_charachter_set() bzw. deren Pendant in der verwendeten Umgebung (beispielsweise mysqli in PHP5)).
Die meisten meiner Tabellenabfragen funktionieren wunderbar und anstandslos. Lediglich der Phpmyadmin bei der 'LIKE'-Suche und meine Php-Scripte bei der Suche innerhalb von BLOB-Feldern.

Es ist trotzdem keine schlechte Idee, die zu verwendende Kodierung explizit auszuhandeln, anstatt sich auf den Zufall zu verlassen.

echo "$verabschiedung $name";

[klaus]

Hallo,

Wenn du vorher eine Version kleiner als 4.1 hattest, dann ist beim Übernehmen der Datenbank-Dateien zu beachten, dass die Default-Einstellung des neuen MySQL-Servers zunächst einmal wieder genauso eingestellt werden muss wie beim alten. Hierzulande wird das latin1 gewesen sein. Nun muss man mindestens einmal für jedes Feld die Kodierung/Kollation ändern. Dabei ist es fast egal, wohin man umstellt, Hauptsache die neue Kodierung kann alle verwendeten Zeichen aufnehmen. Es reicht, wenn man innerhalb der Kodierung bleibt und nur die Kollation eine andere ist. Man kann es auch gleich wieder zurückstellen. Die Änderung führt dazu, dass diese Information in die Tabellendateien eingetragen wird. Bis einschließlich Version 4.0 stand sie nicht drin, da es nur eine generelle Kodierung für den gesamten MySQL-Server gab. Hat man das für die Felder getan, kann man das auch noch für die Tabellen und Datenbanken machen. Danach kann man auch problemlos die Defaulteinstellung des Servers ändern.

Ich glaube, die alte Version war 4.0.12. Sicherlich aber ohne die Kodierungsangaben ...

Was zeigt der PMA auf seiner Startseite an, welche Kodierung er verwendet? Was ist im Server eingestellt (Was zeigt die Seite System-Variablen für die "character set ..."-Werte an?)
In der My.cnf steht
character-set-server = latin1
collation-server = latin1_general_ci
Die Tabellen stehen alle auf latin1_general_ci.

Du hast den ersten Teil der Frage nicht beantwortet. Davon ausgehend, dass der PMA UTF-8 verwendet, kann ich mir schon vorstellen, dass er Grund für eine Konvertierung hat. Bisher hatte er immer Recht und der Fehler lag woanders.

Seltsamerweise steht jetzt auf der Startseite des PMA beim MySQL-Zeichensatz UTF8, aber bei der MySQL-Verbindung steht latin1_general_ci.

Ich werd wohl mal alle DBs, Tabellen und Felder auf UTF8 ändern, nachdem was ich so gegoogled habe, ist UTF8 empfohlen.

Lasse ich mir den Inhalt der Tabelle anzeigen, werden in den BLOB-Feldern die deutschen Umlaute nicht korrekt dargestellt.
Die deutschen Umlaute werden mit Sonderzeichen dargestellt (das 'ü' ist beispielsweise eine kleine schwarze Raute mit einem Fragezeichen drin)

BLOB-Felder werden als Binärdaten behandelt. Wenn du darin Text stehen hast, solltest du einen der TEXT-Feldtypen verwenden.

Welches Feld sollte ich anstatt Blob nehmen? Wäre Longtext besser?

Vielleicht hast du auch nur nicht beachtet, die auf deinen Datenbankverbindungen zu verwendende Kodierung explizit auszuhandeln (SET NAMES ... oder besser mit der Funktion mysql_set_charachter_set() bzw. deren Pendant in der verwendeten Umgebung (beispielsweise mysqli in PHP5)).
Die meisten meiner Tabellenabfragen funktionieren wunderbar und

Da die Scripte nie auf einem fremden Server laufen werden, sollte ich den Zufall eigentlich ausschalten können. Es ist sehr aufwendig, wenn ich bei allen Scripten bzw. Tabellenabfragen die Kodierung explizit angeben müsste. Die Scripte sind alle historisch gewachsen und meine Programmierkenntnisse erstreckten sich noch nicht über Programmierung von Services ...

Sicherlich habe ich etwas leichtgläubig angenommen, die Portierung auf einen neuen Server würde nachwievor per Click&Copy funktionieren.

Sollte ich vielleicht im Zuge der Anpassung aller Tabellen etc. auch gleich auf BDB-Tabellen wechseln? Soviel ich verstanden habe, würde sich die Transactionssicherheit erhöhen und auch die Performance steigern??

Klaus

[dedlfix]

echo $begrüßung;

Welches Feld sollte ich anstatt Blob nehmen? Wäre Longtext besser?

Textdaten bekommen etwas mit TEXT hintendran. Welche Vorsilbe du verwenden musst hängt von der Größe der abzulegenden Daten ab. Wenn du vorher BLOB hattest, reicht nun auch TEXT.

Da die Scripte nie auf einem fremden Server laufen werden, sollte ich den Zufall eigentlich ausschalten können. Es ist sehr aufwendig, wenn ich bei allen Scripten bzw. Tabellenabfragen die Kodierung explizit angeben müsste. Die Scripte sind alle historisch gewachsen und meine Programmierkenntnisse erstreckten sich noch nicht über Programmierung von Services ...

Nicht jede Abfrage benötigt ein vorangestelltes Festlegen der Kodierung, einmal nach dem Verbindungsaufbau reicht. Services nimmt man zur Kommunikation von Prozessen untereinander. Ein Aufruf ist verhältnismäßig aufwendig. Für ein wenig Übersichtlichkeit reicht es schon, wenn du die Datenabfragen innerhalb einer zu inkludierenden Datei bündelst. Das kann auch gern als Klasse implementiert sein. Wenn sich jede deiner Abfragen ihre eigene Verbindung aufbaut ist das nicht besonders sinnvoll organisiert.

Sicherlich habe ich etwas leichtgläubig angenommen, die Portierung auf einen neuen Server würde nachwievor per Click&Copy funktionieren.

Im Prinzip ist es auch nicht sehr aufwendig. Nur der Schritt von 4.0 nach 4.1 ist wegen der grundlegenden Neugestaltung des Themas Kodierung und Kollation einer, der mehr Beachtung benötigt.

Sollte ich vielleicht im Zuge der Anpassung aller Tabellen etc. auch gleich auf BDB-Tabellen wechseln? Soviel ich verstanden habe, würde sich die Transactionssicherheit erhöhen und auch die Performance steigern??

Da muss ich mich mangels Erfahrung zurückhalten. Mir ist auch noch niemand (virtuell) begegnet, der diese Storage Engine nutzt. Die bekannteste Engine wird MyISAM. Danach kommt eine Weile nichts, gefolgt von InnoDB. Ich kann mir gut vorstellen, dass zu anderen Engines wenig Erfahrung vorhanden und zu finden ist.

echo "$verabschiedung $name";

[Klaus]

echo $begrüßung;

Welches Feld sollte ich anstatt Blob nehmen? Wäre Longtext besser?

Textdaten bekommen etwas mit TEXT hintendran. Welche Vorsilbe du verwenden musst hängt von der Größe der abzulegenden Daten ab. Wenn du vorher BLOB hattest, reicht nun auch TEXT.

Dann werde ich im Zuge der Umstellung alle BLOB-Felder in TEXT-Felder umwandeln, da diese schlicht nur jede Menge Text enthalten, aber mehr nicht. Also z.B. das, was ich hier gerade eingebe.

Nicht jede Abfrage benötigt ein vorangestelltes Festlegen der Kodierung, einmal nach dem Verbindungsaufbau reicht. Services nimmt man zur Kommunikation von Prozessen untereinander. Ein Aufruf ist verhältnismäßig aufwendig. Für ein wenig Übersichtlichkeit reicht es schon, wenn du die Datenabfragen innerhalb einer zu inkludierenden Datei bündelst. Das kann auch gern als Klasse implementiert sein. Wenn sich jede deiner Abfragen ihre eigene Verbindung aufbaut ist das nicht besonders sinnvoll organisiert.

Ich hab die Webseiten weitgehend auf Templates aufgebaut, wo der Rahmen für das Öffnen und Schließen der Verbindung zuständig ist.

Insofern sollte ich auch die Anzahl der gleichzeitigen Verbindungen gering halten können.

Ich bleib dann auch vorerst mal lieber my MyISAM-Tabellen. Zumal der PMA nirgends was von BDB zeigt.

Klaus