Login
Newsletter
Werbung

Thema: MySQL 8.0 freigegeben

2 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von JonSnow am Sa, 21. April 2018 um 14:46 #

Du hast dir die Frage eigentlich eh selbst beantwortet. Neue Code Units führen zu neuen Code Points. Die Datenbank muss diese kennen, wenn du String-Funktionen anwenden möchtest.
Natürlich könntest du auch alles RAW speichern, hast dann aber entsprechende Einschränkungen bei der Abfrage.

MySQL ist aber generell ein Murks .. da ist utf8 ja auch kein utf8 sondern ein nicht standardkonformes 3-Byte Encoding.

[
| Versenden | Drucken ]
  • 0
    Von UChef am So, 22. April 2018 um 15:30 #

    Du hast dir die Frage eigentlich eh selbst beantwortet. Neue Code Units führen zu neuen Code Points. Die Datenbank muss diese kennen, wenn du String-Funktionen anwenden möchtest.
    Ok, das stimmt. Wobei der Großteil an neuen Zeichen ja eigenständige Glyphen sind - zumindest wäre das mein Gefühl. Ergo kann die DB ja im Zweifel an den Stellen trennen, an denen sie eine Grenze zwischen Code-Points erkennt.

    Ist denn klar, wie die String-Operationen einer DB (bzw. hier speziell MySQL) arbeiten? Worauf operieren denn Split(), Right() usw.? Auf Code Points, Grapheme Clustern? Wie wird die Größe von String-Feldern festgelegt? Bezieht sich ein VARCHAR(10) auf 10 Code Points, arbeitet also Unicode basiert? Wenn ja, wäre es letztlich auch wieder egal, ob ich die Semantik hinter einem Code Point kenne oder nicht - wenn ich die ersten zwei Einheiten eines solchen Feldes haben möchte, dann sind das eben zwei Code Points. Anders sähe es mit anderen Einheiten aus; aber die wären mutmaßlich noch weniger gut zu verarbeiten ...

    MySQL ist aber generell ein Murks .. da ist utf8 ja auch kein utf8 sondern ein nicht standardkonformes 3-Byte Encoding.
    Ja, hab ich oben im ersten Kommetar ja auch schon angedeutet :x

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung