|
Tja, das Spiel kennt so mancher, der die Themen
"UTF-8 MySQL PHP Apache" unter einen Hut bringen will...
Das Problem kennt so macher. Hier die Lösung:
Ihr wollt ist nicht utf8_encode()/ utf8_decode().
Ihr wollt mysql_query('set character set utf8;');
Viel Spass beim Lesen...
Was Ihr wollt ist nicht utf8_encode() und utf8_decode().
Alles, was Ihr wollt ist MySQL richtig konfigurieren... Ich betreibe meine Seiten parallel in Deutsch, Spanisch und Englisch.
Ich berteibe für meine Kunden Seiten parallel in Deutsch, Englisch, Russisch und Chinesisch.
Habe deswegen osCommerce auf utf-8 portiert.
Hat mich viel Zeit gekostet...
Nicht die Portierung an sich, sondern die Suche nach dem optimalen Weg.
Glaubt mir ein wenig.
Die Portierung von Joomla 1.0.12 auf utf8 hat mich dadurch nur wenige Stunden gekostet.
Frage: Jede Applikation muss, wenn Sie mehrsprachig ausgelegt sein soll, Themen wie Encoding und Character Sets berücksichtigen.
Antwort: Ja, aber nur soweit wie nötig. utf-8-Konvertierung im Source per individuellem Funktionsaufruf ist nur im Falle einer zwingenden höchst individuellen Konvertierung angebracht. Das ist praktisch sehr selten der Fall. und nur in begründeten Ausnahmesituationen angebracht. Normalerweise versaust Du Dir damit nur unnötig Deinen Sourcode.
Frage: Das habe ich per PHP versucht mit dem utf8_encode() zu berücksichtigen.
Antwort: Das ist aber der falsche Ansatz, weil du als Softwarelieferant gar nicht weisst, was für ein Format in der MySQL-DB deines Kunden steckt. DU kannst und solltest alle Optionen beherrschen. Der Fehler liegt in der Komplexität und im Verständniss. Das Problem ist die Vielschichtigkeit. "Wer" liefert "wann" und "warum" welches Ausgabeformat? Wie stellt man das xterm richtig ein? Von der DOS-Box wirst Du vermutlich kein uft8 erwarten können? "Wer" braucht "wann" und "warum" welches Eingabeformat? Was für einen Mist macht ein Tool wie M$-Access daraus und warum? Warum funktionieren mache Tools während andere nicht funktionieren?
Kann der Entwickler das überhaupt noch alles nachvollziehen, oder fängt er aus Verzweiflung irgendwann an, mittels utf-8-Experimenten in seinem eigenen Code zu stochern?
Frage: Ein anderes Problem ist, dass nicht jeder so mutig und seine Datenbank mit utf8 betreibt.
Antwort: Das hat aber wenig mit Mut zu tun, viemehr mit Angst und Unwissenheit. Ich halte Deine Aussage deshalb auch für aus der Luft gegriffen. Bei mir funktioniert das seit Jahren problemlos - und bei Millionen von "exotischen" Charset wie "russisch, chinesich, japanisch, hebrew" usw auch. Ich fürchte eher, Du machst denselben Denkfehler, wie die US-Amerikaner: "Die denken auch, sie wären das Zentrum der Welt."
Fakt ist: Nur M$-Access ist zu dumm als Client die UTF-8-Dateien darzustellen, jedes andere Tool macht das von Haus aus richtig. Deshalb musst du Deinen Code so verändern,
dass der PHP-Client im Apache mit unterschiedlichen Charsets connecten kann.
nur alleine utf-8 oder iso-latin* ist viel zu starr. Der Server kann unterschiedliche Charsets haben, der Client unterschiedliche brauchen.
MySQL macht die Konvertierung automatisch, wenn an ihm nach dem connect sagt, was man als Ergebnis braucht und haben will.
Mache eine Config-Variable, die leicht anzupassen ist.
Jeder dieser Werte ist auf meiner Installation möglich:
mysql> SHOW CHARACTER SET;
+----------+-----------------------------+---------------------+--------+
| Charset | Description | Default collation | Maxlen |
+----------+-----------------------------+---------------------+--------+
| big5 | Big5 Traditional Chinese | big5_chinese_ci | 2 |
| dec8 | DEC West European | dec8_swedish_ci | 1 |
| cp850 | DOS West European | cp850_general_ci | 1 |
| hp8 | HP West European | hp8_english_ci | 1 |
| koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1 |
| latin1 | cp1252 West European | latin1_swedish_ci | 1 |
| latin2 | ISO 8859-2 Central European | latin2_general_ci | 1 |
| swe7 | 7bit Swedish | swe7_swedish_ci | 1 |
| ascii | US ASCII | ascii_general_ci | 1 |
| ujis | EUC-JP Japanese | ujis_japanese_ci | 3 |
| sjis | Shift-JIS Japanese | sjis_japanese_ci | 2 |
| hebrew | ISO 8859-8 Hebrew | hebrew_general_ci | 1 |
| tis620 | TIS620 Thai | tis620_thai_ci | 1 |
| euckr | EUC-KR Korean | euckr_korean_ci | 2 |
| koi8u | KOI8-U Ukrainian | koi8u_general_ci | 1 |
| gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2 |
| greek | ISO 8859-7 Greek | greek_general_ci | 1 |
| cp1250 | Windows Central European | cp1250_general_ci | 1 |
| gbk | GBK Simplified Chinese | gbk_chinese_ci | 2 |
| latin5 | ISO 8859-9 Turkish | latin5_turkish_ci | 1 |
| armscii8 | ARMSCII-8 Armenian | armscii8_general_ci | 1 |
| utf8 | UTF-8 Unicode | utf8_general_ci | 3 |
| ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 |
| cp866 | DOS Russian | cp866_general_ci | 1 |
| keybcs2 | DOS Kamenicky Czech-Slovak | keybcs2_general_ci | 1 |
| macce | Mac Central European | macce_general_ci | 1 |
| macroman | Mac West European | macroman_general_ci | 1 |
| cp852 | DOS Central European | cp852_general_ci | 1 |
| latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1 |
| cp1251 | Windows Cyrillic | cp1251_general_ci | 1 |
| cp1256 | Windows Arabic | cp1256_general_ci | 1 |
| cp1257 | Windows Baltic | cp1257_general_ci | 1 |
| binary | Binary pseudo charset | binary | 1 |
| geostd8 | GEOSTD8 Georgian | geostd8_general_ci | 1 |
| cp932 | SJIS for Windows Japanese | cp932_japanese_ci | 2 |
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3 |
+----------+-----------------------------+---------------------+--------+
36 rows in set (0.00 sec)
Siehe auch http://dev.mysql.com/doc/refman/5.0/en/charset.html
Frage: Meine läuft z.B. auch auf iso-latin1. Hier
müsste ggf. eine Konvertierung stattfinden.
Antwort: Nein! Wenn die DB mit iso-latin tickt,
der Webserver aber mit utf-8, dann connecte einfach mit utf-8.
MySQL weiss was zu tun ist und liefert die richtigen Ergebnisse.
Frage: Ich glaube, dass dies die größten Ursachen sind. Denn aus Deutschland hat sich bezüglich der aktuellen Version noch niemand beschwert.
Antwort: Claro. Weil die auf iso-latin1 fixiert sind und folglich am allerwenigsten Probleme mit deiner unter iso-latin1 entwickelten Software haben. Was für ein Argument. Erinnert mich ein wenig an die Kalifornischen Firmen, die nicht über ihren 8-Bit Charset hinaus sehen können. Funktioniert ja schliesslich alles... Geht schon damit los, dass Joomla-1 kein utf-8 unterstützt. - Dasbei ist es so einfach.
Frage: Vor allem MySQL-DBs laufen in der Regel noch mit iso-latin.
Antwort: Darauf mag ich nicht noch einmal eingehen. Dein Freund heisst:
mysql_query('set character set utf8;');
Mit dem Kommando sagt php der MySQL-DB, dass Apache als Ergebnis utf-8 bekommen will.
Das tatsächliche Format in der DB ist vollkommen irrelevant.
So einfach ist das... Wenn man weiss wie.
LG Ralph
Diese Beiträge könnten Dich ebenso interessieren:
|
