Problem mit Character Sets

**Kropff** · 25-10-2006, 15:36

MySQL läuft auf auf einer Debian Sarge Kiste

dann ist das wohl noch eine 4.0 version, die kann das nocht nicht. erst ab 4.1 oder 5.0 läuft das mit character sets

gruß
peter

**mrhappiness** · 25-10-2006, 15:36

SHOW CHARACTER SET gibt es seit Version 4.1.0.

Welche Version setzt du ein?

**Slava** · 25-10-2006, 15:59

ein mal für immer!
wenn du mit mehreren Sprachen arbeiten willst nur utf-8 benutzen.
dabei spielt charset von db bei einer php-Anwendung kaum eine rolle.
bei älteren mysql versionen muss man aber auf die länge von felder aufpassen, da für darschtellung von einer Kyrilischer Buchstabe etwa 4 lataeinischen rein passen.

**avo** · 25-10-2006, 16:20

Ok, dann habe ich noch 'ne ältere Version (4.0). Kein Wunder, dass es nicht funktioniert hat.

Original geschrieben von Slava
dabei spielt charset von db bei einer php-Anwendung kaum eine rolle.

Wie darf ich das jetzt verstehen? Wenn ich mit PHP einen Text utf-8 kodiere ist es egal wenn die DB z.B. den Latin1-Zeichensatz hat? Oder meintest du, dass es egal ist wenn die DB utf-8 hat?

**Abraxax** · 25-10-2006, 16:26

ersteres ....

**Slava** · 25-10-2006, 16:39

ja es wird auch mit Latin1 funktionieren.
wenn formulare in utf-8 gesendet sind und bei anzeige auch utf-8 verwendet wird, dann gibt es kein problem mit ausnahme von der länge von Strings.
Ä ist jetzt 2 zeichen lang.

PHP Code:


header('Content-Type: text/html; charset=utf-8');

$ding="Ð´Ñ„Ð³Ñ…Ñ…Ñ‚Ñ€ÐµÑ‹Ã„swÃ¼Ã¼Ã¶Ã–";//russische buchstaben

$str="Ã„";//Ä

echo "<html>";

echo $ding."<br />";

echo $str." ist ".strlen($str)." zeichen Lang ";

echo "</html>";

EDIT:
es ist aber utf-8 tabellen zu empfehlen, da sie extra für utf-8 ausgedacht sind.
mit PHP6 wird die sache noch leichter, da wir die ganze code in utf-8 erstellen können.

**wahsaga** · 25-10-2006, 17:06

Original geschrieben von Slava
ja es wird auch mit Latin1 funktionieren.
wenn formulare in utf-8 gesendet sind und bei anzeige auch utf-8 verwendet wird, dann gibt es kein problem mit ausnahme von der länge von Strings.

Na ja, wenn man mal von Sortierungen etc. absieht ...

**Slava** · 25-10-2006, 17:42

Original geschrieben von wahsaga
Na ja, wenn man mal von Sortierungen etc. absieht ...

mit sortirung gibt es eigentlich kein problem, da es eigentlich kein sinn hat japanische zeichen mit deutschen zu vergleichen.
die tabelle muss in utf-8 sein,
damit es ein japanische zeichen als "1" zeichen erkannt wird und nicht als 4 deutsche buschstaben,
damit die stringfunctionen, die zeichenlängen brauchen wie z.b.s "left" die buchstaben und nicht bytes zählt .

edit: dabei habe ich vergessen, dass ein japanische zeihen nicht unbedingt eine Buchstabe ist, sondern kann auch ein ganzes satz bedeuten

**ghostgambler** · 25-10-2006, 19:02

Original geschrieben von Slava
mit sortirung gibt es eigentlich kein problem, da es eigentlich kein sinn hat japanische zeichen mit deutschen zu vergleichen.
die tabelle muss in utf-8 sein,
damit es ein japanische zeichen als "1" zeichen erkannt wird und nicht als 4 deutsche buschstaben,
damit die stringfunctionen, die zeichenlängen brauchen wie z.b.s "left" die buchstaben und nicht bytes zählt .

edit: dabei habe ich vergessen, dass ein japanische zeihen nicht unbedingt eine Buchstabe ist, sondern kann auch ein ganzes satz bedeuten

Es ist vollkommener Schwachsinn dem DBMS vorzugaukeln, dass die Daten einen anderen Zeichensatz haben, als sie eigentlich haben.
Sowas führt spätestens bei der Wiederverwertung der Daten durch einen anderen, vernünftig programmierten, Client zu Problemen, die man *dann* aufgrund der schon vorhandenen, ggf. großen, Datenmenge nur noch durch weitere hässliche workarounds umgehen kann.

Vor MySQL 4.1 blieb einem leider nichts anderes übrig als die Daten utf8-kodiert in die latin1 Datenbank zu schreiben, seit der eben genannten Version kann man allerdings angeben welchen Zeichensatz die Daten haben und soll das auch in Gottes Namen bitte korrekt tun. Ansonsten kann man sein Projekt eigentlich auch gleich im Papierkorb speichern...

Und @php6
Man kann auch jetzt schon seinen php Code mit UTF8 speichern, mache ich, machen viele andere auch schon.
PHP ignoriert einfach jede Art von Mehrbyte-Zeichen, deshalb ist es ja überhaupt möglich jetzt zum Beispiel schon UTF8 zu verwenden.

Der Unterschied, bzw. die Änderung, umfasst die Beachtung des aktuellen Zeichensatzes durch PHP um dem Programmierer einige Probleme abzunehmen; z.B. Einfacher Vergleich von Strings, keine gesonderten Funktionen mehr, Anpassen der Ausgabe von Text vom Zeichensatz der Datei an den Zeichensatz des Outputs, ... weiteres findet sich auf http://www.zend.com/zend/week/php-unicode-design.txt
Generell ändert das nichts daran, dass man die Zeichenkodierung der Verbindung korrekt einstellen muss; Änderungen sind in Hinsicht der Datenbankschnittstelle aber wohl eher nicht zu erwarten, demnach hat das absolut nichts mit dem Thema zutun.

**wahsaga** · 25-10-2006, 19:31

Original geschrieben von Slava
mit sortirung gibt es eigentlich kein problem

Doch, gibt es.

Ein ä in UTF-8, als Latin-1 abgespeichert sieht so aus: Ã¤
Wenn du das jetzt einsortieren willst, kannst du nicht erwarten dass dieses ä zwsichen a und b einsortiert wird - weil Ã¤ eben "größer" als a und größer als b ist.

die tabelle muss in utf-8 sein,

Natürlich, dann gibt es kein Problem.

Aber vorher war doch vom anderen Fall die Rede - dass die DB eben noch kein UTF-8 unterstützt, und man deshalb eben UTF-8 kodierte Daten als Latin-1 o.ä. ablegt.

**Slava** · 25-10-2006, 20:14

1) nach kurzem überlegen, nehme ich die Aussage
dabei spielt charset von db bei einer php-Anwendung kaum eine rolle.
zurück.
die verschiedene Kollation von utf-8 bei mysql sind auch dafür gemacht worden um die sortierung und andere Sprachen-spezifische Funktionalitäten zu ermöglichen.
wenn aber in der Tabelle mit kollation utf8_swedish_ci auf ein mal ein paar chinesische wörter rein kommen, dann gibt es leider fast die gleiche probleme wie bei latain_1 tabellen.

OffTopic:
wann kommt endlich der Tag als ASCII für immer begraben wird?
char muss langsam in char32 für immer umwandeln

Problem mit Character Sets