it-swarm.com.de

Sollte Latin-1 bei der Datenbankkonfiguration über UTF-8 verwendet werden?

Wir verwenden MySQL in der Firma, für die ich arbeite, und erstellen sowohl clientseitige als auch interne Anwendungen mit Ruby on Rails).

Als ich hier anfing zu arbeiten, stieß ich auf ein Problem, auf das ich noch nie zuvor gestoßen war. Die Datenbank auf dem Produktionsserver ist auf Latin-1 eingestellt. Dies bedeutet, dass das MySQL-Gem eine Ausnahme auslöst, wenn Benutzereingaben vorliegen, bei denen der Benutzer UTF-8-Zeichen kopiert und einfügt.

Mein Chef nennt diese "schlechten Zeichen", da die meisten von ihnen nicht druckbare Zeichen sind, und sagt, dass wir sie entfernen müssen. Ich habe ein paar Möglichkeiten gefunden, dies zu tun, aber irgendwann sind wir in einem Umstand gelandet, in dem ein UTF-8-Charakter benötigt wurde. Außerdem ist es ein bisschen mühsam, zumal die einzige Lösung, über die ich jemals für dieses Problem gelesen habe, darin besteht, die Datenbank einfach auf UTF-8 zu setzen (macht für mich Sinn).

Das einzige Argument, das ich für das Festhalten an Latin-1 gehört habe, ist, dass das Zulassen nicht druckbarer UTF-8-Zeichen die Text-/Volltextsuche in MySQL durcheinander bringen kann. Ist das wirklich wahr?

Gibt es andere Gründe, warum man Latin-1 anstelle von UTF-8 verwenden sollte? Ich verstehe, dass es überlegen ist und allgegenwärtiger wird.

66
Ravenstine

Unicode ist sicherlich schwierig, und die UTF-8-Codierung weist einige unbequeme Eigenschaften auf. UTF-8 ist jedoch die De-facto-Standardcodierung im Web und übertrifft ASCII, Latin-1, UCS-2 und UTF-16. Nur benutze UTF-8 überall .

Der wichtigste Grund, warum Sie Unicode unterstützen sollten, ist, dass Sie keine unnötigen Annahmen über Benutzereingaben treffen sollten. Ich habe keine Ahnung, was Ihre Domain ist, aber Dinge wie hebräische Benutzernamen, ein Blog-Beitrag über China, ein Kommentar mit Emoji oder einfach gut gestylter Text - wie „dies“ - sollten möglich sein… Oh, das waren typografisch korrekte Anführungszeichen ( “” eher, als ""), en-wide Striche und eine Ellipse, die Zeichen sind, die im englischen Text häufig vorkommen, aber nicht von ASCII oder Latin-1) unterstützt werden. Andere Skripte werden also nicht unterstützt Nur ein großer Fick für andere Kulturen, aber wenn Sie sich an Latin-1 halten, können Sie nicht einmal richtig Englisch schreiben.

Die Vorstellung, dass Unicode nur "schlechte Zeichen" zulässt, ist falsch. Ja, Text ist wirklich kompliziert und Unicode wird das nicht vor Ihnen verbergen. Ihr Chef denkt möglicherweise an zusammengesetzte Zeichen, bei denen ein Basiscodepunkt wie a durch nachfolgende Codepunkte geändert wird, die z. stellen Diakritika dar, um ein visuelles Zeichen wie á. Dies stört Sie nicht wirklich, wenn Sie versuchen, Suchvorgänge durchzuführen, wenn Sie eine Art Normalisierung durchführen. Sie können beispielsweise den gesamten Text im Formular NFC) speichern, wodurch solche Kompositionen in ihre vorkompositionierte Form reduziert werden, sofern eine verfügbar ist. Bei der Suche können Sie jedoch auch alle zusammensetzenden Zeichen aus dem Text entfernen Dies kann ihre Bedeutung in einigen Sprachen erheblich ändern.

Unicode fügt auch viele nicht druckbare Zeichen hinzu - aber selbst ASCII hat viele davon. Werden Sie eine NUL in der Mitte eines Strings behandeln? Wie wäre es mit 0x1C, einem "File Separator"? I ' Ich habe noch nie gesehen die Hälfte davon . Latin-1 fügt einen weichen Bindestrich hinzu, der auf Wortunterbrechungsmöglichkeiten hinweist, aber ansonsten unsichtbar ist. Unterbricht dies auch Ihre Volltextsuche? Mit anderen Worten, sogar ASCII und Latin-1 ermöglichen es Ihnen, Ihre Eingabe vollständig zu unterbrechen, wenn Sie davon ausgehen, dass alles nur druckbarer Text ist!

133
amon

Ich denke, über die technische Frage hinaus hat Ihr Chef möglicherweise nicht die Zeit, sich über die aktuellen Standards auf dem Laufenden zu halten.

Da seine Haltung nicht vollständig auf das Mittagessen ausgerichtet ist, sondern nur veraltet ist, respektieren Sie seine Position, wenn Sie diese Angelegenheit besprechen (und Sie müssen daran denken, diskutieren, nicht streiten), und versuchen, die Bedenken auszuräumen, die er hat in Bezug auf UTF-8. Ich vermute, dass das zugrunde liegende Problem kein technisches Problem ist und möglicherweise ein gewisses Maß an Soft-Skill-Verhandlungen erfordert.

62
Nelson

Wer von uns hat recht?

Es war einmal Ihr Chef. Aber mit der Zeit ändern sich die Dinge. Heutzutage sind Sie es (aber bevor Sie zu Ihrem Chef laufen , lesen Sie unbedingt auch Nelsons Antwort ).

Alte Versionen von MySQL und alte Versionen von meistens alles handelten viel besser mit dem älteren Latin1/ISO-8859-1 (5) als UTF8.

Es gibt einen Grund, warum UTF8 fast überall erstellt, weiterentwickelt und gepusht wurde: Wenn es richtig implementiert ist, funktioniert es viel besser. Es gibt einige Leistungs- und Speicherprobleme, die sich aus der Tatsache ergeben, dass ein Latin1-Zeichen 8 Bit lang ist, während ein UTF8-Zeichen 8 bis 32 Bit lang sein kann. Wenn Sie also VARCHAR planen, müssen Sie dies berücksichtigen. Und Ihre Suchroutinen werden etwas langsamer sein. Sie werden in der Lage sein, mehr Dinge zu tun (z. B. Suchen mit Akzentempfindlichkeit oder ohne . Diese können in Latein1 nicht ohne umfangreiche Arbeit ausgeführt werden), aber sie werden nehmen a etwas mehr Zeit.

Andererseits ist der Speicherplatz billig, der Overhead für Dateigrößen realistisch weniger als 2-3%, die Rechenleistung ist auch billig und wird immer billiger in guter Übereinstimmung mit Moores Gesetz; während Ihre Zeit und die Erwartungen Ihrer Kunden definitiv sind 't.

Möglicherweise müssen Sie sich um Suchwerkzeuge usw. kümmern, wenn Sie derjenige sind, der entwickelt solche Werkzeuge verwendet. Aber das bist du wahrscheinlich nicht. Sie verwenden diese Werkzeuge; Selbst diejenigen, die gestern nicht vollständig UTF8-kompatibel waren (wie die früheren MySQLs nicht), sind heute oder werden es bald sein (z. B. MySQL mit utf8mb4-Unterstützung).

Wenn Sie also UTF8 sorgfältig planen und implementieren ( und nicht , um es nachträglich über Latin1 zu schlagen), können Sie Code haben, der sehr vernünftig ist zukunftssicher, was, wenn Sie vorhaben, jemals mit einem asiatischen Land Geschäfte zu machen, eine sehr gute Sache ist. Und wenn Sie keine solchen Pläne haben, werden es andere Menschen haben, und diese Menschen könnten Ihre Kunden, Lieferanten oder Partner sein.

Wenn sie Ihnen also UTF8-Daten senden, müssen Sie ein kompliziertes Ding einrichten, um es in Latin1 zu konvertieren und unlösbare Fälle zu behandeln.

Wenn Sie das Budget berücksichtigen, sind die Kosten für mehrere Gefechte gegen die bösen Mojibake-Ninjas und Sie denken, dass sie werden nicht verschwinden - wie Sie bereits festgestellt haben - dann Sie werden feststellen, dass UTF8 nicht nur einfacher ist, sondern auch billiger.

49
LSerni

Einige Situationen, in denen die Beschränkung des Zeichensatzes nur auf ASCII) sinnvoll sein kann, gelten für Felder mit eingeschränkter Auswahl, z. B. Statusfelder, da Sie die dort vorhandenen Werte und Fremdschlüssel/Verweise auf externe streng kontrollieren System, weil es selten Gründe gibt, etwas anderes als alphanumerische Zeichen und einige Symbole zu haben.

Verwenden Sie für andere Texte einfach UTF-8.

4
Lie Ryan

Zunächst spielt es keine Rolle, wie Ihr Server konfiguriert ist. Die Zeichenkodierung in MySQL kann pro Spalte konfiguriert werden (dh, dieselbe Tabelle kann einfach Zeichen in mehreren Kodierungen enthalten). Das heißt, Mein Server (und eine Reihe von Legacy-Datenbanken darin) ist standardmäßig für cp1251 für alte Clients konfiguriert, die beim Verbinden keine korrekte Sortierung festlegen können (verschiedene Hardware-Clients), aber die Hauptdatenbanken in der Produktion verwenden alle UTF-8.

Apropos "verschwendeter Speicherplatz" - Sie können wichtige Daten nicht realistisch als Verschwendung bezeichnen, oder? Die Erhöhung des Speicherplatzes hängt jedoch von der Sprache ab, in der sich Ihre Daten befinden. Von einer unbedeutenden Erhöhung (weniger als 1%), wenn Ihre Website hauptsächlich auf Englisch ist, und bis zu 100%, wenn Ihre Website mit Zeichen außerhalb von ASCII Bereich. Und noch mehr, wenn Sie weiter nach Osten ziehen. Spätere UTF-8-Spezifikationen (sogenannte UTF8mb4) erlauben bis zu 4 Bytes pro Codepunkt.

Und zu "wer hat Recht" ... Die Wahrheit ist, dass dies mehr eine soziale als eine technische Frage ist. Es kann gültige Gründe für bestimmte Server-Setups geben, aber Sie müssen die Auswirkungen kennen. Aber wenn Sie mich fragen, gibt es keinen Grund, UTF-8 nicht zu verwenden. Es ist die einzige Art, alle Texte der Welt zu regieren.

3
AnrDaemon

Erklären Sie ihm einfach, dass UTF-8 die Standardeinstellung für den Webverkehr ist. Und jeder Benutzer kann ein beliebiges gültiges Unicode-Zeichen in seinen Browser eingeben.

Es ist einfach viel einfacher, utf-8/unicode vom vorderen bis zum hinteren Ende zu haben, als sich mit den vielen und verschiedenen Problemen zu befassen, die sich aus utf-8-> latin-1-> utf-8 ergeben.

0
James Anderson