SHOP UTF-8 ...

[ShopNix]

Diese Aussage ist dokumentiert fundiertes Halbwissen.

[Bonsai]

Du kannst Dich gerne reinlesen ...
http://php.net/manual/de/function.strftime.php.
http://php.net/manual/de/function.setlocale.php
Hier sind besonders die Kommentare unter der Doku wichtig.
Der von  "jose dot nobile at gmail dot com" erklärt warum nur 'de_DE.UTF-8' quatsch wäre, weil die Windoof Systeme dann evtl. auf die Fresse fliegen.

Ich bin Fachinformatiker Fachrichtung Systemadministration und habe einige Jahre in multinationalen Großkonzernen in heterogenen IT-Landschaften als 3rd Level im Softwaresupport gearbeitet. Da gewöhnt man sich irgendwann ab es genau wissen zu wollen WARUM etwas funktioniert, weil da einfach keine Zeit dafür ist. Man konzentriert sich darauf etwas zum laufen zu bekommen. Man fokussiert sich dann auf das WIE es funktioniert.

Meine Aussage

Heutige Linuxsysteme brauchen 'de_DE.UTF-8' um richtig zu funktionieren, können aber irgendeine der anderen Optionen auch, und nehmen dann diese falsche ..... die auf älteren Systemen Sinn machen kann

basiert darauf, dass es mit ISO Zeichensatz damit ging:

Code: PHP  [Auswählen]

@setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.UTF-8', 'utf-8', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15');

und zwar scheissegal ob auf Linux, oder Windoof. Der hatte vermutlich das de-DE oder de_DE@euro kapiert und gut war.
Mit UTF-8 ging das nicht:

Code: PHP  [Auswählen]

@setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.UTF-8', 'utf-8', , 'German','de_DE.UTF-8');

Das aber schon:

Code: PHP  [Auswählen]

@setlocale(LC_TIME, 'de_DE.UTF-8', 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.UTF-8', 'utf-8', 'German');

Das brachte mich zum Lesen der Doku über setlocale ....
Meiner Meinung nach sollten alle Werte die UTF-8 enthalten an den Anfang gestellt werden, weil es die Wahrscheinlichkeit erhöht, dass es auf den meisten Systemen funktioniert. Wenn Du es genau wissen willst, dann probiere es aus .... oder lies ca. ein Jahr lang Doku.
Apache läuft auf Windoof (das sind mit XP vor SP2, nach SP2, XP vor SP2 Home, XP nach SP2 Home, 2000, 2000Server, 2003Server, 2008Server, 2010Server, 2012Server, 7, 7 home, 8, 8 home, 10, 10 home schon 15 völlig unterschiedliche Systeme .... multipliziert mit Sprachpaket installiert oder nicht .... und welches, multipliziert mit System Locale Einstellung und System Zeichensatz Einstellung), Linux (<- das sind einige mehr .... insbesondere wenn man die Konfigurationsmöglichkeiten beachtet https://de.wikipedia.org/wiki/Liste_von_Linux-Distributionen), FreeBSD, OS/X, etc ..... und das war nur der Apache!
Daher ist ein einziger Wert für die Locale völliger Quatsch! Und das ist kein Halbwissen, sondern Erfahrung Es genau zu wissen ist nicht erforderlich .... ich bin kein Wandelndes Tabellenbuch und will auch keins sein, auch wenn ich bei HP schon mal den Spitznamen "Walking knowledgedatabase" eingefangen hatte.

Ich hatte mal ein DOS Batch Script geschrieben, das lief auf ca. 2800 Systemen, aber auf den 4 Rechnern in Polen flog es auf die Fresse, die 5 Russen funktionierten aber. In Polen hatte ein Admin die Systemlocale anstatt der Userlocale anders gesetzt.  .... genau so Probleme verursachst du, wenn Du da Werte rauslöschst, die irgendwer aus einem bestimmten Grund aufgenommen hat. Das sind Fallback Werte!!!

[ShopNix]

Hier eine kleine Testroutine:

Code: PHP  [Auswählen]

echo '<pre>';
$loc = array('German', 'de_DE.ISO_8859-15', 'de_DE.UTF-8', 'de_DE.UTF8', 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1');

  foreach ($loc as $val) {
    echo setlocale(LC_TIME, $val) . ' - ' . strftime("%d. %B %G", mktime(0,0,0,3,3,2016)). "\n";
  }
echo '</pre>';

Da stehen also verschiedene Werte aus einem existierenden Shop, und zwecks "schönerer" Ausgabe habe ich die Reihenfolge der Werte im Array umgestellt. Das Ergebins auf meiner lokalen Testkiste:

Code: PHP  [Auswählen]

 - 03. March 2016
 - 03. March 2016
de_DE.UTF-8 - 03. März 2016
de_DE.UTF8 - 03. März 2016
de_DE@euro - 03. M�rz 2016
de_DE - 03. M�rz 2016
 - 03. M�rz 2016
 - 03. M�rz 2016
 - 03. M�rz 2016
de_DE.ISO_8859-1 - 03. M�rz 2016

Wie man sehr schön sieht, gibt setlocale() keinen Wert zurück, wenn eine Lokale übergeben wird, die auf dem System nicht vorrätig ist. In den beiden ersten Fällen bleibt der englische Default erhalten, zwei Varianten stellen den nach utf8 dar, und die letzte gültige setlocale bleibt danach erhalten.

Ganz interessant ist, dass die Version mit Bindestrich den richtigen Wert ergibt, obwohl eine Abfrage auf meinem System nur die ohne Bindestrich ausgibt:

Code: PHP  [Auswählen]

arno@jessie:~$ locale -a
C
C.UTF-8
de_DE
de_DE@euro
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
deutsch
german
POSIX

[noRiddle (revilonetz)]

Ich hab's ehrlichgesagt bislang auch lediglich per "trial and error" gemacht  .
Mit

Code: PHP  [Auswählen]

@setlocale(LC_TIME, 'de_DE.UTF-8', 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15');

hat's bislang auf allen Umgebungen funktionobelt.
In der Tat sind allerdings die ISO-Angaben am Ende evtl. überflüssig.

Ich denke es wäre sinnvoll in einer zukünftigen modified-Version im Backend unter Land/Steuer => Sprachen bei der jeweiligen Sprache ein Eingabefeld für eine Konfigurations-Konstante einzubauen und die Werte darin für die setlocale()-Einstellungen zu benutzen.
Man könnte das Feld mit zwei Beispielen für ISO-8859-15 und UTF-8 kommentieren und Default-Werte bei Installation für UTF-8 bereits vorbelegen.
Somit müsste man die Sprachdateien nicht mehr anfassen und anpassen.

Habe dazu ein Ticket angelegt.

Gruß,
noRiddle

[ShopNix]

...
In der Tat sind allerdings die ISO-Angaben am Ende evtl. überflüssig.
...

Was überflüssig ist, hängt vom jeweiligen Server ab und muss uns, wie die kleine Testroutine zeigt, auch nicht interessieren. Dass die Reihenfolge der Einträge entscheidend ist, zeigte sich bei meinen Tests allerdings auch. Der erste Eintrag gewinnt.

Äußerungen wie "heutige Linuxsystem" sind allerdings für die Katz, denn erstens ist Linux nicht homogen, und zweitens laufen mit Stand 2014 nur ca. ein Drittel aller Webserver mit Linux, ein weiteres Drittel mit irgendwelchen Unixoiden und ein weiteres Drittel unter Windows.

Mir kann's wurscht sein, weil ich meine eigenen Server betreibe und die gültigen Werte direkt abfragen kann.

[Bonsai]

Geschätze 80% der Shopbetreiber hier haben LINUX basiertes Shared Hosting .... das hat nix mit allgemeinen Marktanteilen zu tun.
Wer eigene Server fährt, weiß meistens was er tut.

Der erste Eintrag gewinnt.

Nein, der erste den das System kann!

@noriddle  gute Idee!

[Ladiva]

Ich klinke mich hier mal ein da ich ein Problem mit den Umlauten habe..

Ich habe den Aktuellen 2.0er Shop installiert - mit UTF-8.
Meine bestehede Datenbank Importiert - funktioniert auch alles.
In der Datenbank stehen die Einträge richtig, incl. Sonderzeichen.
Der Shop zeigt sie aber falsch an, im Quelltext sehe ich dann

<meta charset="iso-8859-15" />

Wo ist denn jetzt der Fehler? Im Template??? Ich habe es allerdings Beim XTC template als auch beim Modfied. Wenn ich dann z.b. eine Kategorie bearbeite und Sie speichere steht es am Ende auch falsch in der DB..

[Bonsai]

In includes/modules/metatags.php steht

Code: PHP  [Auswählen]

  echo '<meta charset="'.$_SESSION['language_charset'].'" />'."\n";

Geh mal ins Backend, Land/Steuer -> Sprachen
Schau mal bei allen installierten Sprachen ob da utf-8 eingestellt ist:
[ Für Gäste sind keine Dateianhänge sichtbar ]

[Ladiva]

Hallo,

es steht dort tatsächlich die iso-8859-15 - ein ändern auf UTF-8 bringt aber keine abhilfe und wenn ich erneut auf ändern gehe steht wieder die iso drin.

Installiert ist bei mir nur Deutsch.

[ShopNix]

utf-8 ist auf jeden Fall richtig, wenn auch die DB so eingestellt ist.

Du wirst allerdings das Ergebnis nicht sehen, wenn Du nicht den Browser neu startest, weil diese Variable mit der Session übergeben wird und somit die alte Einstellung aktiv bleibt, solange die Session läuft.

[Ladiva]

BINGO! das war der Grund - danke!

[Weinkrähe]

Das ALTER DATABASE Statement ist meines Erachtens nicht nötig.
Das DEFAULT CHARACTER SET und das DEFAULT COLLATE sind unerheblich. Ergeblich ist der Zeichensatz der DB-Verbindung.
Will sagen, wenn z.B. das DEFAULT CHARACTER SET der DB auf utf8 steht, die Daten in der DB aber in iso-8859-15 gespeichert sind (und die Collation entsprechend auf z.B. latin1_general_ci steht), die DB-Verbindung nun aber auf latin1 steht (siehe die Konstante DB_SERVER_CHARSET in den configure.php-Dateien), gibt es keine Probleme.
Gesetzt wird die DB-Verbindung mittels der oben genannten Konstanten in der Funktion xtc_db_connect(), die für alle Queries an die DB benutzt wird.

Das gleiche gilt umgekehrt, wenn also der DEFAULT CHARACTER SET auf latin1 steht jedoch die Daten in den Tabellen in utf8 gespeichert sind und die DB-Verbindung auf utf8 gesetzt ist.

Die DB muß lediglich wissen in welcher Kodierung die Queries an die DB erfolgen.

Fazit:
Die Konvertierung der TABLEs in das benötigte CHARACTER SET und die benötigte COLLATION reicht völlig aus, wenn die DB-Verbindung, also die Konstante DB_SERVER_CHARSET entsprechend gesetzt ist. Ein ALTER DATABASE Statement um die DEFAULTs zu setzen ist nicht nötig.

Noch zur Klärung:
Um Daten in die DB in der gewünschten Kodierung zu speichern ist die Konstante DB_SERVER_CHARSET wichtig.
Um die Daten aus der DB zu holen ebenso.
Soll die Kodierung in welcher der Shop läuft geändert werden, müssen lediglich die ALTER TABLE Statements aus dem Skript durchgeführt werden damit die bereits in der DB gespeicherten Daten in die gewünschte Kodierung umgewandelt werden.
Kommen tut das Skript von hier.

Nötig ist also folgendes wenn man nachträglich auf UTF-8 umstellen möchte:
(! Dabei bitte die Syntax-Unterschiede beachten (utf8 / utf-8)

• Skript für die DB laufen lassen (ohne ALTER DATABASE Statement)
• DB_SERVER_CHARSET in den beiden configure.php-Dateien auf utf8 setzen
• Backend => Land / Steuer => Sprachen => "meta-content" ("Charset" im Bearbeiten-Modus) auf utf-8 setzen
• Wenn nicht vorhanden in den Dateien /lang/SPRACHE/SPRACHE.php die setlocale() erweitern um 'de_DE.UTF-8' bzw. 'en_GB.UTF-8'
• Evtl., je nach Server-Konfiguration, entweder in der Root-htaccess das
  AddDefaultCharset UTF-8
  setzen oder in den beiden application_top.php ganz oben das
  ini_set("default_charset", "utf-8");
• In der aktuellen modified-Version 1.06 noch folgendes suchen:
  In /includes/classes/class.inputfilter.php das
  $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
  ändern in das
  $source = html_entity_decode($source, ENT_QUOTES, strtoupper($_SESSION['language_charset']));
  
• Für den RSS-Feed im Backend auf der Startseite in /admin/start.php alle utf8_decode() entfernen (kommt 3 x vor soweit ich weiß)
• In evtl. eingebauten Erweiterungen, z.B. RSS-Feed, kommt es darauf an wie die Erweiterungen konfiguriert sind. Handelt es sich um XML oder CSV muß evtl. die Kodierung angepasst werden oder mittels entsprechender Funktionen (utf8_encode(), utf8_decode()) die Ausgabe modifiziert werden.

Hoffe habe nichts vergessen.

Gruß,
noRiddle

Hallo zusammen,

habe nach dieser Anleitung meinen 1.0.6 SP2 r4642 Shop auf utf8 umgestellt.
Zuerst habe ich alles in meinem lokalen Testshop scheinbar erfolgreich umgesetzt.
Beim Liveshop hakt es jetzt leider und ich finde keinen Fehler.
Im Frontend sieht alles korrekt aus. Im Backend und in den Emails leider nicht. Dabei werden Umlaute zum Teil richtig und zum Teil falsch dargestellt. Weiß nicht mehr weiter.
Hat jemand einen Tipp?

Viele Grüße

Thomas

[Mike Randoo]

@Buddha
Wahrscheinlich hast Du es getan, aber trotzdem sicherheitshalber:
Browser hattest Du neu gestartet bzw. auch mal den Browsercache gelöscht?
In verschiedenen Browsern bzw. auf verschiedenen Geräten getestet und in allen das gleiche Ergebnis?
Manchmal kann schon Mailabruf auf Rechner und Smartphone unterschiedlich aussehen.
HTML und Textvariante der Mails geändert?

Wie wurde der Text/Code geschrieben? Schreibst Du wirklich ä,ö,ü oder sind noch die html-Entities im Text drin? Ggfs. mal mit den richtigen Umlauten schreiben und schauen, wie es dann aussieht.

[Weinkrähe]

Hallo Mike,

ja Cache im Browser und im Shop gelöscht, aus- + eingelogged. Email sieht auf dem Smartphone gleich aus und Backend in anderem Browser auch.

Vor allem die Kundendaten sind falsch dargestellt. Wie gesagt, im lokalen Testshop funzt es.

Danke und Gruß
Thomas

[Weinkrähe]

Das Problem in den Mails scheint gelöst. Die Texte mussten noch umformatiert werden.
Bleibt noch die falsche Darstellung im Backend.