Eine kurze Diskussion zum Thema MySQL-Backup-Zeichensatz

[Einleitung] 1 Einleitung Die Auswahl des Zeichensatzes beim Sichern von MySQL ist ein schwieriges Problem, insbesondere für Unternehmen mit variablen Zeichensätzen. Mysqldump verwendet standardmäßig utf8, und utf8 wird auch offiziell empfohlen. Tatsächlich verfügt jedoch für Chinesisch eine beträchtliche Anzahl von GBK-codierten Zeichen nicht über entsprechende Unicode-Codierungen, was bedeutet, dass dieser Teil des Zeichensatzes

1 Einführung

Auswählen des Zeichensatzes beim Sichern nach oben MySQL ist ein schwieriges Problem, insbesondere für Unternehmen mit variablen Zeichensätzen. Mysqldump verwendet standardmäßig utf8, und utf8 wird auch offiziell empfohlen. Tatsächlich verfügt jedoch für Chinesisch ein erheblicher Teil der GBK-codierten Zeichen nicht über die entsprechende Unicode-Codierung, was bedeutet, dass die Verwendung der UTF8-Sicherung für diesen Teil des Zeichensatzes zu Datenverlust führt. Gibt es also eine Lösung?

Der direkteste Weg besteht natürlich darin, die Zuordnung dieses Teils der Codierung hinzuzufügen. Die Anzahl dieses Teils des Zeichensatzes ist jedoch nicht gering, und noch ärgerlicher ist, dass es für diesen Teil des Zeichensatzes anscheinend keinen verbindlichen Zuordnungsstandard gibt. Gibt es also eine andere Möglichkeit?

Wenn Sie für die Sicherung Binärdateien verwenden, findet tatsächlich kein Zeichensatzkonvertierungsprozess statt und die oben genannten Probleme treten nicht auf. Löst die Verwendung von Binärdateien also alle Probleme von GBK? Die Antwort ist NEIN.

2 binäre Probleme

Bevor wir über binäre Probleme sprechen. Es gibt 2 Fragen, die geklärt werden müssen. Die MySQL-Sicherung ist in zwei Teile unterteilt: Schemainformationen und tatsächliche Daten. Schemainformationen werden mit Ausnahme des Standardwerts immer in utf8 codiert. Hier liegt das Problem.

2.1 utf8-Sicherung

(1) Die Datei .frm speichert die Schemainformationen der Tabelle und speichert den Standardwert jedes Felds über einen tatsächlichen Datensatz. Die dem Schema entsprechenden Informationen (einschließlich Kommentar) werden mit utf8 gespeichert, der Standardwert wird jedoch mit dem in der Tabelle angegebenen Zeichensatz gespeichert.

(2) Beim Ausführen der Anweisung „show create table“ konvertiert mysqld den Standardwert in frm von der in der Tabelle angegebenen Kodierung in die utf8-Kodierung.

(3) Wenn mysqld die Anweisung zum Erstellen einer Tabelle ausführt, wird der Standardwert von utf8 in den in der Tabelle angegebenen Zeichensatz konvertiert.

2.2 Binärsicherung

Wenn Binärdatei für die Sicherung angegeben ist. Beim Import vor dem Erstellen der Tabelle ist collation_connection immer noch binär, obwohl „character_set_client“ als utf8 angegeben ist. Daher wird die Konvertierung von utf8 in den in der Tabelle angegebenen Zeichensatz beim Speichern des Standardwerts nicht durchgeführt. Wenn die Tabelle als GBK-Kodierung angegeben ist, schlägt der Import unweigerlich fehl.

Beispiel:

CREATE TABLE `t1`(
`iNetbarId` int(11) NOT NULL DEFAULT '0',
`iUin` bigint(20) NOT NULL DEFAULT '0',
`vNetbarName` varchar(80) NOT NULL DEFAULT '“-”',
PRIMARY KEY (`iNetbarId`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;
 
insert into t1 values(1,1,'xxxx');

Wie Sie sehen können, wurde die Tabelle, die normalerweise exportiert wurde, mit einem Fehler von 1067 importiert. Ungültiger Standardwert.

3 Lösung

Wenn Sie mysqldump verwenden, fügen Sie die Einstellung von „character_set_connection“ hinzu, bevor Sie die Anweisung „create table“ ausführen.

/*!40101 SET Character_set_connection = utf8 */

Dies wird auch als MySQL-Fehler angesehen, da der Schemainformationen: Verwenden Sie utf8 von Anfang bis Ende, bevor Sie die Zeichensatzvariable der Verbindung auf utf8 setzen, anstatt nur die Zeichensatzvariable des Clients festzulegen.

Das Obige ist eine kurze Diskussion zum Thema MySQL-Backup-Zeichensatz. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn).