MySQL-Chinesische verstümmelte Lösungssammlung

Die erste Methode:
Das Problem der verstümmelten chinesischen Zeichen in MySQL 4.1
Ich habe kürzlich MySQL 4.0 auf MySQL 4.1 aktualisiert und das Problem der verstümmelten chinesischen Zeichen entdeckt. Ich hoffe, dass die folgenden Erkenntnisse für alle nützlich sind.
1. MySQL 4.1 hat den Text erheblich verbessert. Es verfügt über die Konzepte Zeichensatz und Sortierung.
2. In MySQL 4.0 speichern allgemeine Programme Text in lateinischer Sprache. Auch wenn wir chinesische Zeichen eingeben, wird das Ergebnis weiterhin in der lateinischen Textspalte abgelegt ist für Gichus Programme kein Problem.
3. Die Systemkodierung von MySQL 4.1 ist jedoch standardmäßig UTF-8. Wenn Sie die Sicherungsdatei von MySQL 4.0 auf MySQL 4.1 wiederherstellen möchten, werden verstümmelte Zeichen angezeigt. Der Grund dafür ist, dass MySQL 4.1 lateinische Codes konvertiert und die Konvertierung dann nicht vollständig perfekt ist, was dazu führt, dass eine kleine Textmenge verstümmelt wird.
Lösung des verstümmelten Problems des PHP-Zugriffs auf MySQL 4.1
ZITAT:
Die mit MySQL 4.1 eingeführte Mehrsprachenunterstützung ist wirklich großartig und einige Funktionen haben andere Datenbanksysteme übertroffen. Während des Tests habe ich jedoch festgestellt, dass die Verwendung von PHP-Anweisungen, die für MySQL vor 4.1 geeignet sind, zum Betreiben der MySQL-Datenbank zu verstümmelten Zeichen führt, selbst wenn der Tabellenzeichensatz festgelegt ist. Nachdem ich Kapitel 10 „Zeichensatzunterstützung“ im neuen MySQL-Online-Handbuch gelesen hatte, fand ich endlich die Lösung und bestand den Test.
Die Zeichensatzunterstützung (Character Set Support) von MySQL 4.1 umfasst zwei Aspekte: Zeichensatz (Zeichensatz) und Sortiermethode (Sortierung). Die Unterstützung für Zeichensätze wurde auf vier Ebenen verfeinert: Server, Datenbank, Tabelle und Verbindung.
Um den Zeichensatz und die Sortiereinstellungen des Systems anzuzeigen, können Sie die folgenden zwei Befehle verwenden:
MYSQL> -------------------+--------------- ----+
|. Variablenname |.
+----------- ---- ----+
|. latin1 | |. charakter_set_server |. zeichen_satz_system |. ---- ------------+-------------+
7 Zeilen im Satz (0,00 Sek.)
mysql> SHOW VARIABLES LIKE 'collation_%'+-------+--- ------------+
|. Variablenname |. -----+
|. latin1_swedish_ci | +---- -------------------+-------------------+
3 Reihen in set (0,00 Sek.)
Die oben aufgeführten Werte sind die Standardwerte des Systems. Wenn Sie sich fragen, warum das System standardmäßig die schwedische Sortiermethode „latin1“ verwendet, liegt der Grund darin, dass MySQL von der schwedischen Firma T.c. entwickelt wurde.
Wenn wir auf die ursprüngliche Weise über PHP auf die MySQL-Datenbank zugreifen, werden Sie feststellen, dass die in der Datenbank gespeicherten Daten selbst dann vorhanden sind, wenn wir den Standardzeichensatz der Tabelle auf utf8 festlegen und die Abfrage über die Codierung UTF-8 senden immer noch verstümmelt. Das Problem liegt in dieser Verbindungsschicht. Die Lösung besteht darin, vor dem Senden der Abfrage den folgenden Satz auszuführen:
SET NAMES 'utf8'
Es entspricht den folgenden drei Anweisungen:
SET Character_set_client = utf8; SET Character_set_results = utf8;
SET Character_set_connection = utf8;
Versuchen Sie es noch einmal, ist es normal?
Fügen Sie einfach eine Abfrage hinzu, nachdem Sie eine Verbindung hergestellt haben.
CODE:
$this->query("SET NAMES 'utf8＇"); Zeichensätze.
Die drei Betriebsvariablen „character_set_client“, „character_set_results“ und „character_set_connection“ sind der Schlüssel zur Entstehung verstümmelter Zeichen. MySQL konvertiert die vom Client übermittelte Abfrage von „character_set_client“ in „character_set_connection“
, da die von der Standardwebseite übermittelte Abfrage gb2312 ist (siehe Meta der Formularseite) und MySQL sie standardmäßig als utf8 behandelt (Sie können finden). der Character_set_client ist zu diesem Zeitpunkt =utf8), daher muss er verstümmelt sein. Auf die gleiche Weise wurden die von MySQL zurückgegebenen Ergebnisse in die Codierung „character_set_results“ konvertiert (dies hat nichts mit der Codierung der Tabelle zu tun). Der Standardwert ist utf8 und die Webseite behandelt es als gb2312, daher müssen verstümmelte Felder vorhanden sein B. Titel und andere aus der Datenbank gelesene Felder. Der Text in anderen Abteilungen ist nicht verstümmelt.
Das obige Beispiel ist der utf8-Zeichensatz und setzt ihn auf gbk, um das Problem zu lösen:
Die ultimative Lösung für verstümmelte MySQL 4.1-Zeichen.
Bitte beachten Sie, dass dies der Fall ist Der Artikel gilt nur für MySQL 4.1. Weitere Informationen zu anderen Versionen von MySQL finden Sie in anderen Artikeln.
mysql4.1 ist ziemlich nervig, es unterstützt mehrsprachige Detaileinstellungen und phpmyadmin2.6 ist auch relativ dumm. Die Standardeinstellung ist utf8, die nicht geändert werden kann, und es wird verstümmelt, egal wie Sie es erstellen.
Okay, ohne weitere Umschweife, lösen wir dieses Problem Schritt für Schritt:
1. Ändern Sie die Datei /etc/my.cnf wie folgt:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/lib
[ mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Hinweis: Habe gerade einen Standardzeichensatz =utf8 hinzugefügt.
2./etc/init.d/mysqld restart MySQL neu starten;
3. Öffnen Sie phpmyadmin, wählen Sie lang als „China vereinfacht (zh-utf-8)“, wählen Sie „MySQL-Verbindungskorrekturlesen“ als „utf8_general_ci“. „Klicken Sie auf „MySQL-Laufinformationen anzeigen“ – „Variablen“. Sie können Folgendes sehen:
Zeichensatz-Client utf8 utf8
Zeichensatzverbindung utf8 utf8
Zeichensatzdatenbank utf8 utf8
Zeichensatzergebnisse utf8 utf8
Zeichensatzserver utf8 utf8
Zeichensatzsystem utf8 utf8
Sortierungsverbindung utf8_general_ci utf8_general_ci
Sortierungsdatenbank utf8_general_ci utf8_general_ci
Sortierungsserver utf8_general_ci utf8_general_ ci
Von hier aus können Sie sehen, dass alle Zeichen utf8 werden .
Jemand fragt sich vielleicht, warum wir es in utf8 ändern müssen? Ist es nicht möglich, es auf GB2312 zu ändern?
Die Erklärung lautet wie folgt:
Ich möchte es nicht in utf8 ändern, aber phpmyadmin2.6 verwendet utf8 nur, wenn mysql4.1 ausgeführt wird. Sogar der Zeichensatz anderer Seiten ist utf8 wird definitiv zu verstümmelten Zeichen führen. Ich kann nur phpmyadmin verwenden.
Nur ​​in mysql3.23 verfügt phpmyadmin über einen zusätzlichen Seitenzeichensatz von gb2312, was derzeit normal ist.
3. Importieren Sie die vorherige MySQL3-Bibliotheksdatei in die MySQL4.1-Bibliothek.
Es gibt zwei Situationen:
Zu diesem Zeitpunkt sollten Sie auf die untere linke Ecke achten Seite, auf der Sie die Bibliotheksdatei auswählen: In der Fußzeile befindet sich der Standardwert utf8, der in gb2312 geändert werden muss, andernfalls wird der Import verstümmelt Unter Linux importieren müssen Sie zu diesem Zeitpunkt eine Zeile zum Kopf der Bibliotheksdatei hinzufügen:
SET NAMES 'gb2312';
Führen Sie dann mysql -u Benutzername -p Passwort xxx.sql > Bibliotheksname aus.
Nachdem der Import abgeschlossen ist, öffnen Sie ihn mit phpmyadmin und prüfen Sie, ob die darin enthaltenen chinesischen Zeichen korrekt sind.
4. Exportieren Sie die Bibliotheksdatei aus mysql4.1
Der Export ist kein großes Problem. Wenn die auf der Browserseite von phpmyadmin angezeigte Datei normal ist, muss dies auch der Fall sein normal
2. Unter Linux exportieren
Es spielt keine Rolle, ob beim Exportieren mit mysqldump verstümmelte Zeichen angezeigt werden. Sie können iconv ausführen, um den Namen der GB2312-Bibliotheksdatei zu konvertieren > Neu gb2312 Der Name der Bibliotheksdatei
Zusammenfassend sollten Sie Folgendes beachten:
1. Versuchen Sie, SET NAMES „gb2312“ am Anfang der zu importierenden Bibliotheksdatei hinzuzufügen. Teilen Sie MySQL mit, dass es sich bei dem, was Sie importieren möchten, um eine gb2312-Datei handelt. Möglicherweise benötigen Sie Folgendes:
SET NAMES 'utf8'; Verwenden Sie es nach der Anmeldung bei MySQL. Ändern Sie einige Standardparameter des Zeichens in utf8.
Verwenden Sie auf MySQL:
SHOW VARIABLES LIKE 'character_set_%';
3. Seien Sie nicht beunruhigt, wenn verstümmelte Zeichen angezeigt werden. Erstens sollten Sie darauf achten, die ursprüngliche Sicherung beizubehalten, und zweitens sollten Sie zum Konvertieren iconv verwenden.
Führen Sie vor dem normalen Gebrauch unbedingt Import- und Exporttests durch, um sicherzustellen, dass nichts schief geht.
Lassen Sie mich noch einmal erklären, dass Mysql4.1 nur aktualisiert und nicht heruntergestuft werden kann. Dies ist auch falsch. Verwenden Sie mysqldump, um die Datenbank zu exportieren. Vergessen Sie nicht. -default-character-set=Dieser Parameter stellt den Zeichensatz ein Auf diese Weise exportierte Dateien können in Mysql 4.1 verwendet werden. Ab .1 ist das Problem der Unterstützung von MySQL für Chinesisch ziemlich ärgerlich Neue Ära von MySQL, aber MySQL5 hat immer noch verstümmelte Zeichen zu diesem Phänomen:
Es wird empfohlen, den Quellcode von MySQL herunterzuladen und zu kompilieren Die Kodierung des offiziell kompilierten MySQL ist der lateinische Zeichensatz, sodass chinesische Schriftzeichen bei der Anzeige in der Datenbank verstümmelt sind. Verwenden Sie beim Kompilieren von MySQL die Codierung withcharset=. Sie können MySQL problemlos in diese Codierungsform kompilieren, sodass MySQL die chinesische Suche und Sortierung direkt unterstützt. Der Parameter --with-extra-charsets gibt andere verfügbare Zeichensätze an.
Laden Sie das Quellcodepaket herunter, entpacken Sie es, öffnen Sie INSTALL-SOURCE. Hier ist die detaillierte Installationsmethode unter Linux. Sie müssen also nur auf den folgenden Konfigurationsbefehl achten:
groupadd mysql
useradd -g MySQL MySQL
./configure --with-charset=gbk --with-collation=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql
make
make install
cp support-files/my-medium.cnf /etc/my.cnf
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
chown -R root .
chown -R mysql var
chgrp -R mysql .
bin/mysql
show variables; Die globalen Zeichensatzparameter sind alle gbk, und der gb2312-Zeichensatz sollte in gbk enthalten sein, daher werden wir nicht darauf eingehen.
Führen Sie den gleichen PHP-Vorgang wie bei normalem MySQL 4.0 aus. Sie werden feststellen, dass immer noch chinesische verstümmelte Zeichen angezeigt werden.
Was hier erklärt werden muss: Ab MySQL 4.1 muss der Zeichensatz der Anwendung nach der Verbindung mit der MySQL-Datenbank angegeben werden, da sonst der Textzugriff mit nicht-englischen Buchstaben nicht interpretiert und in ein ?-Zeichen umgewandelt werden kann .
Die Lösung besteht darin, sich an die Anforderungen der neuen MySQL-Version anzupassen:
Nachdem Sie eine Verbindung zur MySQL-Datenbank hergestellt haben, führen Sie den Befehl „Set Character Set“ aus. Dieser Befehl kann in der neuesten Version von MySQL 5 ausgenommen werden Der Standardzeichensatz entspricht dem Speicher:
set Character set gbk;
Es sollte in PHP wie folgt geschrieben werden: mysql_query("set Character set gbk");
Die Anweisungen können in Groß- oder Kleinbuchstaben geschrieben werden
phpwind und discuz sind weit verbreitete inländische PHP-Foren, die von vielen verwendet werden. Nachdem Sie die obigen Schritte verstanden haben, können Sie auch kleine Änderungen am Quellcode des Forums vornehmen und die Datenbank sicher auf MySQL5 aktualisieren:
Find include /db_mysql.php und ändern Sie die Funktion connect(...){. ....}
Fügen Sie den Satz mysql_query('setcharacter set gbk'); nach der ausgewählten Datenbank hinzu und speichern Sie ihn.
2. Import und Export von Dateien: Wenn Sie Nicht-GBK-Zeichen speichern, müssen Sie am Kopf der importierten Datei eine Zeile hinzufügen: SET NAMES „Zeichensatz“ und auf das ;-Zeichen am Ende achten , verpassen Sie es nicht.
Dateiimport und -export ausführen
mysql -u Benutzername-p Passwort-Datenbankname
mysqldump -u Benutzername-p Passwort-Datenbankname>data.sql
Wenn Sie mysqldump zum Exportieren von Daten verwenden, werden verstümmelte Zeichen angezeigt Es spielt keine Rolle, Sie können iconv ausführen, um es zu konvertieren:
iconv -c -f utf8 -t GBK-Bibliotheksdateiname>Neuer GBK-Bibliotheksdateiname
Zusammenfassend sollten Sie auf Folgendes achten:
1. Versuchen Sie, am Anfang der zu importierenden Bibliotheksdatei den Namen „gbk“ hinzuzufügen. Teilen Sie MySQL mit, dass Sie eine gbk-Datei importieren möchten. Verwenden Sie Show-Variablen oder Show-Variablen wie „character_set_%“ auf MySQL, um den aktuellen Zeichensatzstatus anzuzeigen.
3. Haben Sie keine Angst, wenn verstümmelte Zeichen erscheinen. Erstens sollten Sie darauf achten, das Original-Backup beizubehalten, und zweitens sollten Sie es mit iconv konvertieren.
#PHP-Verbindungsproblem:
Aufgrund der Änderung des Passwort-Hash-Algorithmus ab MySQL Version 4.1 unterstützt der Client möglicherweise kein Authentifizierungsprotokoll. Bei der Verbindung mit der Datenbank kann ein Problem auftreten.
Dieses Problem besteht in MySQL 5 nicht , MySQL 5 Die folgenden Einstellungen sind nicht erforderlich.
Sie können das Problem der Inkonsistenz des Datenbankbenutzerpassworts durch die folgenden zwei Methoden lösen:
Erstens: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd'); ; Update mysql.user SET Password = OLD_PASSWORD('newpwd') Where Host = 'some_host' AND User = 'some_user'
Andere Probleme mit verstümmeltem Code in der PHP-Ausgabe:
Wenn MySQL in die Standardkodierung gbk kompiliert wird, Dies wird erneut passieren. Der direkte Import von Nicht-GBK-Daten führt zu verstümmelten Zeichen, z. B. einigen in UTF8 gespeicherten Zeichen. Wenn die meisten Ihrer Daten im UTF8-Zeichensatz vorliegen, müssen Sie MySQL natürlich mit der Standardkodierung von UTF8 kompilieren .
Nach der Veröffentlichung von Mysql 4.1. 🎜>Erstellen Sie DATABASE „mytest“ DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
Sie müssen diese Anweisung auch zum Festlegen verwenden Nach dem Herstellen einer Verbindung zur MySQL-Datenbank können Sie die korrekt codierten Zeichen im PHP-Programm abrufen und auf der Webseite anzeigen.
mysql_query("setnamen 'utf8'",$connection);
Lassen Sie mich noch einmal erklären, dass Mysql4.1 nur aktualisiert und nicht heruntergestuft werden kann Zum Exportieren fügen Sie der Datenbank einen --kompatiblen Parameter hinzu. Vergessen Sie nicht den Parameter --default-character-set=, um den Zeichensatz festzulegen.
Demonstration: mysqldump -uroot -pPassword --kompatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
ok Die auf diese Weise exportierte Datei kann in Mysql4.0.X verwendet werden und Wird in Mysql.3.2 verwendet. Ich möchte es mir nicht einmal ansehen, aber nachdem ich darüber nachgedacht habe, ist es aus vier Gründen immer noch sinnvoll, es aufzuschreiben:
MySQL 4.1 hat eine große Änderung in der Mehrsprachenunterstützung (was zu Problemen führt);
MySQL 3 dominiert immer noch die meisten Orte (sowohl für den persönlichen Gebrauch als auch für Hosting-Anbieter); MySQL 4.1 ist jedoch bereits die von MySQL empfohlene Datenbank Wird von Hosting-Anbietern bereitgestellt und wird immer häufiger bereitgestellt.
Viele PHP-Programme verwenden MySQL als Standard-Datenbankverwaltungssoftware, unterscheiden jedoch im Allgemeinen nicht zwischen MySQL 4.1 und Versionen unter 4.1. xx oder höher“ kann die Installationsanforderungen erfüllen;
Da latin1 an vielen Stellen als Standardzeichensatz verwendet wird (die spezifischen Stellen werden weiter unten ausführlich beschrieben), hat es viele PHP-Programme erfolgreich getäuscht. Entwickler und Benutzer, Abdeckung Probleme, die in chinesischen und anderen Sprachumgebungen auftreten können;
Einfach ausgedrückt ignorieren Änderungen in MySQL selbst und PHP-Programmen, die MySQL verwenden, die Entstehung und Komplexität von Problemen. Da die meisten Benutzer Englisch verwenden, ist dieses Problem nicht der Fall ernst genommen. Bei dem hier erwähnten PHP-Programm geht es hauptsächlich um WordPress.
Das Prinzip der Zeichensatzunterstützung in MySQL 4.1. Die Spezifikation des Zeichensatzes in MySQL 4.1 kann dahingehend verfeinert werden, welcher Zeichensatz für MySQL verwendet werden soll, das auf einem Computer, einer der Datenbanken, einer der Tabellen und einer installiert ist der Spalten. Herkömmliche Webprogramme verwenden jedoch keine derart komplexen Konfigurationen, wenn sie Datenbanken und Datentabellen erstellen. Woher kommt also die Standardkonfiguration?
Beim Kompilieren von MySQL wird ein Standardzeichensatz angegeben, nämlich latin1.
Bei der Installation von MySQL können Sie einen Standardzeichensatz in der Konfigurationsdatei (my.ini) angeben. Dieser Wert wird vererbt von dem bei der Kompilierung angegebenen Wert;
Beim Starten von mysqld können Sie einen Standardzeichensatz im Befehlszeilenparameter angeben. Wenn nicht angegeben, wird dieser Wert aus der Konfigurationsdatei geerbt.
Zu diesem Zeitpunkt ist „character_set_server“ festgelegt dieser Standardzeichensatz;
Beim Erstellen einer neuen Datenbank wird der Zeichensatz dieser Datenbank standardmäßig auf „character_set_server“ eingestellt.
Wenn eine Datenbank ausgewählt wird, wird „character_set_database“ auf den Standardzeichensatz dieser Datenbank festgelegt Datenbank;
Beim Erstellen einer Tabelle in dieser Datenbank wird der Standardzeichensatz der Tabelle auf „character_set_database“ festgelegt. Dies ist der Standardzeichensatz dieser Datenbank.
Wenn in der Tabelle eine Spalte festgelegt wird, sofern nicht ausdrücklich angegeben Der Standardzeichensatz dieser Spalte ist der Standardzeichensatz der Tabelle.
Dieser Zeichensatz ist der tatsächlich zum Speichern von Daten in der Datenbank verwendete Inhalt 🎜>Um es kurz zusammenzufassen: Wenn nichts geändert wird, werden alle Felder aller Tabellen in allen Datenbanken in latin1 gespeichert. Wenn wir jedoch MySQL installieren, wählen wir im Allgemeinen die Unterstützung mehrerer Sprachen, d. h. das Installationsprogramm setzt default_character_set in der Konfigurationsdatei automatisch auf UTF-8, wodurch sichergestellt wird, dass standardmäßig alle Felder aller Tabellen in allen Datenbanken in UTF-8 gespeichert werden.
Welchen Zeichensatz verwenden die vom Programm an MySQL gesendeten Daten, wenn ein PHP-Programm eine Verbindung mit MySQL herstellt? MySQL hat keine Möglichkeit, es zu wissen (es kann bestenfalls raten), daher erfordert MySQL 4.1, dass der Client diesen Zeichensatz angibt, nämlich charakter_set_client. Das Seltsame an MySQL ist, dass der erhaltene Zeichensatz nicht sofort in den Zeichensatz konvertiert wird Dieser Zeichensatz wird in der Datenbank gespeichert, aber zuerst in einen durch die Variable „character_set_connection“ angegebenen Zeichensatz konvertiert. Ich verstehe nicht ganz, wofür die Verbindungsschicht verwendet wird, aber nach der Konvertierung in den Zeichensatz von „character_set_connection“ muss dies auch der Fall sein in den Standardzeichensatz der Datenbank konvertiert werden, d.
Eine typische Umgebung ist die Installation von MySQL 4.1 auf meinem eigenen Computer. Auf meinem eigenen Computer sind PHP 5 und WordPress 1.5.1.3 installiert. Es entsteht also das Problem:
WordPress ist standardmäßig installiert, daher verwenden alle Tabellen UTF-8 zum Speichern von Daten
Der von WordPress übernommene Standard-Browsing-Zeichensatz ist UTF-8 (eingestellt in Optionen->Lesen). Daher zeigt das Meta aller WP-Seiten an, dass der Zeichensatz utf-8 ist. Der Browser zeigt also alle WP-Seiten im utf-8-Modus an. Alle Beiträge und Kommentare von Write werden in UTF angezeigt. 8-Format. Der Browser sendet sie an Apache, und Apache sendet sie an PHP. Die Daten, die WP von allen Formularen erhält, werden also ohne Konvertierung direkt an MySQL gesendetMySQLs Standard-Character_set_client und Character_set_connection sind beide latin1. Zu diesem Zeitpunkt passierte etwas Seltsames. Es handelte sich tatsächlich um Daten im UTF-8-Format, die in „latin1“ konvertiert wurden, und dann in „latin1“. Nach diesen beiden Konvertierungen gehen einige utf-8-Zeichen verloren und werden zu „??“. In der endgültigen Ausgabe wird „character_set_results“ standardmäßig auf „latin1“ gesetzt, was bedeutet, dass die Ausgabe seltsam ist.
Das Erstaunlichste ist nicht, dass wenn WordPress auf das Lesen im GB2312-Format eingestellt ist, die von WP an MySQL gesendeten GB2312-codierten Daten „als latin1“ konvertiert und in einem seltsamen Format in der Datenbank gespeichert werden ( It ist wirklich ein seltsames Format. Unabhängig davon, ob es als utf-8 oder gb2312 gelesen wird, ist es verstümmelt. Wenn dieses Format jedoch als latin1 ausgegeben wird, kann es wieder in GB2312 geändert werden.
Welches Phänomen wird dadurch verursacht? Wenn WP die MySQL 4.1-Datenbank verwendet, ist es normal, wenn die Kodierung auf GB2312 geändert wird. Leider ist diese Normalität nur oberflächlich.
So lösen Sie das Problem Wenn Sie (mit ziemlicher Sicherheit) ungeduldig sind, googeln Sie es und Sie werden feststellen, dass die meisten Antworten darin bestehen, die Abfrage vorher auszuführen: SET NAMES 'utf8', ja, das ist die Lösung, aber das Der Zweck dieses Artikels besteht darin, zu erklären, warum dies die Lösung ist.
Um sicherzustellen, dass die Ergebnisse korrekt sind, müssen wir sicherstellen, dass das in der Datentabelle verwendete Format korrekt ist, das heißt, dass mindestens alle chinesischen Zeichen gespeichert werden können. Dann haben wir nur zwei Möglichkeiten: gbk oder utf-8. Lassen Sie uns unten die Situation von utf-8 besprechen.
Da der in der Konfigurationsdatei festgelegte Standardzeichensatz utf8 ist, wird die Datentabelle standardmäßig mit utf-8 erstellt. Dies sollte die Konfiguration sein, die von allen Hosting-Anbietern übernommen wird, die MySQL 4.1 verwenden. Wir müssen also lediglich sicherstellen, dass die angegebene Kodierung zwischen dem Client und MySQL korrekt ist.
Es gibt nur zwei Möglichkeiten: Der Client sendet Daten im GB2312-Format oder sendet Daten im UTF-8-Format.
Beim Senden im gb2312-Format:
SET Character_set_client='gb2312'
SET Character_set_connection='utf8' oder
SET Character_set_connection='gb2312'
Beide sind akzeptabel, beide können sicherstellen, dass die Daten ist in Während der Kodierungskonvertierung treten keine Verluste auf, was bedeutet, dass garantiert der richtige Inhalt in der Datenbank gespeichert wird.
Wie kann sichergestellt werden, dass der richtige Inhalt abgerufen wird? Wenn man bedenkt, dass bei den meisten Clients (einschließlich WP) die Kodierung der gesendeten Daten die Kodierung der Daten ist, die sie zu empfangen hoffen, kann also mit
SET Character_set_results='gb2312'
sichergestellt werden, dass das vom Browser angezeigte Format angezeigt wird wird herausgenommen Es ist gb2312.
Wenn es sich um den zweiten Fall handelt, sendet der Client im UTF-8-Format (Standard von WP). Sie können die folgende Konfiguration verwenden:
SET Character_set_client='utf8'
SET Character_set_connection='utf8'
SET Character_set_results='utf8'
Diese Konfiguration entspricht SET NAMES 'utf8'.
Welche Änderungen WP vornehmen sollte, ist immer noch derselbe Satz. Es ist für die Datenbank unmöglich, genau zu wissen, welche codierten Daten der Kunde an die Datenbank senden möchte. Daher muss WP dies klar erklären korrektes SET ... für MySQL. Wie verschickt man es am besten? Taiwans pLog-Kollegen gaben einige Vorschläge:
Testen Sie zunächst, ob der Server >= 4.1 ist und ob UTF-8-Unterstützung während der Kompilierung hinzugefügt wird. Wenn ja, fahren Sie fort
Testen Sie dann das Format, in dem die Datenbank gespeichert ist ($ dbEncoding) ;
SET NAMES $dbEncoding
Für den zweiten Punkt ist die Situation von WP anders, solange Sie WP verwenden, muss die Datenbank also in UTF-8 gespeichert werden Es muss auf den Benutzereinstellungen basieren, die durch Durchsuchen (bloginfo('charset')) beurteilt werden können. Dieser Wert kann jedoch erst nach dem Herstellen einer Verbindung zur Datenbank abgerufen werden. Daher ist es am effizientesten, SET festzulegen Benennen Sie diese Konfiguration einmal, nachdem Sie eine Verbindung zur Datenbank hergestellt haben, anstatt sie jedes Mal vor jeder Abfrage festlegen zu müssen.
Meine Änderungsmethode ist wie folgt, fügen Sie wp_includes/wp-db.php hinzu:
function set_charset($charset)
{
// Überprüfen Sie zuerst die MySQL-Version
$serverVersion = mysql_get_server_info ($this->dbh);
$version = explosion('.', $serverVersion);
if ($version[0] < 4) return; wurde kompiliert in
$result = mysql_query("SHOW CHARACTER SET like 'utf8'",
$this->dbh);
if (mysql_num_rows($result) < = 0) return ; 🎜>if ($charset == 'utf-8' || $charset == 'UTF-8')
$charset = 'utf8'
@mysql_query("SET NAMES '$charset'", $this->dbh);
}
In wp-settings.php require (ABSPATH . WPINC . '/vars.php'); hinzufügen:
$wpdb->set_charset (get_bloginfo(' charset'));

1. MySQL 4.1 hat die Konzepte Zeichensatz und Sortierung erheblich verbessert.
2. In MySQL 4.0 speichern allgemeine Programme Text in lateinischer Sprache. Auch wenn wir chinesische Zeichen eingeben, wird das Ergebnis weiterhin in der lateinischen Textspalte abgelegt. Dies unterscheidet sich zwischen MySQL 4.0 und MySQL 4.0. Es gibt kein Problem.
3. Die Systemkodierung von MySQL 4.1 ist jedoch standardmäßig UTF-8. Wenn Sie die Sicherungsdatei von MySQL 4.0 auf MySQL 4.1 wiederherstellen möchten, werden verstümmelte Zeichen angezeigt. Der Grund dafür ist, dass MySQL 4.1 lateinische Codes konvertiert und die Konvertierung dann nicht vollständig perfekt ist, was dazu führt, dass eine kleine Textmenge verstümmelt wird.
4. Es ist nicht schwer, dieses Problem mit verstümmeltem Code zu lösen. Wenn Sie MySQL 4.0 sichern, ändern Sie zunächst alle Textfelder in den Binärtyp und führen Sie dann eine normale Sicherung durch. Im zweiten Schritt können Sie das vorherige Backup in MySQL 4.1 wiederherstellen. Zum Schluss setzen Sie das Textfeld, das zuvor in den Binay-Typ geändert wurde, wieder auf den Texttyp zurück. Auf diese Weise sollte das Problem der chinesischen Kodierung vollständig gelöst werden.
5. Wenn Sie das Textfeld in den Binärtyp ändern, müssen Sie die Länge der Binärspalte so einstellen, dass sie größer oder gleich (>=) der Länge des Textfelds ist, andernfalls gehen die Daten verloren.
6. Darüber hinaus funktioniert die auf diese Weise aktualisierte MySQL-Datenbank in MySQL 4.1 normal und es treten keine verstümmelten Zeichen mehr auf, unabhängig davon, wie Sie sie sichern und wiederherstellen.
Autor: MySQL Veröffentlichungsdatum: 14.12.2005
mysql4.1 ist ziemlich nervig, es unterstützt mehrsprachige Detaileinstellungen und phpmyadmin2.6 ist auch relativ dumm. Die Standardeinstellung ist utf8, die nicht geändert werden kann. Egal wie man es macht, es ist alles durcheinander.
Okay, genug Unsinn, lasst uns dieses Problem Schritt für Schritt lösen:
1. Ändern Sie die Datei /etc/my.cnf wie folgt:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/ lib
[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Hinweis: Habe gerade einen Standard-Zeichensatz= hinzugefügt utf8.
2./etc/init.d/mysqld restart MySQL neu starten;
3. Öffnen Sie phpmyadmin, wählen Sie lang als „China vereinfacht (zh-utf-8)“, wählen Sie „MySQL-Verbindungskorrekturlesen“ als „utf8_general_ci“. „Klicken Sie auf „MySQL-Laufinformationen anzeigen“ – „Variablen“. Sie können Folgendes sehen:
Zeichensatz-Client utf8 utf8
Zeichensatzverbindung utf8 utf8
Zeichensatzdatenbank utf8 utf8
Zeichensatzergebnisse utf8 utf8
Zeichensatzserver utf8 utf8
Zeichensatzsystem utf8 utf8
Sortierungsverbindung utf8_general_ci utf8_general_ci
Sortierungsdatenbank utf8_general_ci utf8_general_ci
Sortierungsserver utf8_general_ci utf8_general_ ci
Von hier aus können Sie sehen, dass alle Zeichen utf8 werden .
Jemand fragt sich vielleicht, warum wir es in utf8 ändern müssen? Ist es nicht möglich, es auf GB2312 zu ändern?
Die Erklärung lautet wie folgt:
Ich möchte es nicht in utf8 ändern, aber phpmyadmin2.6 verwendet utf8 nur, wenn mysql4.1 ausgeführt wird. Sogar der Zeichensatz anderer Seiten ist utf8 wird auf jeden Fall zu verstümmelten Zeichen führen. Ich kann nur phpmyadmin verwenden.
Nur ​​in mysql3.23 verfügt phpmyadmin über einen zusätzlichen Seitenzeichensatz von gb2312, was derzeit normal ist.
3. Importieren Sie die vorherige MySQL3-Bibliotheksdatei in die MySQL4.1-Bibliothek.
Es gibt zwei Situationen:
Zu diesem Zeitpunkt sollten Sie auf die untere linke Ecke achten Seite, auf der Sie die Bibliotheksdatei auswählen. Der Standardwert ist utf8, er muss in gb2312 geändert werden, sonst wird der Import verstümmelt.
Der zweite ist der Import unter Linux , zu diesem Zeitpunkt müssen Sie eine Zeile zum Kopf der Bibliotheksdatei hinzufügen:
SET NAMES 'gb2312'; Beachten Sie, dass am Ende auch ein ; fehlt.
Führen Sie dann mysql -u Benutzername -p Passwort xxx.sql > Bibliotheksname aus.
Nachdem der Import abgeschlossen ist, öffnen Sie ihn mit phpmyadmin und prüfen Sie, ob die darin enthaltenen chinesischen Zeichen korrekt sind.
4. Exportieren Sie die Bibliotheksdatei aus mysql4.1
Der Export ist kein großes Problem. Wenn die auf der Browserseite von phpmyadmin angezeigte Datei normal ist, muss dies auch der Fall sein normal
2. Unter Linux exportieren
Es spielt keine Rolle, ob beim Exportieren mit mysqldump verstümmelte Zeichen angezeigt werden. Sie können iconv ausführen, um den Namen der GB2312-Bibliotheksdatei zu konvertieren > Neu gb2312 Der Name der Bibliotheksdatei
Zusammenfassend sollten Sie Folgendes beachten:
1. Versuchen Sie, SET NAMES 'gb2312' am Anfang der zu importierenden Bibliotheksdatei hinzuzufügen. Teilen Sie MySQL mit, dass Sie eine gb2312-Datei importieren möchten. Möglicherweise benötigen Sie Folgendes:
SET NAMES 'utf8'; Verwenden Sie es nach der Anmeldung bei MySQL. Ändern Sie einige Standardparameter des Zeichens in utf8.
Verwenden Sie auf MySQL:
SHOW VARIABLES LIKE 'character_set_%';
3. Seien Sie nicht beunruhigt, wenn verstümmelte Zeichen angezeigt werden. Erstens sollten Sie darauf achten, die ursprüngliche Sicherung beizubehalten, und zweitens sollten Sie zum Konvertieren iconv verwenden.
Führen Sie vor dem normalen Gebrauch unbedingt Import- und Exporttests durch, um sicherzustellen, dass nichts schief geht.


Ich habe MYSQL auf 4.1.2 aktualisiert und phpmyadmin verwendet 2.6.2. Die chinesischen Felder in der Datentabelle, die chinesische Zeichen enthalten, sind alle verstümmelt, und die exportierten Daten sind ebenfalls verstümmelt. Ich habe die vorherige Version 2.5.7 problemlos verwendet. Ich möchte fragen, welche Einstellung in der phpmyadmin-Datei geändert werden sollte, damit normale chinesische Zeichen angezeigt werden können.
Diese zeichenbezogenen Variablen stehen in engem Zusammenhang mit SQL:
character_set_client
character_set_connection
character_set_results
Außerdem handelt es sich um den Zeichensatz, der für das entsprechende Feld in der Datenbank festgelegt ist Nicht festgelegt: Der Standardwert ist der Zeichensatz der Tabelle. Wenn die Tabelle nicht angegeben ist, ist der Standardwert die Datenbank.
Die Funktion der oben genannten drei Variablen ist wie folgt: „client“ stellt den vom Client gesendeten Zeichensatz dar, und „results“ stellt den an den Client gesendeten Zeichensatz dar (diese beiden sind getrennt, da der hier gesendete und der an den gesendete Zeichensatz). Vergangenheit sind nicht unbedingt dasselbe Client-Terminal), dient als Verbindung zwischen dem Client und der Datenbank.
Die Einzelheiten sind wie folgt: In der MySQL-Befehlszeile stelle ich beispielsweise den Client auf gbk, die Verbindung auf utf8, die Ergebnisse auf gbk und die Datenbank auf big5 ein.
Wenn ich eine Einfügeanweisung sende Diese Anweisung wird als GBK-Code verwendet und zuerst in UTF8-Code (Verbindung) konvertiert, dann in Big5 (Datenbank) konvertiert und in die Datenbank eingefügt.
Wenn Sie eine SELECT-Anweisung ausführen, durchläuft das aus der Datenbank erhaltene Ergebnis den umgekehrten Prozess, von big5 zu utf8 und dann zu gbk, und Sie erhalten das Ergebnis von gbk.
Das Wichtigste ist also, dass der Client und die Ergebnisse mit dem von Ihnen verwendeten Client übereinstimmen. Wenn Ihre Webseite beispielsweise in utf8 codiert ist, müssen Sie diese beiden auf utf8 setzen.
Wenn ich die MySQL-Befehlszeile verwende, verwende ich 2000, das auf gbk gesetzt werden muss
Der von uns verwendete Setname XXX setzt diese drei Variablen tatsächlich gleichzeitig auf XXX.
In diesem Fall können wir verschiedene Tabellen oder Felder in einer Datenbank auf unterschiedliche Zeichensätze einstellen. Solange die oben genannten drei Einstellungen korrekt sind, können wir gleichzeitig unterschiedliche Zeichensätze in der Datenbank verwenden.
Stellen Sie sicher, dass die Zeichen in Ihrer Datenbank den richtigen Zeichensatz verwendet haben. Wenn Sie ihn beispielsweise zu Beginn falsch eingestellt haben, ist nach dem Einfügen der Daten die Kodierung der Daten selbst falsch, und selbst wenn Werden die Einstellungen wieder geändert, ist die korrekte Anzeige nicht möglich.
Eine andere Sache ist die Kompatibilität zwischen Codierungen. Wenn ein Zeichen in gbk, aber nicht in utf8 existiert, wird es im Prozess von gbk-》utf8-》gbk zu „?“
Zunächst müssen Sie Ihre aktualisierte Datenbank und den Zeichensatz von Tabelle und Feld angeben. Im Allgemeinen verwenden wir gb2312 oder utf8. Wenn Sie nicht mehrere Kodierungen gleichzeitig verwenden, müssen Sie nur angeben Sie können beim Erstellen der Datenbank auch die SQL-Anweisung und den entsprechenden Zeichensatz verwenden.
Dann importieren Sie die alten Daten. Bestimmen Sie zunächst die Kodierung Ihrer Datendatei. Wenn Sie zum Importieren phpMyAdmin verwenden, gibt es auf der Schnittstelle eine Dateikodierungsoption, die mit der Kodierung der Datendatei übereinstimmen muss.
Wenn Sie über die MySQL-Befehlszeile importieren, müssen Sie die drei oben genannten Variablen selbst festlegen und die Namen xxx festlegen.
Seien Sie vorsichtig, wenn Sie andere Client-Programme verwenden.
Auf diese Weise ist die Kodierung der alten Daten nach der Übertragung in die neue Datenbank korrekt. Wenn dieser Schritt falsch ist, ist es später unmöglich, die korrekte Anzeige zu erhalten.
Dann handelt es sich um Ihr eigenes Programm. Nach der Verbindung können Sie je nach Kodierung Ihrer Webseite einmalig set name xxx ausführen.
Dadurch wird grundsätzlich sichergestellt, dass die Kodierung korrekt ist.
Es ist sehr wahrscheinlich, dass die Kodierung der von Ihnen importierten Daten falsch ist.

Die Standardsprache der MYSQL-Datenbank ist Schwedisch und es gibt eine Datenbank mit GB2312-Zeichen.
Die Struktur ist in Ordnung. Gibt es eine Möglichkeit, den Code zu lösen, ohne ihn neu zu installieren? Datenbank?
Eingeführt ab MySQL 4.1. Die Mehrsprachenunterstützung ist wirklich großartig und einige Funktionen übertreffen andere Datenbanksysteme. Während des Tests habe ich jedoch festgestellt, dass die Verwendung von PHP-Anweisungen, die für MySQL vor 4.1 geeignet sind, zum Betreiben der MySQL-Datenbank zu verstümmelten Zeichen führt, selbst wenn der Tabellenzeichensatz festgelegt ist. Nachdem ich Kapitel 10 „Zeichensatzunterstützung“ im neuen MySQL-Online-Handbuch gelesen hatte, fand ich endlich die Lösung und bestand den Test.
Die Zeichensatzunterstützung (Character Set Support) von MySQL 4.1 umfasst zwei Aspekte: Zeichensatz (Zeichensatz) und Sortiermethode (Sortierung). Die Unterstützung für Zeichensätze wurde auf vier Ebenen verfeinert: Server, Datenbank, Tabelle und Verbindung.
Um den Zeichensatz und die Sortiereinstellungen des Systems anzuzeigen, können Sie die folgenden zwei Befehle verwenden:

mysql> ---+--------------+
|. Variablenname |.
+------------ -------------+
|. latin1 | >|. latin1 |. Character_set_system |+------------+--------------------- ----- ------+
7 Zeilen im Satz (0,00 Sek.)
mysql> SHOW VARIABLES LIKE 'collation_%'; --- -------+----------+
|. Variablenname |. -------+
|. latin1_swedish_ci | latin1_swedish_ci |.
+-------------------------- +
3 Zeilen im Satz (0,00 Sek.)

Die oben aufgeführten Werte sind die Systemstandardwerte. (Es ist seltsam, warum das System standardmäßig die schwedische Sortiermethode latin1 verwendet) ...
Wenn wir auf die ursprüngliche Weise über PHP auf die MySQL-Datenbank zugreifen, auch wenn der Standardzeichensatz der Tabelle auf utf8 eingestellt und durch codiert ist UTF-8 Senden Sie eine Abfrage und Sie werden feststellen, dass die in der Datenbank gespeicherten Daten immer noch verstümmelt sind. Das Problem liegt in dieser Verbindungsschicht. Die Lösung besteht darin, den folgenden Satz auszuführen, bevor die Abfrage gesendet wird:
SET NAMES 'utf8'
Es entspricht den folgenden drei Anweisungen:
SET Character_set_client = utf8;
SET Character_set_results = utf8;
SET Character_set_connection = utf8;
Versuchen Sie es noch einmal, ist es normal? ^_^ Viel Spaß!
Insbesondere
Fügen Sie vor Ihrer Abfrage eine Zeile hinzu:
mysql_query("SET NAMES 'gb2312';",$this->con);
Sie sollten wirklich das Handbuch einfügen Schauen Sie es sich genau an.
Diese zeichenbezogenen Variablen stehen in engem Zusammenhang mit SQL:
character_set_client
character_set_connection
character_set_results
Außerdem handelt es sich um den Zeichensatz für das entsprechende Feld in der Datenbank . Wenn keine Feldeinstellung vorhanden ist, ist der Standardwert der Zeichensatz der Tabelle. Wenn die Tabelle nicht angegeben ist, ist der Standardwert die Datenbank.
Die Funktion der oben genannten drei Variablen ist wie folgt: „client“ stellt den vom Client gesendeten Zeichensatz dar, und „results“ stellt den an den Client gesendeten Zeichensatz dar (diese beiden sind getrennt, da der hier gesendete und der an den gesendete Zeichensatz). Vergangenheit sind nicht unbedingt dasselbe Client-Terminal), dient als Verbindung zwischen dem Client und der Datenbank.
Die Einzelheiten sind wie folgt: In der MySQL-Befehlszeile stelle ich beispielsweise den Client auf gbk, die Verbindung auf utf8, die Ergebnisse auf gbk und die Datenbank auf big5 ein.
Wenn ich eine Einfügeanweisung sende Diese Anweisung wird als GBK-Code verwendet und zuerst in UTF8-Code (Verbindung) konvertiert, dann in Big5 (Datenbank) konvertiert und in die Datenbank eingefügt.
Wenn Sie eine SELECT-Anweisung ausführen, durchläuft das aus der Datenbank erhaltene Ergebnis den umgekehrten Prozess, von big5 zu utf8 und dann zu gbk, und Sie erhalten das Ergebnis von gbk.
Das Wichtigste ist also, dass der Client und die Ergebnisse mit dem von Ihnen verwendeten Client übereinstimmen. Wenn Ihre Webseite beispielsweise in utf8 codiert ist, müssen Sie diese beiden auf utf8 setzen.
Wenn ich die MySQL-Befehlszeile verwende, verwende ich 2000, das auf gbk gesetzt werden muss
Der von uns verwendete Setname XXX setzt diese drei Variablen tatsächlich gleichzeitig auf XXX.
In diesem Fall können wir verschiedene Tabellen oder Felder in einer Datenbank auf unterschiedliche Zeichensätze einstellen. Solange die oben genannten drei Einstellungen korrekt sind, können wir gleichzeitig unterschiedliche Zeichensätze in der Datenbank verwenden.
Stellen Sie sicher, dass die Zeichen in Ihrer Datenbank den richtigen Zeichensatz verwendet haben. Wenn Sie ihn beispielsweise zu Beginn falsch eingestellt haben, ist nach dem Einfügen der Daten die Kodierung der Daten selbst falsch, und selbst wenn Werden die Einstellungen wieder geändert, ist die korrekte Anzeige nicht möglich.
Eine andere Sache ist die Kompatibilität zwischen Codierungen. Wenn ein Zeichen in gbk, aber nicht in utf8 existiert, wird es im Prozess von gbk-》utf8-》gbk zu „?“
Zunächst müssen Sie Ihre aktualisierte Datenbank und den Zeichensatz von Tabelle und Feld angeben. Im Allgemeinen verwenden wir gb2312 oder utf8. Wenn Sie nicht mehrere Kodierungen gleichzeitig verwenden, müssen Sie nur angeben Sie können beim Erstellen der Datenbank auch die SQL-Anweisung und den entsprechenden Zeichensatz verwenden.
Dann importieren Sie die alten Daten. Bestimmen Sie zunächst die Kodierung Ihrer Datendatei. Wenn Sie zum Importieren phpMyAdmin verwenden, gibt es auf der Schnittstelle eine Dateikodierungsoption, die mit der Kodierung der Datendatei übereinstimmen muss.
Wenn Sie über die MySQL-Befehlszeile importieren, müssen Sie die drei oben genannten Variablen selbst festlegen und die Namen xxx festlegen.
Seien Sie vorsichtig, wenn Sie andere Client-Programme verwenden.
Auf diese Weise ist die Kodierung der alten Daten nach der Übertragung in die neue Datenbank korrekt. Wenn dieser Schritt falsch ist, ist es später unmöglich, die korrekte Anzeige zu erhalten.
Dann handelt es sich um Ihr eigenes Programm. Nach der Verbindung können Sie je nach Kodierung Ihrer Webseite einmalig set name xxx ausführen.
----------------------------------------
MySQL-Import verstümmelter Code Problem - -
Wenn MySQL mysqldump verwendet, um Daten aus 4.1 zu exportieren und in 4.0 zu importieren, tritt ein SQL-Anweisungsfehler auf und alle Daten werden verstümmelt. Verwenden Sie die folgenden Parameter, um das Problem zu lösen
mysqldump -uxunai -p --kompatible=mysql40 --default-character-set=latin1 xunai>xunai.sql
mysql -uroot -p fmx < fmx3.sql - f --default-character-set=latin1

Das Obige ist eine Sammlung von Lösungen für verstümmelte chinesische MySQL-Zeichen. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!