Support » Installation » Datenbank-Kollation

  • Gelöst Flower33

    (@flower33)


    Hallo zusammen!

    Als ich neulich meine Test-Datenbank in XAMPP angelegt habe, habe ich die Kollation „utf8_general_ci“ ausgewählt. Läuft soweit auch alles gut bei der Test-Installation.

    Erst danach habe ich hier im Forum in einem Beitrag von Bego und jetzt auch im Praxishandbuch von Gino Cremer gelesen „Lassen Sie das Auswahlfeld Kollation ruhig so wie es ist“, sprich, man soll (?) bzw. braucht (?) beim Anlegen keine spezifische Kollation ein(zu)geben.

    Es gab bei mir (mit besagter Kollation-Auswahl) bis jetzt keine spürbaren negativen Auswirkungen, und beim vielen WP-spezifischen Rumlesen in letzter Zeit habe ich auch nirgends eine Begründung dafür gesehen. Hat jemand irgendwelche diesbezüglichen Detail-Infos oder Begründungen für die Aussage/Empfehlung, in diesem Feld nichts auszuwählen? Danke schon mal im Voraus!

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 25)
  • Es gibt verschiedene Einstellungen bezüglich Kollation.

    1) Die Kollation der einzelnen Tabellen.

    2) Die Standard-Kollation der Datenbank

    => Es kommt daher vor, dass sich in einer Datenbank Tabellen mit unterschiedlicher Kollation befinden.

    3) Die Kollation der MySQL-Verbindung, die phpMyAdmin zur Kommunikation verwendet (änderbar in den „Allgemeinen Einstellungen“ von phpMyAdmin). Eine Änderung hier wirkt sich also nur auf phpMyAdmin aus.

    Wenn du nichts einstellst, sollte WordPress automatisch utf8mb4 verwenden und die Plugins verwenden die Standard-Kollation (siehe Punkt 2), außer sie legen ihre Tabellen explizit mit einer anderen Kollation an.

    Fazit: Nachdem WordPress utf8mb4 verwendet, würde ich empfehlen, immer utf8mb4_unicode_ci zu verwenden.

    Allerdings muss ich sagen, dass ich kein Spezialist auf dem Gebiet bin, vielleicht gibt es noch andere Meinungen, die besser begründet sind?

    @anchises:
    Freut mich, dass du auf meine Frage eingehst!
    Vielen Dank für die verständliche Darstellung, die ich auf meiner Test-Installation auf XAMPP sehr gut nachvollziehen kann:

    Die auf meinem XAMPP voreingestellte Kollation der MySQL-Verbindung ist utf8mb4_unicode_ci.

    Der Datenbank hatte ich, wie oben erwähnt, beim Erstellen die Kollation utf8_general_ci zugewiesen (ich lese gerade im WP-Buch von Hetzel „WordPress setzte früher auf den Zeichensatz utf8_general_ci“; ich hatte mich vor einiger Zeit mal kurz mit einem anderen CMS beschäftigt, wo wahrscheinlich Selbiges der Fall war, daher wohl meine Erinnerung an utf8_general_ci und die Auswahl dieser Kollation beim Erstellen meiner ersten Datenbank, bevor ich dann mehr darüber las).

    Wenn ich mir jetzt meine mit der Kollation utf8_general_ci angelegte Datenbank anschaue, dann steht ganz unten die Zahl der Tabellen, rechts als Typ InnoDB und daneben die von mir zugewiesene Kollation utf8_general_ci.

    Die einzelnen WordPress-Tabellen haben, wie von dir beschrieben, ohne mein Zutun als Kollation utf8mbi_unicode_ci, und die 5 RevSlider-Tabellen haben, genau wie von dir angegeben, die Standard-Kollation, hier also uft8_general_ci.

    In Hetzels Buch ist in 2 Abbildungen (eine bei XAMPP; eine bei MAMP) jeweils utf8mbi_general_ci als Kollation ausgewählt. Damit übereinstimmend heißt es im WP-Codex: „Enter the chosen database name in the Create database field and choose the best collation for your language and encoding. In most cases it’s better to choose in the „utf8_“ series and, if you don’t find your language, to choose „utf8mb4_general_ci“.“

    Mein derzeitiger Stand:

    1)
    Kollation der MySQL-Verbindung voreingestellt als utf8mb4_unicode_ci.
    2)
    Kollation der WP-Tabellen: ohne mein Zutun utf8mb4_unicode_ci.
    3)
    Kollation der Datenbank: G. Cremer sagt: keine Auswahl, so lassen, A. Hetzel zeigt in Abbildungen utf8mb4_general_ci, Codex erwähnt (als eine Möglichkeit) ebenfalls utf8mb4_general_ci, User @anchises begründet utf8mb4_unicode_ci.

    Kurzes Fazit:

    Das Ganze ist mir jetzt schon ein gutes Stück klarer.
    Den Wechsel von utf8 auf utf8mb4 kann ich gut nachvollziehen (ermöglicht viel mehr Zeichen als utf8). Deswegen werde ich bei der Server-Installation auch nicht mehr utf8_general_ci auswählen.

    Inzwischen habe ich aber auch so ein bisschen den Eindruck gewonnen, dass es für eine, salopp gesagt, stinknormale deutsche WP-Installation relativ egal ist, ob ich jetzt bei Datenbank-Kollation gar nichts auswähle oder aber utf8mb4_general_ci bzw. utf8mb4_unicode_ci. Cremer und Hetzel schätze ich beide als Fachautoren, der Codex ist eine Autorität und @anchises‚ Argument ist gut begründet. Trotzdem 3 verschiedene Angaben im Hinblick auf die Auswahl der Datenbank-Kollation. Vielleicht kommen ja im weiteren Verlauf der Diskussion noch ein paar zusätzliche Aspekte zur Sprache.

    Stand jetzt schwanke ich bei der Datenbank-Kollation zwischen utf8mb4_unicode_ci und utf8mb4_general_ci, wobei ich mal noch in Ruhe nachschauen muss, wie sich diese beiden voneinander unterscheiden und ob es bei der Auswahl der Datenbank-Kollation Fälle geben könnte, wo die eine der beiden der anderen vorzuziehen wäre.

    Vielen Dank noch mal an @anchises für die verständliche und hilfreiche Darstellung!

    Zu der Frage „unicode“ vs „general“:

    http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci

    What should you use?

    There is almost certainly no reason to use utf8mb4_general_ci anymore, as we have left behind the point where CPU speed is low enough that the performance difference would be important. Your database will almost certainly be limited by other bottlenecks than this.

    One other thing I’ll add is that even if you know your application only supports the English language, it may still need to deal with people’s names, which can often contain characters used in other languages in which it is just as important to sort correctly. Using the Unicode rules for everything helps add peace of mind that the very smart Unicode people have worked very hard to make sorting work properly.

    —–

    Sprich: „Unicode“ ist genauer, „general“ ist schneller (weil es einige Abkürzungen verwendet)

    Wobei sich der Unterschied in der Schnelligkeit bei der Performance moderner Server kaum bemerkbar machen sollte.

    Ich denke, wenn du nicht gerade ein sehr großes Projekt vorhast, wird es relativ egal sein.

    Perfekt, @anchises, ich danke dir!

    Hallo zusammen,

    vor einiger Zeit hatte ich diese Frage in G+ gestellt.

    Thomas Scholz ist auch eine Koryphäe auf diesem Gebiet.

    Nachtrag:
    Leider kann man in dem verlinkten thread auf G+ die „3 vorherigen Kommentare“ nur lesen, wenn man bei G+ angemeldet ist. Daher stattdessen hier der (fehlende) Text der drei Kommentare:

    Thomas Scholz (toscho)19.05.2015
    *general_ci ist schnell, aber sehr primitiv. Es betrachtet a,ä und å als den gleichen Buchstaben. Verwende *unicode_ci oder eine der optimierten Varianten wie utf8mb_german2_ci. Das gibt bessere Ergebnisse beim Sortieren.

    Software-Lupe19.05.2015
    Danke!

    Kristina Marino19.05.2015
    Ich habe bis jetzt auch immer UTF8_general_ci benutzt.
    Nachträglich ändern geht wohl nicht , oder?

    Hi Angelika. Immer Ärger mit dem Zeichensatz: Habe gerade einem Mitstreiter des Kölner Meetups geholfen, seine Website umzuziehen und Let’s Encrypt-SSL einzurichten. Alles schick soweit, nur einige Bilddateien mit Sonderzeichen (Umlaute, „ß“) werden nicht angezeigt. Hatte hier auf einen falschen Zeichensatz der Datenbank-Tabellen getippt, aber die Einträge in der Datenbank sind alle korrekt, wenn man sie mit phpMyAdmin beauskunftet. Auch ein nachträglicher Wechsel auf UTF-8-MBF hat nichts gebracht. Muss jetzt in den nächsten Tagen mal eine Test-Installation aufsetzen … Irgendwo mache ich einen Denkfehler.

    Hallo Angelika, schön, mal wieder was von dir zu lesen, hatte deine Beiträge hier schon vermisst! 🙂
    Danke für den Hinweis auf die G+-Diskussion, da ging es dir ja damals mit dem utf8_general_ci wie mir jetzt 😉
    Bei meiner Live-Installation werde ich nach dem bisher Dazugelernten also nicht, wie derzeit auf XAMPP, „utf8_general_ci“, sondern von Anfang an „utf8mb4_unicode_ci“ als Datenbank-Kollation wählen und hoffe, mir die auf G+ angesprochenen nachträglichen Konvertierungen ersparen zu können. Das klingt nach nicht unerheblichem Stress…;-)
    Danke auch für die Mühe, die für Nichtangemeldete nicht zugänglichen Inhalte zu zitieren!

    Hallo Flower33, war 2 Wochen in Urlaub und das hat guuuuut getan 🙂
    Ich stelle generell eine utf8… Kollation über PHPmyAdmin ein, und habe noch nie Hieroglyphen auf irgendeiner Website gehabt.

    Habe auch festgestellt, wenn utf8_unicode_ci (oder auch general_ci) gewählt wurden, der Hoster aber auch für die Datenbanken utf8mb4 anbietet, stellt WordPress entsprechende Tabellen selbst auf utf8mb4.

    @bego:
    Ich habe auf Kundenseiten generell „verkehrte“ Dateinamen per functions.php unterbunden. Gibt’s auch als Plug-in:
    https://de.wordpress.org/plugins/clean-image-filenames/

    „Unterbunden“ ist nicht ganz korrekt ausgedrückt, die Problem behafteten Dateinamen werden umgeschrieben.

    Ich habe auf Kundenseiten generell „verkehrte“ Dateinamen per functions.php unterbunden.

    Besser ist das. Aber … Kunden/Anwender … 8)

    Sind die Dateinamen mit Umlauten und ß in der Datenbank hinterlegt oder wurden die Namen geändert?

    Schau mal dort, vielleicht hilft’s.
    http://forum.wpde.org/installation/102432-probleme-mit-umlauten-bei-bildern-nach-serverumzug.html

    Oh, da kommen wir der Sache aber ganz nahe.
    Muss mal meinen Meetup-Kumpel fragen. Danke für den Tipp!

    @angelika
    Es liegt tatsächlich an den Dateinamen, mit den die Dateien auf dem Server abgespeichert sind. Melde ich mich per ssh an, werden Umlaute als vier Fragezeichen dargestellt (Borussia-M????nchengladbach-120x67.jpg), ein directory listing mit ls -Q fördert dann die Umlaute als Borussia-M\303\203\302\266nchengladbach-120x67.jpg zu Tage.

    Versuche ich nun per ssh die Datei umzubenennen, kann ich im Terminal keine Umlaute mehr eingeben. Auch der Versuch, die Datei herunterzuladen, auf dem eigenen Mac den Dateinamen zu ändern und die Datei wieder hochzuladen, scheitert daran, dass die Datei anschließend wieder als Borussia-M????nchengladbach-120×67.jpg auftaucht.

    Eigentlich keine WordPress-Frage, aber wenn du noch eine Idee hast …

    @bego
    Ich überlege mal „laut“ 🙂

    Sieht so aus, als ob der Server keine Umlaute akzeptiert und diese immer wieder in irgendetwas anderes kodiert.

    Also müssen die Umlaute aus den Namen verschwinden. Heißt, alle Bilder mit entsprechenden Sonderzeichen im Namen müssen umbenannt werden.

    Da die Bildernamen ja nun auch in der Datenbank namentlich hinterlegt wurden, kann man die umbenannten Bilder nicht einfach per FTP hochladen und die alten überschreiben. In den Beiträgen / Seiten werden die Bilder mit den alten Dateinamen aufgerufen.

    1. Idee/Frage:
    Wie sehen die Dateinamen in der Datenbank aus? Existiert ein Schema, wie ä, ü, ö, ß dort hinterlegt wurden? Kann man mit Search&Replace etwas ausrichten? Bliebe noch ein Problem, mit eventuellen Leerzeichen in Dateinamen, das könnte man darüber nicht abfangen.

    2. Idee/Frage:
    Wenn die Bilder in der Mediathek existieren, also die Namen werden angezeigt und das Bild selbst nicht, könnte man folgendes machen:

    1.) das von mir erwähnte Plug-in installieren (das beim Hochladen die Bilder umbenennt)
    2.) das Plug-in „Enable Media Replace“ installieren und die fehlerhaften Bilder mit den neuen ersetzen. Geht leider nur Bild für Bild 🙁

    Plug-in 1 und 2 sollten in Kombination funktionieren. Falls nicht, einfach händisch umbenannte Bilder mit Plug-in 2 ersetzen.

    Sieht so aus, als ob der Server keine Umlaute akzeptiert und diese immer wieder in irgendetwas anderes kodiert.

    Wenn ich die Dateinamen im FTP-Client händisch korrigiere, funktioniert auch die Anzeige der Bilddatei auf der Webseite. Nur … wer will da jetzt alle Bilder einzeln anfassen?

    Da die Bildernamen ja nun auch in der Datenbank namentlich hinterlegt wurden, kann man die umbenannten Bilder nicht einfach per FTP hochladen und die alten überschreiben. In den Beiträgen / Seiten werden die Bilder mit den alten Dateinamen aufgerufen.

    In der Datenbank ist ja ein Bildname „Borussia-Mönchengladbach.jpg“ korrekt abgelegt, nur auf dem Webserver ist die Datei als „Borussiona-M????nchengladbach.jpg“ gespeichert. Korrigiere ich den Dateienamen per FTP, klappt alles. Versuche ich per ssh Umlaute einzugeben, passieren kuriose Dinge; vermutlich, weil die ssh-Verbindung schon mit dem falschen Zeichensatz aufgebaut wird.

    Ich hab jetzt erst mal auf den Support des Webhoster verwiesen. Das kommt sicher häufiger vor.

    Wenn ich die Dateinamen im FTP-Client händisch korrigiere, funktioniert auch die Anzeige der Bilddatei auf der Webseite. Nur … wer will da jetzt alle Bilder einzeln anfassen?

    Funktioniert aber nur, wenn du die Bilder mit Umlauten angibst, also 1:1 wie die Bilder derzeit in der Datenbank hinterlegt sind.

    Ich würde generell den Mist mit den Umlauten und Leerzeichen ausmerzen.
    https://wiki.selfhtml.org/wiki/HTML/Regeln/Konventionen_f%C3%BCr_Dateinamen
    Wenn viele Bilder betroffen sind, könnte man die auch herunterladen, und im Batch mit einem Tool wie Renamer http://www.den4b.com/?x=products&product=renamer umbenennen. Ö in Oe, etc.
    Für die Datenbank könnte man vielleicht die heruntergeladene Tabelle mit regex (kann ich aber nicht :-p) oder mit einem guten Editor, der entsprechende Funktionen hat, suchen und ersetzen.

    Du kannst natürlich mit dem Renamer auch die Umlaute wieder einfügen, in einem Schwung.

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 25)
  • Das Thema „Datenbank-Kollation“ ist für neue Antworten geschlossen.