hawkmaster: Zeichensatz MySQL umstellen

Hallo zusammen,
nach einer Umstellung auf 5.0.37 sind alle meine Tabellen und Spalten mit Kollation "latin1_swedish_ci" eingestellt. (Warum auch immer?)

Wenn ich PhpMyAdmin öffne und damit arbeite wird mir aber als Default immer "utf8" angezeigt.
Ich habe Probleme damit wenn ich eine Tabelle mit PhpMyAdmin änder und es sind Passwörter mit SOnderzeichen drin.
Daher wollte ich nun MySQL auch umstellen.
Ich habe in der "my.ini" folgendes eingestellt:

set-variable = default-character-set=latin1
set-variable = default-collation=latin1_german2_ci #

Danach habe ich den MySQL Dienst neu gestartet.
Trotzdem zeigt mir PhpMyAdmin immer noch "UTF8" an.

Was muss man noch ändern?
Wie wäre die beste Vorgehensweise?
Ich möchte ungern alle MySQL Tabellen umstellen auf "UTF8" weil es ja dann vermutlich Probleme mit dem Login von Usern und deren Passwörtern gibt?

Gruss und danke
hawk

  1. Hallo auch!

    Hallo zusammen,
    nach einer Umstellung auf 5.0.37 sind alle meine Tabellen und Spalten mit Kollation "latin1_swedish_ci" eingestellt. (Warum auch immer?)

    Weil das der vorgegebene Standard ist.

    War Deine alte DB MySQL 4.0 oder aelter?

    Collations kamen mit Version 4.1...

    Wenn ich PhpMyAdmin öffne und damit arbeite wird mir aber als Default immer "utf8" angezeigt.
    Ich habe Probleme damit wenn ich eine Tabelle mit PhpMyAdmin änder und es sind Passwörter mit SOnderzeichen drin.
    Daher wollte ich nun MySQL auch umstellen.
    Ich habe in der "my.ini" folgendes eingestellt:

    set-variable = default-character-set=latin1
    set-variable = default-collation=latin1_german2_ci #

    Danach habe ich den MySQL Dienst neu gestartet.
    Trotzdem zeigt mir PhpMyAdmin immer noch "UTF8" an.

    Was muss man noch ändern?
    Wie wäre die beste Vorgehensweise?
    Ich möchte ungern alle MySQL Tabellen umstellen auf "UTF8" weil es ja dann vermutlich Probleme mit dem Login von Usern und deren Passwörtern gibt?

    Die Kollation regelt die Sortierreihenfolge. German2 waere ggf. eher passend. Das laesst sich an vier Stellen angeben: Fuer den Server, die Datenbank, fuer die Tabelle, fuer das Feld... mal so aus dem Kopf.

    Mehr Infos dazu siehe auch Doku zu MySQL.

    Nick

    --
    --------------------------------------------------
    http://www.xilp.eu
    XILP Internet Links People
    Dein persoenliches privates Netzwerk
    aus Freunden, Verwandten, Bekannten und Kollegen.
    --------------------------------------------------
    1. Hallo Nick
      danke dir für die Hilfe:
      Die Frage ist halt:
      wie bzw. wo bringt man PhpMyAdmin dazu dass nicht mehr "utf8" verwendet wird sondern der gleiche Zeichensatz wie die Tabellen haben.
      Wie gesagt, bei mir steht alles in "latin1_swedish_ci" und es wäre vermutlich das Beste, wenn man das so belässt.

      Gruss
      hawk

      1. Hallo Hawk

        Hallo Nick
        danke dir für die Hilfe:
        Die Frage ist halt:
        wie bzw. wo bringt man PhpMyAdmin dazu dass nicht mehr "utf8" verwendet wird sondern der gleiche Zeichensatz wie die Tabellen haben.

        Bei mir sagt PMA, dass Zeichensatz/Kollation der VERBINDUNG utf8_unicode_ci nutzt.

        Wie gesagt, bei mir steht alles in "latin1_swedish_ci" und es wäre vermutlich das Beste, wenn man das so belässt.

        Die Kollation, nehme ich an?
        Die wuerde ich schon auf etwas dem Inhalt passendes umstellen, also z.B. auf latin1_german2_ci (bei deutschen Texten).

        Bei mir sieht das auch nach problemlosen Betrieb aus. Deine (vgl. Thread) Probleme kann ich (noch?) nicht nachvollziehen. Wie sind denn die Daten in 5.0.x gelandet? Von wo kamen die wie?

        Nick

        --
        --------------------------------------------------
        http://www.xilp.eu
        XILP Internet Links People
        Dein persoenliches privates Netzwerk
        aus Freunden, Verwandten, Bekannten und Kollegen.
        --------------------------------------------------
  2. echo $begrüßung;

    nach einer Umstellung auf 5.0.37 sind alle meine Tabellen und Spalten mit Kollation "latin1_swedish_ci" eingestellt. (Warum auch immer?)

    Das ist die Default-Einstellung. MySQL kommt aus Schweden.
    Ohne explizite Angaben übernehmen die Felder die Kodierung/Kollation der Tabelle, Tabellen übernehmen von Datenbanken, Datenbanken von der Server-Konfiguration.

    Wenn ich PhpMyAdmin öffne und damit arbeite wird mir aber als Default immer "utf8" angezeigt.

    Das ist etwas, das nur den PMA angeht und muss dich nicht weiter kümmern. Jeder Client kann mit einer ihm genehmen Kodierung mit dem MySQL-Server Daten austauschen. Vorausgesetzt, es ist die Kodierung der Server-Konfiguration, oder sie wurde explizit für die Verbindung ausgehandelt. MySQL nimmt dann gegebenenfalls selbständig Umwandlungen zwischen unterschiedlichen Kodierungen vor. Das muss natürlich technisch möglich sein. Der komplette Unicode-Bereich beispielsweise lässt sich nicht in Latin1 abbilden, wohl aber der umgekehrte Fall.

    Ich habe Probleme damit wenn ich eine Tabelle mit PhpMyAdmin änder und es sind Passwörter mit SOnderzeichen drin.

    Welcher Art sind die Probleme? Wurden die Datendateien aus einer Version kleiner als 4.1 direkt übernommen? Verwend(et)en Client und Server beim Importieren/Einfügen der Daten die gleiche Kodierung? Können mit dieser Kodierung alle zu verarbeitenden Zeichen dargestellt werden?

    Daher wollte ich nun MySQL auch umstellen.
    Ich habe in der "my.ini" folgendes eingestellt:

    set-variable = default-character-set=latin1
    set-variable = default-collation=latin1_german2_ci #

    Das "set-variable =" kannst du weglassen.

    Danach habe ich den MySQL Dienst neu gestartet.
    Trotzdem zeigt mir PhpMyAdmin immer noch "UTF8" an.

    Wo zeigt er es an? Die für andere Client interessanten Angaben stehen auf der Systemvariablen-Seite. Falls für eine Einstellung zwei Zeilen auftauchen, dann ist es die Zeile "Globaler Wert", alles andere ist nur für die aktuelle Client-Verbindung von Belang.

    Was muss man noch ändern?
    Wie wäre die beste Vorgehensweise?

    Lass den Server auf UTF-8 laufen oder stelle ihn so ein. Verwende für die Felder eine Kodierung, die den zu erwartenden Daten entspricht, bzw. nimm dafür auch UTF-8. Jeder Client sollte nun selbst mit dem Server aushandeln, welche Kodierung er verwenden und haben möchte. Idealerweise nimmt man dafür die MySQL-API-Funktion mysql_set_character_set(),  weil dann auch die (MySQL-API-)Funktion mysql_real_escape_string() richtig arbeitet. Unter PHP ist mysql_set_character_set() nur in der mysqli-Extension (und damit PHP5) implementiert. Für die ISO-8859-Familie und dazu kompatible Kodierungen/Zeichensätze und für UTF-8 kann man auch das Statement SET NAMES ... verwenden.

    Ich möchte ungern alle MySQL Tabellen umstellen auf "UTF8" weil es ja dann vermutlich Probleme mit dem Login von Usern und deren Passwörtern gibt?

    Es gibt keine Probleme, wenn die Daten nicht bereits kaputt sind, wenn alle beteiligten Systeme über die verwendete Kodierung informiert sind und damit umgehen können, und im gesamten Verarbeitungsprozess kein Datenverlust aufgrund von unpassend gewählten Kodierungen auftritt.

    echo "$verabschiedung $name";

    1. Nachtrag: Das MySQL-Handbuch hat ein eigenes Haupt-Kapitel zum Thema Kodierung/Zeichensatz und Kollation: Character Set Support. Darin findest du alle 10 (wenn ich richtig gezählt habe) verschiedenartigen Stellen aufgeführt, an denen eine Zeichensatz- und Kollationsangabe vorgenommen werden kann und beachtet werden muss.

    2. Hi dedlfix,
      erst einmal vielen Dank für deine Hilfe:

      Mein Problem mit PhpMyAdmin war wie folgt:

      Ich habe eine PHP Seite mit einem User Login Bereich.
      Der User gibt seinen Namen und Passwort ein und wird dann auf die Hauptseite geleitet.
      Das Passwort ist als Spalte "pwd" mit Varchar(250) in einer MySQL DB gespeichert. Als Zeichensatz habe ich den Default "latin1_swedish_ci"
      Das Passwort wird verschlüsselt abgelegt.

      Alles ist in Ordnung bis auf den Fall wenn man mit PhpMyAdmin die MySQL User Tabelle öffnet, in irgend einer anderen Spalte etwas ändert und dann wieder speichert.
      Dann kann sich der User anschließend nicht mehr einloggen, obwohl sich rein visuell das Passwort nicht verändert hat.
      Mir ist etwas weiteres aufgefallen, was vielleicht die Ursache ist.
      Angenommen man ändert mit PhpMyAdmin beim User "demo1" in der Spalte "AddressField" etwas. Dann lautet der Update Befehl von PhpMyAdmin hinterher:

      UPDATE user SET pwd = 'TB.·þ2d]bæø',
      AddressField = 'Bochum' WHERE user.UserID =3 LIMIT 1

      Es wird also auch die Spalte "pwd" geändert obwohl ja dort nichts geändert wurde.

      Wenn man das Gleiche z.b. beim user "demo" macht:
      dann ist der Update Befehl wirklich nur für die betroffene Spalte:
      UPDATE user SET AddressField = 'Köln' WHERE user.UserID =2 LIMIT 1
      Ich weiss nicht warum einmal auch noch zusätzlich die "pwd" Spalte "geupdated" wird und einmal nicht.
      Vermutlich liegt aber das Passwort Prolem daran das die Sonderzeichen im Passwort anders gespeichert werden??

      Im normalen Betrieb mit meiner PHP Weboberfläche passiert dergleichen  nicht.
      Nochmals wegen der Umstellung auf UTF8
      Angenommen ich stelle alle Tabellen, Spalten und Felder auf "UTF8" um.
      Können sich die Anwender dann immer noch auf der PHP Weboberfläche im Login Bereich mit ihren alten Passwörtern anmelden?
      Oder muss ich zusätzlich in meinem PHP Script noch sagen das die Verbindung zum MySQL auch über UTF8 laufen muss?

      viele Grüße
      hawk

      1. echo $begrüßung;

        Mein Problem mit PhpMyAdmin war wie folgt:

        Normalerweise macht der PMA keine Probleme beim Thema Kodierung. Fehler waren in allen bisherigen (mir bekannt gewordenen) Fällen außerhalb seines Zuständigkeitsbereichs verursacht worden, meist indem keine Verbindungskodierung angegeben wurde und die Daten in einer anderen als der Server-Default-Kodierung importiert wurden.

        Mir ist etwas weiteres aufgefallen, was vielleicht die Ursache ist.

        Ich glaube nicht, dass das die wirkliche Ursache ist, sondern nur die Auswirkungen eines bereits vorher begangenen Fehlers.

        Angenommen man ändert mit PhpMyAdmin beim User "demo1" in der Spalte "AddressField" etwas. Dann lautet der Update Befehl von PhpMyAdmin hinterher:

        UPDATE user SET pwd = 'TB.·þ2d]bæø', AddressField = 'Bochum' WHERE user.UserID =3 LIMIT 1
        Es wird also auch die Spalte "pwd" geändert obwohl ja dort nichts geändert wurde.

        Vielleicht nimmt PMA an, dass sich etwas geändert hat, weil es ein Problem mit durch ein Kodierungsproblem verursachter Datenverfälschung in der gesamten Verarbeitungskette gab. Genaueres vermag ich über Ferndiagnose nicht zu sagen.

        Vermutlich liegt aber das Passwort Prolem daran das die Sonderzeichen im Passwort anders gespeichert werden??

        Ich weiß nicht, welche Verschlüsslung du verwendest, und welche Zeichen die daraus resultierende Zeichenkette verwendet.

        Angenommen ich stelle alle Tabellen, Spalten und Felder auf "UTF8" um.
        Können sich die Anwender dann immer noch auf der PHP Weboberfläche im Login Bereich mit ihren alten Passwörtern anmelden?

        Das Umstellen der Felder-Kodierung betrifft nur die interne Datenhaltung. Welche Kodierung der Client zum Senden von Statements und welche für die Ergebnismenge verwendet wird, ist pro Verbindung auszuhandeln, sonst gilt die Server-Default-Einstellung. Gegebenenfalls wandelt MySQL zwischen den Kodierungen hin und her.

        Oder muss ich zusätzlich in meinem PHP Script noch sagen das die Verbindung zum MySQL auch über UTF8 laufen muss?

        Ja, das wäre sinnvoll und bei Abweichung von der Server-Default-Kodierung auch notwendig, wenn du keinen Datenverlust haben möchtest. Du musst die Kodierung angeben, die du verwenden willst, dann auch wirklich diese Kodierung verwenden, denn von allein konvertiert ein Client nichts.

        Um dich mit dem Thema vertraut zu machen, solltest du dir eine Testumgebung aufsetzen, und den Datenaustausch zwischen Client und Server testen. Wenn du am lebenden Objekt forschst, machst du dir vielleicht noch mehr kaputt, als es schon ist. Wenn die Testumgebung zufriedenstellend funktioniert, nimm eine Kopie deiner Produktivdaten und teste damit.

        echo "$verabschiedung $name";