Was ist die beste Kollation für MySQL mit PHP?

Question

Ich frage mich, ob es eine "beste" Wahl für die Sortierung in MySQL für eine allgemeine Website gibt, bei der man sich nicht 100%ig sicher ist, was eingegeben wird? Ich verstehe, dass alle Kodierungen gleich sein sollten, wie MySQL, Apache, HTML und alles in PHP.

In der Vergangenheit habe ich PHP so eingestellt, dass es in "UTF-8" ausgibt, aber zu welcher Sortierung passt das in MySQL? Ich denke, es ist eine der UTF-8-Kollationen, aber ich habe die utf8_unicode_ci , utf8_general_ci y utf8_bin vor.

Answer 1

Im Wesentlichen hängt es davon ab, wie man sich eine Zeichenkette vorstellt.

Ich verwende immer utf8_bin wegen des von Guus angesprochenen Problems. Meiner Meinung nach ist eine Zeichenkette, soweit es die Datenbank betrifft, immer noch nur eine Zeichenkette. Ein String ist eine Anzahl von UTF-8-Zeichen. Ein Zeichen hat eine binäre Repräsentation, also warum muss es die Sprache kennen, die Sie verwenden? In der Regel werden Datenbanken für Systeme erstellt, die für mehrsprachige Sites geeignet sind. Das ist der Sinn der Verwendung von UTF-8 als Zeichensatz. Ich bin eher ein Purist, aber ich denke, die Fehlerrisiken überwiegen bei weitem den leichten Vorteil, den man bei der Indizierung haben könnte. Alle sprachbezogenen Regeln sollten auf einer viel höheren Ebene als der des DBMS festgelegt werden.

In meinen Büchern sollte "Wert" nicht in einer Million Jahren mit "valúe" gleichgesetzt werden.

Wenn ich ein Textfeld speichern und eine Suche ohne Berücksichtigung der Groß-/Kleinschreibung durchführen möchte, verwende ich die MYSQL-Stringfunktionen mit PHP-Funktionen wie LOWER() und der PHP-Funktion strtolower().

Answer 2

Für UTF-8-Textinformationen sollten Sie utf8_general_ci weil...

• utf8_bin : Vergleich von Zeichenketten anhand des Binärwert jedes Zeichens in der der Zeichenkette

• utf8_general_ci : Zeichenketten vergleichen unter Verwendung allgemeiner Sprachregeln und Vergleiche ohne Berücksichtigung der Groß- und Kleinschreibung

d.h. die Suche und Indizierung der Daten soll schneller/effizienter/nützlicher werden.

Answer 3

Die akzeptierte Antwort schlägt ziemlich definitiv die Verwendung von utf8_unicode_ci vor, und während das für neue Projekte großartig ist, wollte ich meine jüngste gegenteilige Erfahrung erzählen, nur für den Fall, dass es jemandem etwas Zeit spart.

Weil utf8_general_ci die Standard-Kollation für Unicode in MySQL ist, müssen Sie, wenn Sie utf8_unicode_ci benutzen wollen, diese in einer Los von Orten.

So haben beispielsweise alle Client-Verbindungen nicht nur einen Standard-Zeichensatz (was ich für sinnvoll halte), sondern auch eine Standard-Sortierreihenfolge (d. h. die Sortierreihenfolge wird bei Unicode immer auf utf8_general_ci gesetzt).

Wenn Sie utf8_unicode_ci für Ihre Felder verwenden, müssen Ihre Skripte, die eine Verbindung zur Datenbank herstellen, wahrscheinlich aktualisiert werden, um die gewünschte Sortierung explizit zu erwähnen - andernfalls können Abfragen mit Textstrings fehlschlagen, wenn Ihre Verbindung die Standardsortierung verwendet.

Das Ergebnis ist, dass Sie bei der Konvertierung eines bestehenden Systems beliebiger Größe nach Unicode/utf8 gezwungen sein können, utf8_general_ci zu verwenden, weil MySQL mit Voreinstellungen umgeht.

Answer 4

Für den von Guus hervorgehobenen Fall würde ich dringend empfehlen, entweder utf8_unicode_cs (Groß-/Kleinschreibung beachten, strikte Übereinstimmung, größtenteils korrekte Reihenfolge) anstelle von utf8_bin (strikte Übereinstimmung, falsche Reihenfolge) zu verwenden.

Wenn das Feld durchsucht werden soll, anstatt es einem Benutzer zuzuordnen, dann verwenden Sie utf8_general_ci oder utf8_unicode_ci. Bei beiden wird die Groß- und Kleinschreibung nicht beachtet, bei der einen geht die Übereinstimmung verloren (' ist gleich 's' und nicht 'ss'). Es gibt auch sprachspezifische Versionen, wie z.B. utf8_german_ci, bei denen die Unterscheidung der Groß- und Kleinschreibung besser auf die angegebene Sprache abgestimmt ist.

[Bearbeiten - fast 6 Jahre später]

Ich empfehle nicht mehr den Zeichensatz "utf8" für MySQL, sondern den Zeichensatz "utf8mb4". Sie stimmen fast vollständig überein, lassen aber ein wenig (viel) mehr Unicode-Zeichen zu.

Realistischerweise hätte MySQL den "utf8"-Zeichensatz und die entsprechenden Sortierungen an die "utf8"-Spezifikation anpassen müssen, aber stattdessen einen separaten Zeichensatz und entsprechende Sortierungen verwenden sollen, um die Speicherbezeichnung für diejenigen, die bereits ihren unvollständigen "utf8"-Zeichensatz verwenden, nicht zu beeinträchtigen.

Answer 5

Ich fand diese Übersichtstabellen hilfreich. http://collation-charts.org/mysql60/ . Ich bin mir aber nicht sicher, welches das verwendete utf8_general_ci ist.

Hier ist zum Beispiel die Tabelle für utf8_swedish_ci. Sie zeigt, welche Zeichen sie als gleich interpretiert. http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html