Gunnar Bittersmann: Warum man nicht 'uft8' in MySQL verwenden sollte

@@alle:

nuqneH

… sondern 'utf8mb4':

How to support full Unicode in MySQL databases (Mathias Bynens)

Qapla'

--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)
  1. Tach!

    … sondern 'utf8mb4':
    How to support full Unicode in MySQL databases (Mathias Bynens)

    Nunja, wer's braucht.

    Was will er eigentlich in Schritt 5? Erst redet er davon, alle SET-NAMES-Statements in den Client-Codes anzupassen und dann definiert er

    [mysqld]
    character-set-client-handshake=FALSE
    init-connect='SET NAMES utf8mb4'

    Nach meinem Verständnis dürften dann die Clients gar keine Zeichenkodierung mehr aushandeln können. Allerdings konnte ich bei mir keine Auswirkungen der ersten Zeile erkennen, auch nicht in anderen Schreibweisen. Und das init-connect muss er auch nicht explizit aufführen, das ist durch character-set-server bereits auf diesen Wert voreingestellt. Die Zeichenkodierung im init-connect zu setzen ist nur notwendig, wenn der Server-Default-Wert ein anderer ist als die Clients voreingestellt bekommen sollen. Beispielsweise kann ein Szenario dafür sein, dass man gern UTF-8 als Default haben will, aber unveränderliche Clients hat, die von Latin1 ausgehen und auch keine Anstalten einer individuellen Aushandlung machen.

    dedlfix.

  2. hi,

    How to support full Unicode in MySQL databases (Mathias Bynens)

    Den seine Fehlermeldung "Incorrect string value: '\xF0\x9D\x8C\x86' for column 'column_name' at row 1 "

    deutet darauf hin, dass er versucht, Latin1 einzufügen. Siehe auch

    Diskussion

    Hotti

    1. Tach!

      How to support full Unicode in MySQL databases (Mathias Bynens)
      Den seine Fehlermeldung "Incorrect string value: '\xF0\x9D\x8C\x86' for column 'column_name' at row 1 "
      deutet darauf hin, dass er versucht, Latin1 einzufügen.

      Nein, aber deine Aussage deutet darauf hin, dass du mal wieder keine Ahnung hast.

      F0        9D        8C        86
      1111 0000 1001 1101 1000 1100 1000 0110

      Gemäß den Kodierungsregeln für UTF-8 sieht man, dass es sich um eine gültige 4 Byte lange UTF-8-Sequenz handelt. Als Nutz-Bits bleiben übrig

      000 011101 001100 000110

      was in Hex umgerechnet 01D306 ergibt, genau der Codepoint für das Zeichen, das er einzufügen versucht hat. Die Fehlermeldung ist die gleiche wie bei Latin1-kodierten Zeichen, weil sowohl Latin1 > 0x7F als auch UTF-8 jenseits der BMP ungültig für MySQLs "Character Set" namens utf8 sind.

      dedlfix.

    2. @@hotti:

      nuqneH

      Den seine Fehlermeldung "Incorrect string value: '\xF0\x9D\x8C\x86' for column 'column_name' at row 1 "
      deutet darauf hin, dass er versucht, Latin1 einzufügen.

      Nein.

      Hast du die Erklärung nicht gelesen oder nicht verstanden?

      Qapla'

      --
      Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)
    3. hi again,

      How to support full Unicode in MySQL databases (Mathias Bynens)

      Den seine Fehlermeldung "Incorrect string value: '\xF0\x9D\x8C\x86' for column 'column_name' at row 1 "

      Die Bytefolge F0 9D in utf8 ist der REPLACEMENT CHARACTER, das erklärt den im Artikel beschriebenen Effekt "The content got truncated..."

      Vermutlich liegt das Problem bereits am Client, der UTF-8-kodierte Strings nicht richtig taggen kann oder MySQL kann das nicht in diesem Fall oder es gibt ein generelles Problem mit dem Tagging oder mit der Unicode Canonicalization.

      Euch als Experten übergebe ich feierlich die Aufgabe, das rauszukriegen ;)

      Schönen Tach!

      1. @@hotti:

        nuqneH

        Die Bytefolge F0 9D in utf8 ist der REPLACEMENT CHARACTER

        Nein.*

        Die Bytefolge F0 9D¹ zeigt an, dass die nächsten 2 Bytes auch noch mit zu dem codierten Zeichen² gehören. Und wenn es keine 2 folgenden Bytes gibt (oder deren jeweils ersten zwei Bits nicht 10 sind), ist die Bytefolge F0 9D kein UTF-8.

        Der REPLACEMENT CHARACTER (Codepoint U+FFFD) ist übrigens in UTF-8 die Bytefolge EF BF BD.

        Qapla'

        * Das wird wohl zur Standardantwort auf all deine Postings zum Thema Zeichencodierung.

        ¹ genauer gesagt: die ersten 5 Bits des ersten Bytes 11110 und die ersten 2 Bits 10 des zweiten Bytes [Wikipedia]

        ² welches einen Codepoint ≥ U+10000 hat

        --
        Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)
        1. Hi!

          Die Bytefolge F0 9D in utf8 ist der REPLACEMENT CHARACTER

          Nein.*

          * Das wird wohl zur Standardantwort auf all deine Postings zum Thema Zeichencodierung.

          Ebenso scheint es zum Standard zu werden, dass seine eigene Seite hotti widerlegt - die zeigt nämlich die richtige Bytefolge an: http://rolfrost.de/unicode.html?charname="replacement+character"&findname=Suche+nach+Codepoint+oder+Name

          Viele Grüße,
          Alex

      2. @@hotti:

        nuqneH

        Die Bytefolge F0 9D in utf8 ist der REPLACEMENT CHARACTER

        Nein. Meintest du vielleicht „surrogate code point“?

        Qapla'

        --
        Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)
  3. Hallo Gunnar,

    'uft8' sollte man wirklich nicht verwenden, da stimme ich Dir zu :-)

    Freundliche Grüße

    Vinzenz