Ich versuche herauszufinden, welche Sortierung ich für verschiedene Arten von Daten verwenden sollte. Der Inhalt, den ich speichern werde, wird zu 100% vom Benutzer übermittelt.
Nach meinem Verständnis sollte ich UTF-8 General CI (case-insensitiv) anstelle von UTF-8 Binary verwenden. Ich kann jedoch keine klare Unterscheidung zwischen UTF-8 General CI und UTF-8 Unicode CI finden.
Im Allgemeinen ist utf8_general_ci schneller als utf8_unicode_ci, aber weniger korrekt.
Hier ist der Unterschied:
Für jeden Unicode-Zeichensatz sind Operationen, die mit der _general_ci-Kollatierung ausgeführt werden, schneller als für die _unicode_ci-Kollatierung . Beispielsweise sind Vergleiche für die Sortierung utf8_general_ci schneller, aber etwas weniger korrekt als Vergleiche für utf8_unicode_ci. Der Grund dafür ist, dass utf8_unicode_ci Zuordnungen wie z. B. Erweiterungen unterstützt. Das heißt, wenn ein Zeichen mit Kombinationen anderer Zeichen verglichen wird. Zum Beispiel ist in Deutsch und einigen anderen Sprachen "ß" gleich "ss". utf8_unicode_ci unterstützt auch Kontraktionen und ignorierbare Zeichen. utf8_general_ci ist eine ältere Kollatierung, die keine Erweiterungen, Kontraktionen oder ignorierbaren Zeichen unterstützt. Es können nur Eins-zu-Eins-Vergleiche zwischen Zeichen durchgeführt werden.
Zitiert von: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html
Weitere Informationen finden Sie in folgendem Beitrag aus den MySQL-Foren: http://forums.mysql.com/read.php?103,187048,188748
Wie für utf8_bin: Beide utf8_general_ci und utf8_unicode_ci führen einen Vergleich ohne Berücksichtigung der Groß-/Kleinschreibung durch. utf8_bin unterscheidet (neben anderen Unterschieden) zwischen Groß- und Kleinschreibung , da es die Binärwerte der Zeichen vergleicht.
Sie sollten sich auch der Tatsache bewusst sein, dass mit utf8_general_ci, wenn Sie ein varchar-Feld als eindeutigen oder primären Index verwenden und 2 Werte wie 'a' und 'á' einfügen, ein doppelter Schlüsselfehler auftritt.
utf8_bin
Vergleicht die Bits blind. Kein Falten des Gehäuses, kein Abziehen von Akzenten.utf8_general_ci
Vergleicht ein Byte mit einem Byte. Dabei werden die Akzente und geklappt, es werden jedoch keine 2-Zeichen-Vergleiche durchgeführt: ij
ist hier nicht gleich ij
Kollation.utf8_*_ci
Ist ein Satz sprachspezifischer Regeln, aber ansonsten wie unicode_ci
. Einige Sonderfälle: Ç
, Č
, ch
, ll
utf8_unicode_ci
Folgt einem alten Unicode-Standard für Vergleiche. ij
= ij
, aber ae
! = æ
utf8_unicode_520_ci
Folgt einem neueren Unicode-Standard. ae
= æ
Siehe Kollatierungstabelle für Einzelheiten darüber, was in verschiedenen utf8-Kollatierungen gleich was ist.
utf8
, gemäß Definition in MySQL ist auf die utf8-Codes von 1 bis 3 Byte beschränkt. Dies lässt Emoji und einige Chinesen aus. Sie sollten also wirklich auf utf8mb4
Umsteigen, wenn Sie weit über Europa hinaus wollen.
Die obigen Punkte gelten für utf8mb4
Nach entsprechender Rechtschreibänderung. In Zukunft werden utf8mb4
Und utf8mb4_unicode_520_ci
Bevorzugt.
Wirklich, ich habe das Speichern von Werten wie 'é' und 'e' in einer Spalte mit eindeutigem Index getestet und sie verursachen doppelte Fehler sowohl bei 'utf8_unicode_ci' als auch bei 'utf8_general_ci' '. Sie können sie nur in der sortierten Spalte 'utf8_bin' speichern.
Und mysql docs (in http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html ) schlagen in seinen Beispielen die Kollatierung 'utf8_general_ci' vor.
[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
Akzeptierte Antwort ist veraltet.
Wenn Sie MySQL 5.5.3 oder höher verwenden, verwenden Sie utf8mb4_unicode_ci
anstatt utf8_unicode_ci
, um sicherzustellen, dass die von Ihren Benutzern eingegebenen Zeichen keine Fehler verursachen.
utf8mb4
unterstützt beispielsweise Emojis, während utf8
gibt Ihnen möglicherweise Hunderte von Fehlern im Zusammenhang mit der Codierung:
Incorrect string value: ‘\xF0\x9F\x98\x81…’ for column ‘data’ at row 1