SHOP UTF-8 ...

[Bonsai]

noriddle, hast Post. Zugang zu einer Testdatenbank die das gleiche Verhalten zeigt.

[web28]

Code: PHP  [Auswählen]

xtc_db_query("ALTER DATABASE " . DB_DATABASE . " DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci");

Das halte ich auch für zwingend notwendig.

Gruss Web28

[Bonsai]

Der von mir angesprochene Fehler ist übrigens reproduzierbar. Ich habe es in einer Testdatenbank nachstellen können.

Also nach

Code: SQL  [Auswählen]

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8  COLLATE utf8_general_ci"

sollte immer noch ein

Code: SQL  [Auswählen]

"ALTER TABLE " . $table . " COLLATE utf8_general_ci"

folgen, weil sonst manche Tabellen auf dem alten Wert für die Kollation stehen bleiben.

Es handelt sich um Tabellen bei denen die Kollation nicht wirklich etwas bewirkt, (ohne Text oder Varchar Felder), ist also zum Zeitpunkt der Umstellung egal, wenn man aber später mal in solch einer Tabelle ein Textfeld einbaut, dann findet niemand mehr den Fehler.

[noRiddle (revilonetz)]

Code: PHP  [Auswählen]

xtc_db_query("ALTER DATABASE " . DB_DATABASE . " DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci");

Das halte ich auch für zwingend notwendig.

Gruss Web28

Hi web28, darf ich fragen warum ?
Ich bin folgender Überzeugung (durch Tests belegt):

• Entscheidend ist die Collation die im jeweiligen Feld steht und nicht die DB-übergreifende Collation.
• Hat man irgendwelche Erweiterungen in seiner DB und benötigt unterschiedliche Collations in diversen Tabellen ist die DB-übergreifende ja wieder störend, nach eurer Argumentation.
  Z.B. kann ich auf iso-8859-15 im Shop laufen aber für bestimmte Feeds oder XML-Exporte utf-8 benötigen und schreibe Daten in eine entsprechende Tabelle die auf utf-8 und einer entsprechenden Collation steht.
• Stimmt ja schon was mit der DB nicht wenn in int- oder decimal-Feldern eine Collation angegeben ist.
• Sollte jedes nachträgliche Hinzufügen eines Feldes oder einer Tabelle die Angabe der Collation enthalten, ansonsten kommt es immer wieder zu Inkonsistenzen.
• Dient mein Skript dazu verkehrte Ausgaben (z.B. defekte Umlaute) im Nachhinein zu fixen.
  Dabei kann man sich zwar entscheiden auch die DB-übergreifende Collation zu setzen, muß aber aufgrund meines Punktes 2. genau wissen was man tut.
  Das Setzen der DB-übergreifende Collation ist also mit Vorsicht zu genießen.
  (Die DB meines Demo-Shops steht z.B. auf utf-8 und Collation utf8_general_ci, der Shop läuft aber auf iso-8859-15, und zwar weil alle in Frage kommenden Felder (text, char, varchar usw.) die Collation latin1_german1_ci haben und die DB-Verbindung auf latin1 steht.)

Sicherlich kann es vordergründig nicht schaden die DB-übergreifende Collation auch zu ändern, wie gesagt aber nur, wenn man weiß was man tut.
"Zwingend notwendig" ist es jedenfalls keinesfalls.
Ich weiß, daß der Installer des Shops die DB-übergreifende Collation setzt, okay, ist ja auch klug bei der Installation.

Bonsais Approach noch ein

Code: PHP  [Auswählen]

"ALTER TABLE " . $table . " COLLATE utf8_general_ci"

hinterherzuschicken ist allerdings klug, für den Fall, daß es bereits Inkonsistenzen in manchen Tabellen in der DB gibt. Es ist zwar nicht unbedingt nötig, verhindert aber, daß bei eventuellem Hinzufügen eines neuen Feldes als text, char oder varchar und Nichtangabe der Collation für das Feld Probleme entstehen können.

Gruß,
noRiddle

[womd]

Hi!

es geht um utf8_general_ci vs utf8_unicode_ci, falls wer sprachen ausserhalb des latin-sets verwendet.

bin gerade über ein statement gestolpert, dachte das lass ich euch mal hier:

You should never, ever use utf8_general_ci: it simply doesn’t work. It’s a throwback to the bad old days of ASCII stooopeeedity from fifty years ago. Unicode case-insensitive matching cannot be done without the foldcase map from the UCD. For example, “Σίσυφος” has three different sigmas in it; or how the lowercase of “TSCHüẞ” is “tschüβ”, but the uppercase of “tschüβ” is “TSCHÜSS”. You can be right, or you can be fast. Therefore you must use utf8_unicode_ci, because if you don’t care about correctness, then it’s trivial to make it infinitely fast.

von hier:
http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci

greetz

[Bonsai]

Das betrifft ja nur die Sortierung ... Das eigentliche Problem beim Suchen in der Datenbank nach Wörtern mit ß löst das auch nicht.

Ich habe Bücher mit dem Wort "groß" im Titel und Bücher mit "gross" im Titel. Je nach Sturkopf der Verleger verwenden diese noch die alte Rechtschreibung, oder das Buch ist schon älter.

Aber danke für die Erinnerung! Da wollte ich mal was umbauen ......
Jedes Suchwort mit ss umbauen auf ß und auch danach suchen, und jedes Wort mit ß auf ss umbauen und nochmal suchen.

[womd]

... hatte das eigentlich eher generell zum UTF-8 - thema gemeint, zb: wenn wer den shop auch in russich, schlitzi o.ä betreibt... mal zum nachdenken wo sich das überall auswirkt, ev auch auf die suche ...., das zieht sich ja durch von der datenbank über php bis zum encoding dann im html, , wenn's besser wär ev in die utf-8 convert anleitung aufnehmen, dein spezifisches problem hatte ich noch nicht im auge....,

Jedes Suchwort mit ss umbauen auf ß und auch danach suchen, und jedes Wort mit ß auf ss umbauen und nochmal suchen.

aber wenn du da so am hacken bist, ev so:

Jedes Suchwort mit ss oder ß auf % in der myslq-query, umbaun und  nur 1x suchen

greetz

[Morgenstund]

Ich habe Bücher mit dem Wort "groß" im Titel und Bücher mit "gross" im Titel. Je nach Sturkopf der Verleger verwenden diese noch die alte Rechtschreibung, oder das Buch ist schon älter.

Halb off topic: "Groß" mit sz ist nach wie vor völlig richtig - nach einem langen Vokal kommt ein sz. Hat also in diesem Fall nix mit verlegerischer Sturheit zu tun.

[noRiddle (revilonetz)]

... hatte das eigentlich eher generell zum UTF-8 - thema gemeint, zb: wenn wer den shop auch in russich, schlitzi o.ä betreibt... mal zum nachdenken wo sich das überall auswirkt, ev auch auf die suche ...., das zieht sich ja durch von der datenbank über php bis zum encoding dann im html, , wenn's besser wär ev in die utf-8 convert anleitung aufnehmen, dein spezifisches problem hatte ich noch nicht im auge....,
...

Inwiefern soll sich die Collation, also die Sortierungsroutine für ORDER BY (und evtl. auch WHERE) mySQL-Befehle, auf das Encoding im HTML auswirken ?

Wer lediglich Deutsch und Englisch benutzt ist mit utf8_general_ci bestens bedient. Es muß halt jeder selbst schauen welche Sprachen er hat und was für ihn besser ist.
Bei einer generellen Beschreibung/Erklärung wie man den Standard-Shop (der ja in Deutsch und Englisch ausgelegt ist) auf UTF-8 umstellen kann ist das Setzen der Collation *_general_ci korrekt.

Den von dir verlinkten Stackoverflow-Thread hatte ich in vorliegendem Thread im übrigen bereits hier verlinkt.
Wenn man also der Meinung ist etwas Neues beitragen zu können sollte man den Thread vorher lesen um Redundanz zu vermeiden.

Wenn du genaue Beispiele hast wo *_unicode_ci oder gar die utf8mb4-Varianten sinnvoller wären, lass hören.
Ansonsten bleibt alles zu allgemein und ist wenig hilfreich.

Gruß,
noRiddle

[Mike Randoo]

Moin,
muss das Thema nochmal kurz aufgreifen, da ich gerade einen Testshop in UTF-8 und PHP5.6 erstellen will.
Habe es schon mehrere Male versucht, mit allen Tricks, die man im Forum findet, kriege aber die Umlaute z.B. in den Bundesländern wie Kärnten nicht weg.

• Kollation DB: Besser uft8_general_ci oder utf8_unicode_ci?
• Sollte man die Umlaute schon in der modified.sql korrigieren (z.B. bei Bundesländern) oder erst nach Installtion des Shops?
• Wenn Shop auf UTF-8 eingestellt, dann in den Sprachdateien besser Umlaute als Entities benutzen?
• Sollte man die Änderungen in den Dateien xtc_db_connect.inc.php und class.phpmailer.php durchführen, auch wenn laut Wiki nich nötig.

Danke schon mal fürs Feedback!
Schönen Sonntag allerseits...

[Mike Randoo]

Bevor was falsch verstanden wird... In der DB und im Backend steht K‰rnten statt Kärnten.
Muss ich das händisch machen oder sollte das eigentlich schon alles richtig in der DB stehen, wenn die Umstellung auf UTF-8 richtig geklappt hat.

[Mike Randoo]

Bin schon einen Schritt weitergekommen. Bei mir scheint das Archivierungsprogramm des Mac die Umlaute schon falsch aus dem Zip geholt zu haben. Mit Stuffit Expander sind die Umlaute in der modified.sql richtig dargestellt. Sachen gibt's... 

Wäre schön, wenn noch jemand einen Kommentar zu den Punkten 1, 3 und 4 geben könnte. Interessiert ja manch anderen ggfs. auch, der neu gen UTF-8 gehen will.

[noRiddle (revilonetz)]

Ich hatte in diesem Post mal versucht eine Aufstellung zu machen was alles gemacht werden sollte bei der Unstellung auf UTF-8. Dabei bitte auch auf die Bemerkung zu setlocale() in den Sprachdateien achten.

Gruß,
noRiddle

[Mike Randoo]

Hallo noRiddle,

vielen Dank für die Antwort. Über den Beitrag war ich vorher auch schon drüber gestolpert Wenn man beim Fazit angelangt ist, drehts einem a weng, wie was wo jetzt 
Hab soweit alles beherzigt. Auch die Änderung in der class.inputfilter.php. Ist die Änderung bei neuaufgesetzten Shops überhaupt nötig?
Hänge nochmal einen Screenshot meiner DB-Abfrage an. Das sollte jetzt alles insgesamt passen, oder?
Finale Frage: 
Sollte man die Änderungen in den Dateien xtc_db_connect.inc.php und class.phpmailer.php durchführen, die laut Wiki nicht nötig sind?

Thanksssss

[noRiddle (revilonetz)]

Ich hatte meinen Beitrag nur bzgl. dessen verlinkt was nach
"Nötig ist also folgendes wenn man nachträglich auf UTF-8 umstellen möchte:"
kommt, und da wüßte ich nicht was einem da "a weng" drehen sollte.
Der Rest in dem Post ist der Beitrag zu einer Diskussion die für dich keine Bedeutung hat.

In xtc_db_connect.inc.php und class.phpmailer.php ist nichts zu ändern.

Was ist denn nun genau das Problem in deinem Shop ?
Testen kannst du doch selbst und wenn es ein Problem gibt, schildere dieses so genau wie möglich, dann werden wir da schon die Lösung zu finden.

Gruß,
noRiddle