Bakery auf UTF-8 umstellen

[dbs]

Hallo,

was müsste man tun um Bakery auf UTF-8 umzustellen?
Also so, dass Daten in der Datenbank in UTF-8 gespeichert und ausgelesen werden.

Mein DB ist auf UTF-8 eingestellt. Umlaute werden aber in der Form ü ä ö gespeichert.
Das ist sicher nicht richtig so, hm?

Gruß
dbs

[dbs]

Wenn ich das richtig verstanden habe dann schickt Bakery die Daten als ISO-irgendwas an die DB aber sagt es nicht dazu. Meine DB denkt deshalb es kommt passend als UTF-8 und speichert dadurch falsch.

Habe nun einige Dateien mit utf8_encode bzw. _decode bearbeitet und glaube mich auf dem richtigen Weg.
Wenn das als Neben-Effekt noch korrekte Email-Betreffs ausspuckt bin ich zufrieden, aber soweit ist es noch nicht.

[jacobi22]

Mein DB ist auf UTF-8 eingestellt. Umlaute werden aber in der Form ü ä ö gespeichert.

welche denn?
Alles, was du NICHT über das oder die Wysiwyg-Felder änderst oder einträgst, wird in der Codierung versendet und auch gespeichert, die du als Zeichensatz in den Optionen eingestellt hast. Lt. früherer Posting ist das bei dir UTF-8.
Das betrifft bei Bakery sämtliche Einstellungen, auch die User-Adressdaten usw.

Was über das oder die Wysiwygfenster geschickt wird (Artikel-Lang- und ggf. Kurzbeschreibungen) wird (wie auch alle anderen Wysiwyg-Blöcke einer Seite vom eingestelltem Editor umgewandelt, ich glaube mit htmlentities

Wenn ich das richtig verstanden habe dann schickt Bakery die Daten als ISO-irgendwas an die DB aber sagt es nicht dazu

Quelle=Selfhtml
Ein Formular wird üblicherweise von den Browsern in der Codierung versendet, die für die Seite angegeben wurde, in dem es steht. Wenn also der Server eine Webseite mit einem Formular ausliefert, die in UTF-8 codiert ist, wird der (Antwort-)Request mit den Formulardaten ebenfalls UTF-8-codiert werden.

[dbs]

from: http://www.bakery-shop.ch/#charset

All Bakery files are saved using iso-8859-1 charset encoding. If you are running your WB installation using another charset you might get troubles with special chars.

welche denn?

ü ä ö

ü ä ö  ist so also richtig gespeichert?
Wysiwyg-Zeug wird als htmlentities gespeichert, richtig.

MySQLDumper zeigt mir dies:

character_set_clien t   utf8
character_set_conne ction   utf8
character_set_datab ase   latin1
character_set_files ystem   binary
character_set_resul ts   utf8
character_set_serve r   latin1
character_set_syste m   utf8

[freeSbee]

Hallo dbs

from: http://www.bakery-shop.ch/#charset

All Bakery files are saved using iso-8859-1 charset encoding. If you are running your WB installation using another charset you might get troubles with special chars.

Dieses Zitat bezieht sich nur auf die von Bakery benutzten Sprachdateien und keineswegs auf den Datenverkehr zwischen Client und Server.


Datenübertragung und Zeichensatz-Codierungen sind ein komplexes Thema und schon manch erfahrener Programmierer hat sich seine Zähne (oder zumindest ein paar davon) daran ausgebissen. Eine Ahnung davon erhältst du, wenn du folgenden Artikel überfliegst:
http://forum.mysqldumper.de/die-umlautproblematik-was-wieso-was-tun-t2313.html

Wenn du das Problem allerdings lösen möchtest, dann kann dir der Artikel eine grosse Hilfe sein, sofern du bereit bist, ihn genau zu studieren und die Sachverhalte exakt nachzuvollziehen.

Falls dein Problem aber nur in der Datenbank auftritt - zB. beim Betrachten der Datenbank-Inhalte mit phpMyAdmin - und nicht bei der Ausgabe der Zeichen im Browser, so empfehle ich dir die Hände davon zu lassen - du kannst dir damit einen grossen Aufwand und viel Zeit ersparen!

Gruss Christoph

[dbs]

Hallo Christoph,

den Link zu MySQLDumper hatte ich beim Suchen schon mal gefunden und die Seite nicht kurz aber auch nicht sehr lange studiert. Deshalb dachte ich das Problem vielleicht erkannt zu haben.

Die Darstellung in der DB würde mir egal sein, wenn ich nicht Probleme hätte.
Konkret sind das 2 Dinge:

1. Die Bestätigungsmail für eine Bestellung zeigt im Betreff die Umlaute in der Form ü ä ö. Nicht bei allen Empfängern, aber GMX z.B.

2. Ich möchte Artikel in die DB importieren. Das geht scheinbar am Besten in Textform.
Sind dort Umlaute enthalten werden sie als äöü abgespeichert. Bei der Ausgabe im Browser gibt es dann Probleme.

Vielleicht muss ich an anderen Stellen schrauben?

Gruß
dbs

[jacobi22]

2. Ich möchte Artikel in die DB importieren. Das geht scheinbar am Besten in Textform.
Sind dort Umlaute enthalten werden sie als äöü abgespeichert. Bei der Ausgabe im Browser gibt es dann Probleme.

am simpelsten geht das z.b. im Editorfenster. Text rein kopieren, auf Quelltext umschalten, fertig

[dbs]

Moin Uwe,

ich will ja nicht nur 1 oder 2 Artikel importieren.  

Nochmal gefragt, wenn ich ü ä ö im Backend speichere (nicht wysiwyg), wie sollte es dann in der DB zu sehen sein, wenn alle beteiligten Parteien auf UTF-8 eingestellt sind?

[freeSbee]

Hallo dbs

Wichtig ist noch zu wissen, dass eine Datenbank-Tabelle einen eigenen, von der Datenbank unabhängigen Charset haben kann. Wenn du in der Exportdatei einer Datenbank beispielsweise unter "Tabellenstruktur" nachsiehst, findest du am Ende der Aufzählung der einzelnen Tabellenfelder generelle Angaben zur Tabelle. Zum Beispiel folgende Zeile
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=59 ;
Hier wird der Charset der Tabelle explizit angegeben und sollte in deinem Fall natürlich auch auf utf8 eingestellt sein.
 

Falls du nur einmalig einen Import machen musst, wäre folgendes eine Lösung - quick&dirty:
Öffne die Datei, welche importiert werden soll, in einem Texteditor und ersetze mit Hilfe der "Suchen-Ersetzen"-Funktion alle Umlaute durch die 'falschen' Entsprechungen. Also
ä durch ä
ö durch ö
ü durch ü
Ä durch Ä
Ö durch Ö
Ü durch Ãœ
ß durch ß

Gruss Christoph

[dbs]

AHA!

Danke Christoph, hier ein Auszug vom Dump der Tabelle mod_bakery_items:

Code:

DROP TABLE IF EXISTS `wbmod_bakery_items`;
CREATE TABLE `wbmod_bakery_items` (
  `item_id` int(11) NOT NULL auto_increment,
  `section_id` int(11) NOT NULL default '0',
  `page_id` int(11) NOT NULL default '0',
  `group_id` int(11) NOT NULL default '0',
  `active` int(11) NOT NULL default '0',
  `position` int(11) NOT NULL default '0',
  `title` varchar(255) character set latin1 collate latin1_general_ci NOT NULL default '',
  `sku` varchar(20) character set latin1 collate latin1_general_ci NOT NULL default '',
  `stock` varchar(20) character set latin1 collate latin1_general_ci NOT NULL default '',
  `price` decimal(9,2) NOT NULL,
  `shipping` decimal(9,2) NOT NULL,
  `tax_rate` decimal(5,2) NOT NULL,
  `definable_field_0` varchar(150) character set latin1 collate latin1_general_ci NOT NULL default '',
  `definable_field_1` varchar(150) character set latin1 collate latin1_general_ci NOT NULL default '',
  `definable_field_2` varchar(150) character set latin1 collate latin1_general_ci NOT NULL default '',
  `link` text character set latin1 collate latin1_general_ci NOT NULL,
  `main_image` varchar(50) character set latin1 collate latin1_general_ci NOT NULL default '',
  `description` text character set latin1 collate latin1_general_ci NOT NULL,
  `full_desc` text character set latin1 collate latin1_general_ci NOT NULL,
  `modified_when` int(11) NOT NULL default '0',
  `modified_by` int(11) NOT NULL default '0',
  PRIMARY KEY  (`item_id`)
) ENGINE=MyISAM AUTO_INCREMENT=29 DEFAULT CHARSET=utf8;

Da muss ich mich wohl nicht wundern, dass die Umlaute (title, description) umgewandelt werden von utf-8 zu latin1 beim Speichern.

[jacobi22]

Da muss ich mich wohl nicht wundern, dass die Umlaute (title, description) umgewandelt werden von utf-8 zu latin1 beim Speichern.

Umlaute werden aber in der Form ü ä ö gespeichert.

Äh..... bringst du da nicht etwas durcheinander?

Das ist UTF-8
Artikel äöü

das latin1 mit htmlentities
Artikel  äöü

[dbs]

Ähm... das war ja meine Frage wie es aussehen muss als UTF-8. 

Code:

`title` varchar(255) character set latin1 collate latin1_general_ci NOT NULL default '',

Die Zeile sagt mir doch aber, dass ihr bzw. dem Feld UTF-8 egal ist, weil es auf latin1 steht. Richtig?

Verwechselt wird sicher einiges von mir, deshlab ist jede Hilfe willkommen.

[jacobi22]

Ich zitiere mal, was da passiert, wenn man beim Eintragen und Auslesen ist

    Wir sind auf einem Linux-System mit UTF-8 als Zeichensatz. Die Eingabe „üüü“ wird daher in die ANSI-Zeichen „üüü“ umgesetzt.
    Der MySQL-Client erwartet Latin1, liest also nicht „üüü“, sondern eben „üüü“.
    Und dies schickt er auch an den Server, und zwar mit der Anmerkung, es handele sich hier um Daten im Format Latin1.
    Der Server wiederum weiß, dass die Tabelle UTF-8 benutzt und konvertiert entsprechend die ankommenden Daten von Latin1 nach UTF-8. Er speichert also nicht ein UTF-8-"ü", sondern UTF-8-„üüü“
    Wir fragen die Tabelle ab und verlangen dabei das Format Latin1.
    Der Server gibt uns die Daten zurück, konvertiert aber vorher von UTF-8 nach Latin1, weil der Client das so wollte.
    Der Client erhält „üüü“ als ANSI und druckt das aus.
    „üüü“ werden auf dem Bildschirm als „üüü“ angezeigt.
Quelle: PHP und UTF-8

Noch mal ne Nachfrage.... Deine einziges Problem ist doch, das gmx deinen Mailbetreff eher nach Laune umwandelt (oder auch mal nicht) oder ist noch was dazu gekommen?

[dbs]

Hab den Link mal verfolgt, danke.
Mein Problem ist wohl keins.

Da beim Import per Text das ü als ü in der DB stand und deshalb im Browser kein ü war, sah ich ein Problem.
Da in der Bestätigungsmail im Betreff ein ü kein ü war, sah ich ein Problem.
Da dies auch beim Versenden durch das Modul MassMail auftrat, sah ich Handlungsbedarf.

Da der Autor von MySQLDumper so ein Programm gebastelt hat, dass dir in der DB alle komischen Umlaute in normale verwandelt, dachte ich eben, dass alle meine komischen (ANSI) falsch abgespeichert wären.

Will nicht mehr, Nautze voll.

[jacobi22]

und ich dacht schon, ich muß mir nun noch einen GMX-Account zu legen, um das testen zu können