WB 2.6.5 und UTF-8

[thorn]

Hallo,

im Zusammenhang mit dem Thread "WebsiteBaker und Chinesisch" habe ich mir mal den Umgang von WB mit UTF-8 (oder jedem anderen Charset != latin-1) genauer angesehen.

Kann das sein, daß der Umgang mit Charsets ungleich latin-1 in WB generell falsch ist?
WB setzt beim Aufbau der Verbindung zur Datenbank keinen charset. Dadurch wird für die Verbindung immer der default-charset genommen (hier immer iso-8859-1).
D.h. wenn man in WB den DEFAULT_CHARSET z.b. auf UTF-8 stellt, werden Umlaute u.s.w. in der Datenbank generell falsch abgelegt (phpmyadmin zeigt nur Zeichenmüll an).

Was meiner Meinung nach fehlt ist die Festlegung des charsets für die Verbindung zwischen WB und Datenbank mittels
mysql_query("SET NAMES 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");
UTF-8 sollte hier natürlich durch den sich durch DEFAULT_CHARSET ergebenden Wert ersetzt werden.

Das ganze gehört, wie ich meine, in die class.database.php:

Code:

        // Connect to the database
        function connect() {
                $status = $this->db_handle = mysql_connect(DB_HOST, DB_USERNAME, DB_PASSWORD);
                if(mysql_error()) {
                        $this->connected = false;
                        $this->error = mysql_error();
                } else {
                        if(!mysql_select_db(DB_NAME)) {
                                $this->connected = false;
                                $this->error = mysql_error();
                        } else {
                                $this->connected = true;
                                mysql_query("SET NAMES 'utf8'");
                                mysql_query("SET CHARACTER SET 'utf8'");
                        }
                }
                return $this->connected;
        }

Wie gesagt, utf-8 muß natürlich angepaßt werden, je nach DEFAULT_CHARSET.
Zudem müßte, wenn der User den DEAULT_CHARSET in WB umstellt, die Verbindung entsprechend neu eingestellt werden.
Erst mit dieser Änderung enthält die Datenbank immer reines UTF-8, unabhängig vom DEFAULT_CHARSET.
Allerdings weiß ich nicht ob das bei mySQL4 genauso ist, ich habe hier nur mySQL5.

Das Ganze muß man nun im Zusammenhang mit dem Thread "WebsiteBaker und Chinesisch" sehen:
Mit dieser Änderung könnte man auf die Umwandlung in entities im menu_title und page_title verzichten, und könnte trotzdem im Titel und Menu Sonderzeichen haben (bisher hat da eben diese falsche "Verbindungs-Charset-Einstellung" einiges kaputt gemacht). Auch denkbar ist komplett auf UTF-8 umzusteigen, sprich keinen anderen Charset mehr anzubieten (eine Lösung die ich bevorzugen würde, weil sie endgültig alle Probleme mit Umlauten lösen würde! [bei Verwendung der Änderung an page_filename() aus dem o.g. Thread).

Es gibt allerdings ein großes Problem:
Die obige Änderung ist nicht kompatibel mit bestehenden Seiten die Umlaute im Content oder Menu/Title haben, dort wird dann nur noch Müll angezeigt. 

Ich bräuchte da mal, wie gesagt, eine 'offizielle Meinung', ob es sich lohnt in dieser Richtung weiter zu machen.
In der Anlage zum testen mal ein paar geänderte Dateien. Bitte mit UTF-8 ausprobieren.
Die Änderungen entsprechend weitgehend denen aus dem o.g. Thread mit ein paar Anpassungen.

MfG, thorn

Edit: Anhang ist nun weiter unten

[pcwacht]

Wann Sie die default_charset nutzen und dieses andert sich nach dass schreiben dan haben sie grossere aerger


When you use default_charset and this changes after stuff has been wriiten to the db you'll end up in bigger troubles


John

[Macros]

Hi,

ich bin dafuer voll auf UTF8 zu setzen, aber das habe ich auch an anderen Stellen schon zum Ausdruck gebracht, werde morgen mal eben deinen "Patch" testen.

Heute komme ich da nicht mehr zu.

Gruss

[thorn]

When you use default_charset and this changes after stuff has been wriiten to the db you'll end up in bigger troubles

Erstaunlicher weise funktioniert das sogar besser als heute!
Gerade ausprobiert:
- neue wb-Installation
- die geänderten Dateien einspielen
- Charset in WB auf UTF-8
- Editor htmlarea oder xinha (damit der content auch echte Umlaute enthält)
- in class.database.php:
mysql_query("SET NAMES 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");
- eine Seite anlegen, im Titel und Content Umlaute benutzten
- View-> Seite wird richtig angezeigt.
- Charset in WB auf ISO-8859-1 stellen
- ein blick auf Pages zeigt nur wirre Zeichen statt Umlaute, aber nun:
- in class.database.php:
mysql_query("SET NAMES 'latin1'");
mysql_query("SET CHARACTER SET 'latin1'");
- im Brower Pages aktualisieren, <staunen>
- View-> Seite wird wieder richtig angezeigt <noch mehr staunen>. 

Dadurch das alle Umlaute in der Datenbank als UTF-8 abgelegt werden, und durch das Einstellen des richtigen "Verbindungs-Charsets" in class.database.php wird auch die Anzeige immer richtig sein!
Einziges Manko: gibt man bei Verwendung von WB-Charset:UTF-8 Zeichen ein, die in z.B. ISO-8859-1 nicht vorhanden sind, und schaltet dann in WB um nach ISO-8859-1, werden anstelle dieser Zeichen nur '?' angezeigt. Aber dieses Problem hat man immer wenn man zwischen unterschiedlich großen Charsets wechselt.
Ein Grund mehr komplett auf UTF-8 zu gehen!

MfG, thorn

Edit: gerade merke ich, daß man noch eine Änderung an der Datenbank vornehmen muß, damit man unter UTF-8 Zeichen außerhalb latin-1 speichern kann:
mindestend für erste Tests
die Kollation auf "utf8_unicode_ci" ändern für folgende Felder:
wbymod_wysiwyg: content und text
wbypages: page_title und menu_title
Außerdem für die ganze Datenbank die Standard-Kollation auf "utf8_unicode_ci"

(d.h. wenn man kpl nach UTF-8 will, muß entweder die Datenbank direkt mit Kollation "utf8_unicode_ci" und charset "utf8" angelegt werden
(z.B. für module/wysiwyg:)

Code:

        // Create table
        $database->query("DROP TABLE IF EXISTS `".TABLE_PREFIX."mod_wysiwyg`");
        $mod_wysiwyg = 'CREATE TABLE `'.TABLE_PREFIX.'mod_wysiwyg` ( '
                . ' `section_id` INT NOT NULL DEFAULT \'0\','
                . ' `page_id` INT NOT NULL DEFAULT \'0\','
                . ' `content` TEXT NOT NULL ,'
                . ' `text` TEXT NOT NULL ,'
                . ' PRIMARY KEY ( `section_id` ) '
                . ' ) '
                . ' DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci '
                . ' ';
        $database->query($mod_wysiwyg);

, oder man muß bei jedem(?) Zugriff auf die Datenbank die Kollation mit angeben.


Interessant:
Es sieht so aus als wenn bestehende Seiten die mit ISO-8859-1 erstellt wurden ohne Änderung weiter funktionieren (weil dort durch den Standard-charset latin1 die Umlaute schon als UTF-8 in der Datenbank liegen). Seiten die in einem anderen Charset erstellt wurden, werden dagegen nicht mehr richtig angezeigt.

Ich habe auch gleich mal einen neuen Anhang zusammengestellt. (Die oben genannten Felder müssen von Hand umgestellt werden, wenn man mit Zeichen außerhalb latin-1 testen will).

Edit: Anhang ist nun weiter unten

MfG, thorn

[thorn]

Hallo,

da mir das selbst langsam zu umständlich wird mit dem "Dateien hier einspielen, Datenbank dort ändern, hier jenes dort dieses"...
habe ich mal eine komplette wb-Installation angepaßt für die Verwendung mit UTF-8:

Enthalten sind die Änderungen aus dem Thread "WebsiteBaker und Chinesisch", ein paar weitere Änderungen, und ganz wesentlich: in der wb/install/save.php wird die Datenbank nun so angelegt

Code:

// Try to create the database
mysql_query('CREATE DATABASE '.$database_name.' DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci');

Diese Eigenschaften vererben sich auch auf alle Tabellen.

Das ist allerdings mit ziemlich heißer Nadel gestrickt, hoffe es läuft auch auf mySQL<5.

Zum Ausprobieren:
- WB wie üblich installieren.
- CHARSET auf UTF-8 (default) lassen
- munter Seiten mit Umlauten anlegen, im Titel/Menu und Content
- Seiten ansehen; auch im Menu sollten die Umlaute funktionieren
- weitere Seiten anlegen mit 'exotischen Zeichen' -- einfach ein paar kyrillische oder chinesische Zeichen aus dem Internet kopieren...
- Seiten ansehen: auch das sollte funktionieren, sowohl im Menu als auch im Content.

- in WB den Charset auf ISO-8859-1 ändern
- ACHTUNG dann ist noch eine Änderung am Quelltext nötig:
in wb/framework/class.database.php  die Zeilen

Code:

mysql_query("SET NAMES 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");

ändern zu

Code:

mysql_query("SET NAMES 'latin1'");
mysql_query("SET CHARACTER SET 'latin1'");

- auch jetzt sollte sowohl die Menus als auch Content wieder richtig angezeigt werden!
(mit Ausnahme von Zeichen die in ISO-8859-1 nicht vorhanden sind, die werden nur als '?' dargestellt.)
Wenn man die Änderungen wieder rückgängig macht (zu UTF-8), wird wieder alles komplett angezeigt.

Edit: Anhang weiter unten

[doc]

@thorn
Es ist ausreichend, die geänderten Dateien inklusive Ordnerangaben als ZIP zu speichern.
Spart Platz und mann überschreibt nur die Dateien, die wirklich geändert wurden. Weiterhin sehen auch andere sofort, welche Daten denn nun eigentlich geändert sind. Mit einem XDIFF ist es dann leich möglich, die geänderten Passagen hervorzuheben.

Gruss Christian

[thorn]

@thorn
Es ist ausreichend, die geänderten Dateien inklusive Ordnerangaben als ZIP zu speichern.
Spart Platz und mann überschreibt nur die Dateien, die wirklich geändert wurden. Weiterhin sehen auch andere sofort, welche Daten denn nun eigentlich geändert sind. Mit einem XDIFF ist es dann leich möglich, die geänderten Passagen hervorzuheben.

Ja, sinnig; war wohl schon ein wenig spät. 

Hier also der aktuelle Stand. Bitte Datenbank zum testen neu anlegen!
Bei bestehenden Datenbanken müßte (oder sollte, sonst gibt es Einschränkungen) der default Charset und Collation umgestellt werden.

Kurz die Änderungen beschrieben:
- Die neue such-funktion mit highligting ist hier schon enthalten (mit bugfix)
- Aufrufe von htmlentities() entfernt in:
wb/admin/pages/index.php
wb/admin/pages/modify.php
wb/admin/pages/sections.php
wb/admin/pages/settings.php
wb/admin/pages/settings2.php
wb/admin/pages/trash.php
wb/framework/class.frontend.php
wb/framework/frontend.functions.php
- wb/search/search.php: bugfix - Suche in UTF-8 funktionierte nicht richtig
- wb/framework/functions.php: my_htmlspecialchars(), get_wbcharset(), entities_to_umlauts(), umlauts_to_entities(), entities_to7bit() hinzu.
[die meisten dieser Funktionen werden nur benötigt, um die Probleme, die durch die Möglichkeit der Verwendung verschiedener charsets entstehen, zu umgehen. In einer reinen UTF-8-Installation können sie wieder raus.]
- wb/framework/functions.php: page_filename() und media_filename() geändert.
- wb/framework/convert.php: nur noch für 'kosmetische' Zwecke, die Hauptaufgabe der Bestimmung von page_filename übernimmt nun entities_to7bit().
- wb/admin/add.php: Aufruf von my_htmlspecialchars() hinzu; Änderung an page_filename-Bestimmung
- wb/admin/settings2.php: Aufruf von my_htmlspecialchars() hinzu; Änderung an page_filename-Bestimmung
- wb/framework/class.database.php: Festlegung des "Verbindungs-Charsets"; zur Zeit noch hard-coded, muß noch überarbeitet werden.
- wb/install/save.php: Anlegen der Datenbank mit default charset und collation 'utf8'; diese Eigenschaft wird auf alle Tabellen vererbt (d.h., daß man die Module nicht anpassen muß - puhh)

Der Hauptunterschied zum Lösungsansatz aus dem Thread "WebsiteBaker und Chinesisch" ist, daß hier menu_title und page_title keine entities enthalten, sondern nativ im verwendeten DEFAULT_CHARSET vorliegen.
Der Knackpunkt an dieser Lösung ist, daß man nur noch Zeichen verwenden kann, die zum DEFAULT-CHARSET gehören.

Zum testen dieser Variante bitte die Hinweise in den obigen Posts beachten.

Edit:
Ich habe mir nochmal Gedanken dazu gemacht, inwieweit die Forderung komplett auf UTF-8 umzustellen überhaupt notwendig ist. Und ich meine inzwischen, daß das ziemlich egal ist! Bisher hatte ich folgendes Szenario im Kopf: Ein User legt munter eine Seite an in ISO-8859-1. Nachdem er dutzende Seiten mit Content angelegt hat, fällt im ein, daß er nun auch ein türkisches, russisches oder japanisches Wort darstellen möchte. Kurz darauf fragt er dann hier im Forum, warum das nicht geht  (mit der Original-Installation geht es im Titel und Menu nicht; mit meiner Variante geht es auch im Content nicht (es sei denn der Editor erzeugt entities)).
Und ein Umstellen der kompletten Seite auf UTF-8 zerstört alle Umlaute... Darum bisher meine Forderung nach UTF-8-ONLY.
ABER: mit dieser Lösungsvariante die ich hier anbiete geht das dann ja doch - wie ich oben gezeigt habe. D.h. der User kann bei einer bestehenden Seite den DEFAULT_CHASRET von z.B. ISO-8859-1 auf UTF-8 umstellen, und die vorhandenen Umlaute werden immer noch richtig angezeigt (Nur ein zurückwechseln von UTF-8 nach ISO-8859-1 unterliegt den Beschränkungen des kleineren Charsets). Damit ist es ziemlich egal ob man außer UTF-8 weitere Charsets anbietet oder nicht.
Weitere Vorteile:
- Unabhängig vom DEFAULT-CHARSET werden die Daten in der Datenbank immer in UTF-8 gespeichert. Das ist zur Zeit nicht der Fall! (wenn z.Z. der DEFAULT_CHARSET in wb z.b. auf UTF-8 steht, passiert folgendes: WB übergibt die Umlaute im UTF-8-Format - mySQL meint, weil der "Verbindungs-Charset" standardmäßig auf 'latin1' steht (und von WB nicht verändert wird), es müßte eine latin1-->UTF-8 Konvertierung durchführen, und es speichert nur noch Datenmüll in der Datenbank. Daß das trotzdem funktioniert, liegt daran, das mySQL auf dem Rückweg wieder eine UTF-8-->latin1 Konvertierung durchführt, wodurch dann wieder richtige UTF-8 Zeichen entstehen.)
- eine konsistente Datenbank ist Voraussetzung für spätere Updates ... (hat man glaube ich beim Wechsel von 2.6.4 nach 2.6.5 gesehen)
-  keine Entities in Titel und Menu

Das o.g. gilt leider nur für Neuinstallationen (d.h. bei denen die Datenbank neu angelegt wird). Bei bestehenden Datenbanken ergeben sich folgende Probleme:
- default Charset und Collation muß geändert werden (sowohl für die DATABASE als auch für jede TABLE): dafür bräuchte man ein php-Skript, daß nachsieht welche Tabellen da sind, und diese dann entsprechend ändert.
- Seiten in ISO-8859-1 und (englische) Seiten ohne Umlaute funktionieren dann; aber Seiten die mit einem anderen Charset erstellt wurden (UTF-8, GB2312, ISO-8859-11,...) sind dann verstümmelt. Möglicherweise könnte man das lösen, indem man einen Dump der Datenbank entsprechend konvertiert und wieder einspielt -- aber weder iconv noch recode kommen mit dem Zeichensalat klar. Hier bräuchte man wiederum ein Skript, das jeden einzelnen "String" aus der Datenbank mit Verbindungs-Charset 'latin1' liest, und in mit 'utf8' zurückschreibt.

MfG, thorn

[ruebenwurzel]

Hallo,

denkt bitte bei allem dran dass

1. Alle Änderungen abwärtskompatibel sein sollten (Upgrades von jeder 2.6.x Version müssen möglich sein.
2. Alles auch Auf Mysql 3.x Datenbanken laufen sollte
3. Sonderzeichen in menu_title und page_title möglich sein sollten.
4. Auch die WB Module weiterhin funktionieren sollten
5. Es auch eine Welt außerhalb UTF8 gibt (wobei UTF8 der Standard sein sollte)

Matthias

[thorn]

1. Alle Änderungen abwärtskompatibel sein sollten (Upgrades von jeder 2.6.x Version müssen möglich sein.
2. Alles auch Auf Mysql 3.x Datenbanken laufen sollte
3. Sonderzeichen in menu_title und page_title möglich sein sollten.
4. Auch die WB Module weiterhin funktionieren sollten
5. Es auch eine Welt außerhalb UTF8 gibt (wobei UTF8 der Standard sein sollte)

Die Kompatibilität ist echt problematisch:
zu 1: neu aufgesetzte Datenbanken sind ja kein Problem, aber bei bestehenden kann ich zur Zeit nur mit iso-8859-1 und utf8 erstellte Datenbanken umsetzten, bei den anderen Charsets hapert es irgendwo
zu 2: laut Doku sollte das gehen, kann ich aber nicht testen.
zu 3: sowieso
zu 4: das auch
zu 5: da würd ich inzwischen schon wieder das genau Gegenteil von oben behaupten da die von WB verwendeten Zeichensätze zum Teil inkompatible zu PHPs mb_-Funktionen und zu mysql sind    Die Multibyte-String-funktionen von PHP kennen iso-8859-11 und gb2312 nicht, mysql kennt weder iso-8859-3, -4, (-5?), (-6?), -10, -11 (soweit die nicht mit cp1251 oder cp1252 identisch sind?), noch iso-2022-jp und -kr. Damit wird man nie glücklich, solange man neben UTF-8 auch noch andere Charsets zuläßt.

MfG, thorn

Edit:
gerade stelle ich fest, daß in dem Fall wenn die Datenbank nicht bei der Installation von WB erzeugt, sondern vom Provider gestellt wird, das mit der Vererbung von Charset und Collation natürlich nicht geht 
Stattdessen müßte man wirklich für jede Tabelle, in jedem Modul ... bei der Erzeugung der Tabellen den charset mit angeben...

Naja, ich betrachte das ganze damit erstmal als abgehakt. Vielleicht mag das obige ja als Anregung für eine zukünftige Version dienen. Im Anhang nochmal mein aktueller und erstmal letzter Stand (UTF-8-ONLY!). Dieser Version arbeitet nur wenn WB die Datenbank bei der Installation neu anlegt.
Es fehlt noch:
- Erzeugen der Tabellen mit charset und collation 'utf8' (siehe wb/install/save.php)
- Möglichkeit der Konvertierung von bestehenden Datenbanken ungleich utf8 oder iso-8859-1

MfG, thorn