Aufgrund der weit verbreiteten Verwendung verschiedener Multibyte-Zeichensätze weiß ein sehr hoher Anteil englischsprachiger Programmierer nicht viel über Multibyte-Zeichen. Aus diesem Grund sind viele Schwachstellen in den letzten Jahren auf Multibyte-Zeichen zurückzuführen. Der Autor dieses Artikels spricht über seine eigenen Ansichten zur Rolle der Zeichensatzarchitektur von MySQL. In den letzten Monaten habe ich jedes Mal, wenn ich MySQL verwende, fast immer gedacht: Ist die aktuelle hierarchische Zeichensatzarchitektur von MySQL wirklich nützlich?
Verarbeitung von MySQL-Zeichensätzen
Anfrage senden
Client (character_set_client)=》Datenbankverbindung (character_set_connection)=》Speicher (Tabelle, Spalte)
Rückgabeantrag
Speicher (Tabelle, Spalte)=》Datenbankverbindung (character_set_connection)=》Client (character_set_results)
An jedem nicht-anfänglichen Knoten wird eine Zeichensatzkonvertierungsoperation vom vorherigen Knoten zum aktuellen Knoten durchgeführt. Betrachten Sie beispielsweise die folgende Umgebung:
◆ Character_set_connection utf-8
◆ Character_set_results GBK
◆ Character_set_client gb2312
◆ Es gibt Tabelle A und die Feldzeichensätze sind alle BIG5
Beim Senden einer Anfrage werden die Daten zunächst von gbk nach utf-8, dann nach BIG5 konvertiert und dann gespeichert.
Bei der Rücksendung der Anfrage werden die Daten zunächst von BIG5 in utf-8, dann in gb2312 konvertiert und dann an den Client gesendet.
Die Rolle der Architektur
1. Erlauben Sie verschiedenen Clients, unterschiedliche Zeichensätze zu verwenden. Ein typisches Beispiel ist, dass ich eine UTF-8-Site habe, bei der es sich um einen Client mit einem UTF-8-Zeichensatz-Client handelt. Gleichzeitig muss ich möglicherweise die Datenbank auf einem GBK-Terminal lesen und schreiben, bei dem es sich um einen anderen Client handelt, dessen Zeichensatz jedoch GBK ist.
2. Wenn Sie das Dateisystem über die Datenbank betreiben, müssen Sie den Dateipfad in den Zeichensatz des Dateisystems konvertieren. Mein Client ist beispielsweise gbk und das Serverdateisystem ist utf-8. Bei der Operation „/A Slice/Rina.rmvb“ unterscheiden sich unter den gesendeten Daten die Daten von „Slice“ vom Server. Zu diesem Zeitpunkt muss es eine Möglichkeit geben, das „Slice“ von GBK in utf-8 zu konvertieren. Hier führt MySQL etwas namens „character_filesystem“ ein, um dies zu erreichen.
Ansonsten fallen mir im Moment keine anderen Verwendungsmöglichkeiten ein. Aber überlegen Sie es sich genau: Brauchen wir diese Art der Behandlung wirklich? Viele Websites hoffen einfach, dass ihre Daten so herauskommen, wie sie wollen. Hier gibt es noch zwei weitere Situationen.
1. Ich hoffe, dass ich anhand der Daten ähnliche Vorgänge sortieren oder ausführen kann. Lassen Sie uns zunächst über die Sortierung sprechen. Für Felder, die Chinesisch enthalten, ist das Konzept der Sortierung nach Zeichensätzen nutzlos. Wenn Sie vereinfachtes Chinesisch sortieren, sollten Sie im Allgemeinen nach Pinyin sortieren. Ich habe die Überprüfung in MySQL nicht wirklich verstanden, aber nach den Programmen, mit denen ich in Kontakt gekommen bin, zu urteilen, wird, wenn diese Art der Sortierung erforderlich ist, speziell ein Feld zum Speichern von Pinyin für die Sortierung erstellt. Es gibt auch polyphone Zeichen im Pinyin. Wenn es sich um UTF-8 handelt, gibt es auch eine Situation, in der ein bestimmter Bereich des Chinesischen gleichzeitig von China, Japan und Südkorea geteilt wird. Es ist nicht so einfach zu implementieren, daher sollten weder das GBK noch das UTF-8-Checkset von MySQL Pinyin implementieren. Ich wage zu behaupten, dass die meisten Websites in China, die MySQL verwenden, jetzt einen Prüfsatz verwenden, der nur eine Byte-Sortierung ist. Bei der Bytesortierung ist es überhaupt nicht erforderlich, einen Zeichensatz zu verwenden. Daher hat die MySQL-Zeichenüberprüfung für chinesische Websites beim Sortieren keine Bedeutung.
Aber im Hinblick auf die gleiche Funktionsweise hat es durchaus eine gewisse Bedeutung. Wenn mir zum Beispiel „%a%“ gefällt, ist es möglich, ein chinesisches Zeichen zu finden, das an einem bestimmten Teil ein enthält. Unter UTF-8 tritt diese Situation natürlich nicht auf, da das Speicherformat von UTF-8 bedeutet, dass a nur ein und kein Teil eines Mehrbyte-Zeichens sein kann. Dieses Problem kann jedoch auch bei anderen Zeichensätzen auftreten. Am Ende wird Gleiches gleichbedeutend mit Ordnung, wodurch die Überprüfung bedeutungslos wird. schwach.
2. Wenn keine Notwendigkeit besteht, die Daten zu sortieren oder eine Volltextsuche durchzuführen, verwenden Sie bitte keine Zeichen, Varchars, Texte mehr usw. Binär, Varbinär und BLOB sind die richtigen Optionen. Binär und dergleichen führen beim Speichern und Abrufen keine Zeichensatzkonvertierung durch, aber beim Sortieren werden sie nur nach dem Binärinhalt sortiert, sodass die Effizienz viel höher ist als die von char, varchar und text.
In diesem Fall ist kein Zeichensatz erforderlich. Gemäß der aktuellen MySQL-Architektur werden Zeichensatzoperationen zwischen Client- und Verbindungs-Ignorierfeldtypen jedoch weiterhin zwischen diesen beiden Knoten durchgeführt.
Erwähnen Sie auch die Zeichensatzeinstellung in PHP. Bitte hören Sie auf, Anweisungen wie mysql_query("set name utf8") zu verwenden. mysql_set_charset() ist die umfassendste Methode zum Festlegen von Zeichensätzen. Letzteres hat eine Einstellung mehr als Ersteres, nämlich das Festlegen des Zeichensatzmitglieds von struct MySQL. Diese Mitgliedsvariable spielt beim Escape eine sehr wichtige Rolle, insbesondere bei Codierungsformaten wie GBK, die „“ als Teil des Zeichens verwenden. Wenn Sie nur mysql_query("set labels
-