Warum konvertiert meine database in UTF-8 trunkierende Einträge?

Ich benutze WordPress 4.1.1. Meine Website ist bei NearlyFreeSpeech gehostet.

Ich benutze meinen WordPress-Blog seit den Tagen, als es Informationen im latin1 Zeichensatz kodierte. Diese Woche habe ich festgestellt, dass bestimmte Beiträge in meinem Blog (wie diese: 1 – 2 – 3 ) keine japanischen Schriftzeichen anzeigen – die Schriftzeichen erscheinen entweder als Fragezeichen oder als Zeichenfolgen wie æ- ¥ 本èèž .

Dies ist eindeutig ein Codierungserrors. Wenn ich meine database in phpMyAdmin betrachte, habe ich viele Tabellen und Spalten in meiner database, deren Sortierung auf latin1_swedish_ci . Ich versuchte, dies zu beheben, indem ich die database auf verschiedene Arten in UTF-8 änderte. Sie alle hatten genau das gleiche Ergebnis.

Die Möglichkeiten, die databasecodierung in UTF-8 zu ändern:

  1. Verwenden Sie das UTF-8 Database Converter- Plugin
  2. Befolgen Sie diese Anleitung , um die database zu exportieren, ersetzen Sie alle Instanzen von “latin1” durch “UTF8”
  3. Verwenden Sie ein SQL-Skript, um Tabellen und Spalten in Blob und dann in UTF-8-Text zu konvertieren ( hier detailliert)
  4. Verwenden Sie ein SQL-Skript, um Tabellen und Spalten zu dem darin enthaltenen Datentyp zu konvertieren, dann zu Blob und dann zu UTF-8-Text ( hier detailliert)

Erwartete Ergebnisse:

Meine Website erscheint genauso wie oben, alle Designs und Einstellungen sind intakt, aber japanische Schriftzeichen werden jetzt korrekt angezeigt.

Tatsächliche Ergebnisse für alle oben genannten Methoden:

Japanisch wird immer noch nicht korrekt angezeigt. databaseeinträge enden abrupt; Zum Beispiel fehlt einigen Einträgen in post_content Teil oder der Großteil ihres ursprünglichen Inhalts. Benutzerdefinierte Shortcodes, die vom Shortcoder-Plug-in definiert und in der Zeile ‘ wp_options in ‘ wp_options , sind wp_options , weil der Eintrag ‘ wp_options abrupt abgeschnitten wurde. Meine Themenoptionen, einschließlich benutzerdefinierter CSS und fonts, wurden anscheinend zurückgesetzt oder beschädigt, höchstwahrscheinlich aufgrund ähnlicher abrupter Kürzungen von databaseeinträgen.

Glücklicherweise hatte ich die Voraussicht, alle diese Änderungen an einer doppelten database vorzunehmen, also habe ich eine Sicherungskopie mit allen meinen intakten Daten.

Wenn ich die geänderten Daten in post_content mit dem Original vergleiche, fällt mir etwas auf: Fast alle abgeschnittenen Strings beginnen mit einem Sonderzeichen. Zum Beispiel, ein Beitrag, der einmal gelesen hat:

Heute war es angenehme 72 ° und sonnig.

werde in der geänderten database lesen:

Heute war es eine angenehme 72

Ich bin nicht durchgegangen und habe alle meine abgeschnittenen Beiträge gefunden – ich weiß nichts über mySQL, also müsste ich das mit der Hand machen, und das wäre eine Übung in Geduld. Von einer Stichprobe von 8 Posts, die abgeschnitten wurden, wurden jedoch 6 von ihnen eindeutig mit einem speziellen Zeichen abgeschnitten.

Was muss ich tun, um meine database korrekt zu konvertieren, sodass japanische Zeichen korrekt angezeigt werden, ohne dass dies zu Datenverlust führt – oder, wenn keine vollständige Lösung vorhanden ist, was kann ich tun, um die Vorgänge richtig zu diagnostizieren?

Vielen Dank.

Update: Zusätzliche Informationen

Ein paar mehr Dinge.

Ich hatte viele Posts in meinem Blog, auf denen Strings wie ich statt wie ich , naiv statt naiv , angezeigt wurden . Wie ich oben erwähnt habe, zeigte Japanisch so lange Strings wie æ- ¥ æœèèž statt 日本語. Ich ging durch und ersetzte diese Saiten, wo ich sie sah und ¯ durch ein richtiges replacing (zum Beispiel) ersetzte.

Ich habe jedoch nicht alle von ihnen erfasst, und es gibt ein paar Posts in meiner database, die immer noch naiv statt naiv sind .

Wenn ich mir die Einträge in den databaseen anschaue, die ich geändert habe, werden sie korrekt angezeigt. Sie werden nicht abgeschnitten. Alle verstümmelten Charaktere haben sich nahtlos in ihre “richtigen” Entsprechungen übersetzt. Sogar die Japaner konvertierten.

In den Posts, in denen ich zurückging und die verstümmelten Charaktere “korrigierte”, wo ich jedoch naiv und nicht naiv bin , wird der Inhalt in der database beim Import abgeschnitten, wie oben beschrieben.

Solutions Collecting From Web of "Warum konvertiert meine database in UTF-8 trunkierende Einträge?"

Das Problem war eine gemischte Codierung. Einige Felder enthielten Daten, die ordnungsgemäß als UTF-8 codiert waren. andere enthielten Daten, die als etwas anderes kodiert waren, wahrscheinlich ISO-8859-1. Beim Import in eine neue UTF-8-database führte dies zu einer Kürzung.

Meine Schritte, um das zu lösen:

  1. Kopieren Sie die ursprüngliche database, wordpress , in eine neue database, wordpress2 . Stellen Sie sicher, dass die Sortierung von wordpress2 auf UTF-8 eingestellt ist.
  2. Befolgen Sie einen der obigen Schritte, um die Tabellen und Spalten von wordpress2 in UTF-8 zu konvertieren. Dies wird Abschneiden verursachen.
  3. Für jede Zeile in wordpress die Einträge enthält, bei denen die Daten bei der Konvertierung in UTF-8 nicht mit den Daten in ASCII konvertierten, aktualisieren Sie die entsprechende Zeile in wordpress2 mit den wordpress Daten, die in UTF-8 konvertiert wurden. Ein Beispielskript ist unten.

Das Skript:

 UPDATE wordpress3.wp_options wp3 INNER JOIN wordpress.wp_options wp ON (wp.option_id = wp3.option_id AND convert(wp.option_value using utf8) != convert(wp.option_value using ascii)) SET wp3.option_value = convert(wp.option_value using utf8); 

Ein kenntnisreicherer Freund schrieb eine Reihe von Skripten für mich, die information_schema absuchten, um alle Spalten mit Einträgen zu finden, in denen convert(value using utf8) != convert(value using ascii) und dann Versionen des obigen Skripts für sie generieren.

Ergebnisse:

Es funktionierte! In meiner neuen database kann ich Japanisch speichern, ohne dass es zu Fragezeichen wird (weil der Zeichensatz erfolgreich auf UTF-8 gesetzt wurde), und alle falsch kodierten Felder, die die Daten abgeschnitten haben, wurden behoben.

Es gibt einige Posts, die falsch codierte Zeichen enthalten, aber da ich fast alle dieser Strings finden kann, indem ich nach â, Â, Â oder æ suche, kann ich einfach reingehen und sie manuell ersetzen.