Jump to content
xt:Commerce Community Forum

Auf UTF-8 umstellen


Recommended Posts

Ich habe gehört, dass man xt:Commerce ganz auf UTF-8 umstellen kann, um Darstellungsprobleme zu beseitigen.

Wie genau funktioniert das?

Welche Dateien muss ich ändern? (Mein Shop ist auf Deutsch und Russisch)

Ich bin für jede Hilfe dankbar!

Link to comment
Share on other sites

  • 4 weeks later...

Ich habe gehört, dass man xt:Commerce ganz auf UTF-8 umstellen kann, um Darstellungsprobleme zu beseitigen.

Mal ne blöde Frage, was hat der Zeichensatz der DB mit den Darstellungsproblemen zu tun?

Die meisten Darstellungsprobleme kommen doch daher, dass ich die Daten z.B. in UTF-8 abspeicher, aber in ISO-8859-15 ausgeben, oder anders herum.

Ich gehe mal davon aus, wir sprechen nur von diesen beiden Zeichensätzen.

Habe ich in der Datenbank meine Zeichen in ISO-8859-15 abgelegt, dann muss ich das dem Client auch sagen. Das mache ich doch mit dieser Zeile:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">

Link to comment
Share on other sites

  • 3 weeks later...

Mal ne blöde Frage, was hat der Zeichensatz der DB mit den Darstellungsproblemen zu tun?

Nichts. Wenn Du nur einen Zeichensatz hast, den Du darstellen willst, also nur Deutsch und Englisch z.B.

Die meisten Darstellungsprobleme kommen doch daher, dass ich die Daten z.B. in UTF-8 abspeicher, aber in ISO-8859-15 ausgeben, oder anders herum.

So kann man das auch sehen.

Sinnvoll ist es durchaus einen Shop, der verschiedenste Sprachen 'spricht' gleich UTF8 zu codieren und dann dem Shop zu sagen, dass er auch UTF8 ausliefern soll. Dann muss die Datenbank auch UTF8 codieren und es klappt auch mit Kyrillisch oder Farsi oder gar Chinesischen oder Japanischen Schriftzeichen.

Kyrillisch geht ja noch, die schreiben ja auch von links nach rechts aber bei Farsi oder Asiatischer Schrift wird es ganz übel - aber mit UTF8 hast Du die Zeichen zumindest mal richtig in der Datenbank, das Ausliefern musst Du dann mit einem angepassten theme vornehmen.

Ich gehe mal davon aus, wir sprechen nur von diesen beiden Zeichensätzen.

Das ist doch langweilig! :D

Habe ich in der Datenbank meine Zeichen in ISO-8859-15 abgelegt, dann muss ich das dem Client auch sagen. Das mache ich doch mit dieser Zeile:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">

Toll. Und wo machst Du diese Zeile hin? :mad:

Es gibt ja nur ein paar unwichtige Konfigurationsdateien bei XTC! :confused:

So etwas hasse ich, klugsch... und einen Brocken hinwerfen, mit dem man nicht wirklich was anfangen kann.

Alles muss man selber machen, also, umbauen von XTC geht so:

Erst einmal ein Backup der Datenbank machen, wenn man nicht (wie ich) den Shop gleich auf UTF8 umstellen will. Ich habe dafür PHPmyadmin benutzt, da klickt man einfach auf export, wählt SQL als Export und klickt Senden an, damit man es herunterladen kann. ;)

Die Manipulation der Datenbank habe ich direkt mit mysql gemacht, das Kommando dafür ist:

ALTER DATABASE <Datenbankname_ohne_Klammer> DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

So, jetzt ist die Datenbank (für neu angelegte Tabellen) auf UTF8 eingestellt. Dumm ist nur, dass da zig Tabellen schon drin sind, die man nun alle umwandeln muss:

ALTER TABLE <tablename> CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

So, wenn man die alle durch hat, schaut man mit PHPmyadmin mal nach, ob sie auch alle schön konvertiert worden sind und damit ist die Datenbank erstmal erledigt.:rolleyes:

Dumm ist nur, dass nun die Datenbank UTF8 liefert, nun aber lustige Zeichen erscheinen, wenn man sich die Seite anschaut. Was tun? :confused:

Der Schlüssel hierfür liegt in /includes/header.php auf ca. Zeile 35:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Damit liefert der Shop nun UTF8 aus, aber dummerweise weiss er noch nicht, dass aus der Datenbank nun auch UTF8 kommt:

In inc/xtc_db_connect.inc.php auf etwa Zeile 39 steht:

if ($$link) mysql_select_db($database);

da setzt der Könner noch:

mysql_query("SET NAMES 'UTF8'");

drüber und gut is.

Dumm ist nur das Kontaktformular, da habe ich mal einen Test gefahren und mit Sonderzeichen aus aller Herren Länder um mich geworfen und es kam im Header die Info mit der Mail an:

Content-Type: text/plain; charset = "iso-8859-15"

Content-Transfer-Encoding: 8bit

Was ja in dem Fall total sch...ade ist.

Vielleicht weiss ja jemand in dem Fall mehr als ich, ich denke, dass ich da PHP sagen muss, in diesem Fall doch dem Mailserver (in meinem Fall Postfix), dass diese Mail UTF8-codiert ist. :eek:

Allerdings wage ich zu bezweifeln, dass das so einfach geht, wie das oben beschriebene.

Hoffe, das Problem des einen oder anderen nun gelöst zu haben. :o

Ich muss nun ein Theme anpassen und ich habe keine Ahnung, wie ich das machen soll um persische Schriftzeichen richtig von rtl (right to left) auszugeben, denn in der Datenbank landen sie andersrum, wenn man sie eingibt. Ganz schön gaga...

Gruß,

Mussa

Link to comment
Share on other sites

Das ist doch langweilig! :D

Toll. Und wo machst Du diese Zeile hin? :mad:

Es gibt ja nur ein paar unwichtige Konfigurationsdateien bei XTC! :confused:

So etwas hasse ich, klugsch... und einen Brocken hinwerfen, mit dem man nicht wirklich was anfangen kann.

Wenn du es nicht langweilig magst, dann kannst du auch nicht erwarten dass dir alles vorgekaut wird. ;-)

Für mich stellte sich auch erst mal nur die Frage warum muss xtc zwingend auf UTF8 umgestellt werden. Aber gut UTF8 ist zumindest auch nicht falsch, ich glaube aber, dass man dann so einiges im Shop umstellen muss.

Ich habe mal was zu einem Bug geschrieben, wo du definitiv was ändern musst, damit der Zeichensatz richtig ist: Zeichensatzprobleme nach dem Editieren einer Bestellung

Ansonsten würde ich einfach mal mit einem grep "charset=" oder so ähnlich über die Dateien gehen. Da sollte eigentlich immer so etwas wie ?php echo CHARSET stehen. und irgendwo muss CHARSET ja definiert sein, da ich aktuell nicht an den Quelltext komme, kann ich dir aber nicht sagen wo.

Link to comment
Share on other sites

  • 4 weeks later...

Und doch habe ich Probleme.

Die zeichen stimmen soweit bis auf das Eurozeichen.

Aber das lässt sich manuell beheben.

Nun wird aber im Quelltext ein merkwürdiger Umbruch gezeigt,

der wohl auch Folgen hat.

Es wird nicht der in der DB angegebene Zeichesatz (utf-8)angegeben,

sondern der wie man hier sieht :

<meta http-equiv="Content-Type" content="text/html; charset=utf8_unicode_ci

" />

So wie die zeile hier steht mit dem Umbruch am Ende wird es im Quelltext dar gestellt - ich habe den ganzen Morgen gesucht aber nichts gefunden um das zu ändern.

Kann mir jemand hier weiter helfen ???

Wäre sehr nett

Danke

Link to comment
Share on other sites

  • 3 months later...
  • 1 month later...

Hallo,

ich gebe auf!:(

Womit?

Seit mehreren Tagen versuche ich vergeblich die Umlaute in den Bestell-Emails so darzustellen, d. h. so umzuwandeln, dass sie auch für normale Menschen lesbar sind.

In der Datenbank werden die Daten normal als Umlaut dargestellt.

Der Zeichensatz der Datenbank ist latin1_swedish_ci

Der header der E-Mail enthält u.a. folgende Daten:

X-Priority: 3

X-Mailer: PHPMailer [version 1.73]

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="b1_122d8.....3966304421b"

Ich habe es mit utf-8 probiert und auch im Adminbereich die Einstellung mail auf sendmail geändert.

Zusätzlich habe ich versucht per str_replace() die Umlaute beispielsweise in ae umzuwandeln...

...aber er stellt auf stur.

Das merkwürdige an der Sache ist, dass die Umlaute, die direkt in der html-Datei stehen richtig übertragen werden und zwar unabhängig davon, ob sie als Umlaut (ü) oder als html (ü) dort stehen. Das selbe gilt auch für die Datumsangabe (Bspl. März).

Was mir noch gerade einfällt:

Die E-Mails, die mit WordPress generiert werden, enthalten Umlaute.

(Am Server kann es meines Erachtens nicht liegen, oder doch?)

Über Eure Hilfe würde ich mich sehr freuen, denn mit meiner Weisheit bin ich am Ende.

Vielen Dank im Voraus und Euch allen eine gute Nacht.

Elke

Link to comment
Share on other sites

  • 2 years later...

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...