Sprachvariablen werden nicht alle erkannt

WebsiteBaker Support (2.10.x) > Hilfe & Support (deutsch)

<< < (4/4)

DarkViper:
Ich denke, ich sollte ein klein wenig über Zeichensatzcodierun g schreiben, vielleicht hilft es dabei die hier auftretenden Probleme leichter zu verstehen.

Wir haben für WB selbst ab der neuen Version den PHP-Code mehr oder weniger zwangsweise auf UTF-8 umgestellt.
Damit sind wir jedoch nur der dringenden Empfehlung der PHP-Group gefolgt, die mit PHP-7 UTF8 als default-Zeichensatz festgelegt hat.
Auch die mySQL - Datenbank läuft bei uns jetzt primär auf UTF-8mb4 (was bei mySQL demnächst Standard wird).

Da es bis dato bei WebsiteBaker noch keinerlei Vorgaben oder Regeln in Bezug auf Zeichensätze und Datenbankanbindung gab, jeder die Einstellungen nach persönlichem Gusto wählen und ändern konnte, bzw. vom Provider in unterschiedlichster Konfiguration geliefert bekam, war es vorhersehbar, dass es bei diesen Umstellungen Zeichensatzprobleme der unterschiedlichsten Art geben würde. Eine allgemeingültige Anleitung war da kaum zu erstellen. Zumal auch Anleitungen leider meistens erst dann gelesen werden, wenn die ersten, eigenen Versuche "in die Hose gingen" und die Daten endgültig verwurstelt sind. :-(
Diese Umstellungen, mitsamt ihren Problemen, wären jedoch auf jeden Fall erforderlich gewesen. Wenn nicht jetzt, dann spätestens in der nächsten Version. Das ganze Zeichensatzproblem wäre nur zeitlich etwas verschoben worden.

Noch ein paar Informationen zu Zeichensätzen, die vorwiegend Programmierer interessieren dürften:

Der offizielle UTF-8 Standard, der auch in PHP gilt, deklariert UTF-8 als Multibyte Zeichensatz, der 1-4 Bytes umfassen kann. Also für PHP alles im grünen Bereich.
Das Problem liegt bei mySQL. Als hier damals UTF-8 eingeführt wurde, hat man den maximalen Umfang auf die max. 3 Bytes der Basic Multilingual Plane (BMP) beschränkt. Quasi ein UTF-8(mb3). Mit Aufkommen der neuen Zeichen (z.B. Emojis etc), die das 4.Byte benötigen, war mySQL gezwungen, sich anzupassen. Es wurde jedoch nicht das bisherige UTF8 auf die genormten 1-4 Byte erweitert, sondern ein zusätzlicher Zeichensatz UTF8_MB4 eingeführt, der grundsätzlich 4 Byte lang ist. Der Codierungsalgorithm us von UTF8 und UTF8MB4 ist absolut identisch.
Da PHP von Haus aus ja 4-Byte UTF8 unterstützt, kann es sowohl utf8 als auch utf8mb4 von der Datenbank lesen und verarbeiten.
Umgekehrt ist das schon kritischer: Wird ein 4-Byte UTF8 Zeichen an mySQL gesendet und dieses ist auf 'normal' utf8(mb3) eingestellt, geht das 4.Byte verloren. Läuft die mySQL mit utf8mb4, so ist alles völlig in Ordnung.
Soll eine neue Tabelle angelegt werden, so muss der höhere Speicherbedarf für UTF8MB4 berücksichtigt werden (4 Byte je Zeichen anstatt durchschnittlich 2-3 Byte je Zeichen bei UTF8). Das muss auch beim Anlegen von Indizes auf Textfelder berücksichtigt werden.

Codierungsbeispiele:
UTF-8-Codetabelle
ZÄHTML-EntitieZÄ𝌆ASCII[0x5A] 01011010 --- --- --- --- Latin1[0x5A] 01011010[0xC4] 11000100 --- --- Unicode
(Code position)[0x5A]
U+005A 01011010[0xC4]
U+00C4 11000100[0x01 0xD3 0x06]
U+1D30600000001 11010011
00000110UTF8(PHP)[0xC3 0x9A] 11000001 10011010[0xC3 0x84] 11000011 10000100[0xF0 0x9D 0x8C 0x86]11110000 10011101
10001100 10000110UTF8(mySQL)[0xC3 0x9A] 11000001 10011010[0xC3 0x84] 11000011 10000100[0xF0 0x9D 0x8C]11110000 10011101
10001100 (Fehler)UTF8MB4[0xC3 0x9A] 11000001 10011010[0xC3 0x84] 11000011 100001000xF0 0x9D 0x8C 0x8611110000 10011101
10001100 10000110Man sieht hier auch deutlich den Speicherverbrauch der einzelnen Codierungsarten. Ungeachtet dessen sind jedoch die neuesten Versionen von mySQL bereits soweit optimiert, dass manche Aktionen mit UTF8MB4 schon schneller ablaufen als mit UTF-8.

Manuela

Navigation

[0] Message Index

[*] Previous page

Go to full version