UFT-8 funktioniert nicht?!

[jenslm]

komischerweise werden Umlaute nicht angezegezeigt. Manchmal !!!
Denn die Seite hat charset=utf8
bei der ausgabe aus eine inkludierten Sprachdatei werden die Umlaute angezeigt. Bei Woertern auf der eignetlichen Seite allerdings nicht. Schaue ich mir den generierten Quelltext der eigentlichen Seite an steht hier aber utf-8. Warum werden die Umlaute nicht angezeigt?

lg, jens

[jenslm]

ok es scheint hieran zu liegen:

mysql_set_charset('utf-8' ,$database);  
$charset = mysql_client_encoding($database);  
  
echo $charset;

da kommt trotzdem latin-1 raus warum?!
lg, jens

[jenslm]

so jetzt muss ich hier aber mal n ernstes wort los werden...
wieso in gottes namen muss denn bitte bei mysql uft8 und bei html utf-8 verwendet werden. das is doch unnoetig...haette man sich auch einigen koennen.
hat sich erledigt, danke
lg, jens

[dedlfix]

Hi!

ok es scheint hieran zu liegen:

mysql_set_charset('utf-8' ,$database);

Dürfte einen Fehler liefern, den du durch Auswerten des Rückgabewertes hättest erkennen können und dessen Text du mit mysql_error() abfragen kannst.

$charset = mysql_client_encoding($database);
echo $charset;

> da kommt trotzdem latin-1 raus warum?!  
  
Glaub ich nicht, da kommt sicher latin1 (ohne Bindestrich!) raus.  
  
  
Lo!

[hotti]

hi,

da kommt trotzdem latin-1 raus warum?!

Das entzieht sich auch meiner Kenntnis, bei mir kommt da auch latin1 raus obwohl ich utf-8-codierte Zeichen in meinen Tabellen habe und auf charset-Deklarationen verzichte ;-)

Entscheidend ist der Inhalt Deiner Tabellen, ob Du die Char-Encodings deklarierst oder nicht, ist eine andere, eher pragmatische Angelegenheit. Wenn Du ein ordentlicher Mensch bist, taggst Du eine Tabelle mit utf-8, wenn utf-8 drin ist. Beachte, dass eine utf-8-Deklaration in mysql für ein Zeichen dreimal mehr Platz reserviert gegenüber einer latin1-Deklaration.

Hotti

[dedlfix]

Hi!

Entscheidend ist der Inhalt Deiner Tabellen, ob Du die Char-Encodings deklarierst oder nicht, ist eine andere, eher pragmatische Angelegenheit.

Eine ordentliche Konfiguration zu ignorieren empfiehlt sich nur, wenn man keinen Wert auf Sortierung und sonstige Stringverarbeitung seitens MySQL legt.

Wenn Du ein ordentlicher Mensch bist, taggst Du eine Tabelle mit utf-8, wenn utf-8 drin ist. Beachte, dass eine utf-8-Deklaration in mysql für ein Zeichen dreimal mehr Platz reserviert gegenüber einer latin1-Deklaration.

Es stimmt schon, dass ein UTF-8-Zeichen bis zu drei Byte benötigt. Die benötigt es aber auch, wenn du die bis zu drei Byte als Latin1 deklariert speichern lässt. Es werden stets nur so viel Byte belegt, wie das UTF-8-Zeichen lang ist (im VARCHAR-Feld). Es wäre unsinnig, drei Bytes zu reservieren, denn mit UCS2 existiert eine 2-Byte-Kodierung, mit der sich noch dazu einfacher arbeiten lässt. Die einzige Stelle, an der sich die 3 Bytes negativ bemerkbar machen ist bei der Länge von Indexen, die nach Byte gezählt nicht mehr als 1000 pro Zeile lang sein dürfen, und somit nur 333 Zeichen bei UTF-8.

Lo!

[hotti]

moin,

Entscheidend ist der Inhalt Deiner Tabellen, ob Du die Char-Encodings deklarierst oder nicht, ist eine andere, eher pragmatische Angelegenheit.

Eine ordentliche Konfiguration zu ignorieren empfiehlt sich nur, wenn man keinen Wert auf Sortierung und sonstige Stringverarbeitung seitens MySQL legt.

Ja, die Collation... Es kommt irgendwann immer der Moment, in dem festgestellt wird, dass die Default-Einstellungen eines Systems geändert werden müssen.

SELFHTML z.B. hat jahrelang die charset-Angabe im HTTP-Content-Type-Header auch irgnoriert und so hat sich das vermutlich auch auf tausende SELFER übertragen, mich nicht ausgernommen.

Kill me ;-)

Horst

[dedlfix]

Hi!

Eine ordentliche Konfiguration zu ignorieren empfiehlt sich nur, wenn man keinen Wert auf Sortierung und sonstige Stringverarbeitung seitens MySQL legt.
Ja, die Collation... Es kommt irgendwann immer der Moment, in dem festgestellt wird, dass die Default-Einstellungen eines Systems geändert werden müssen.

Die genauen Sortier-Regeln sind nochmal ein anderes Thema. Die Grundlage für ein Sortiern (nach welchen Regeln auch immer) oder der Stringverarbeitung ist, dass überhaupt die Zeichen als solche richtig erkannt werden. Es nützt nichts, die Felder auf Latin1 stehen zu haben (ebenso die Verbindungskodierung), die Daten UTF-8-kodiert zu senden und sie genauso beim Lesen zu interpretieren - und das funktioniert auch augenscheinlich wunderbar -, MySQL muss die Kodierung genau kennen, damit es richtig arbeiten kann. Mehr noch, es gibt verschiedene Tools, die die Kodierung auf ihren DBMS-Verbindungen stets korrekt aushandeln. Da kommt es dann zu Diskrepanzen. Insofern ist es im Prinzip keine Kür, die Kodierungen richtig zu konfigurieren, weil man vielleicht grad nichts besseres zu tun hat, sondern wichtig für die Datenintegrität. Es sind ja im Grunde genommen nur zwei Dinge, die zu beachten sind: die Feldkodierung und die Aushandlung nach dem Connect.

SELFHTML z.B. hat jahrelang die charset-Angabe im HTTP-Content-Type-Header auch irgnoriert und so hat sich das vermutlich auch auf tausende SELFER übertragen, mich nicht ausgernommen.

Dass andere aus Unwissenheit etwas versäumen sollte kein Grund sein, den gleichen Fehler zu wiederholen. Solange man von ISO-8859-1 als Standardkodierung ausging, ist das nicht weiter tragisch, aber der Wunsch nach UTF-8 und die langsame Verbreitung, erfordert ein Grundwissen (bei denen, die sich mit dem System beschäftigen).

Lo!

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Es stimmt schon, dass ein UTF-8-Zeichen bis zu drei Byte benötigt.

Stimmt schon nicht. Es können bis zu vier sein.

Und was soll überhaupt ein „UTF-8-Zeichen“ sein?

Qapla'

[dedlfix]

Hi!

Es stimmt schon, dass ein UTF-8-Zeichen bis zu drei Byte benötigt.
Stimmt schon nicht. Es können bis zu vier sein.

Im Zusammenhang mit MySQL sind es nur drei, denn MySQL unterstützt nur die BMP.

Und was soll überhaupt ein „UTF-8-Zeichen“ sein?

Naja, das kann man schon als „UTF-8-kodiertes Zeichen“ lesen, wenn man sich Mühe gibt :-)

Lo!

[hotti]

hi,

da kommt trotzdem latin-1 raus warum?!

Das entzieht sich auch meiner Kenntnis,

Mensch bin ich blöd ;-)

Ja, ne, is klar, dieser Wert ist in der my.ini festgelegt. Ich hatte noch eine uralte (deaktivierte) mysql-Installation und eine noch ältere my.ini auf meinem Rechner rumschwirren, da stand diese Hausnummer nicht drin.

Also, my.ini:

The default character set that will be used when a new schema or table is

created and no character set is defined

default-character-set=latin1

Now is setting to:
default-character-set=utf8

Viele Grüße an Alle,
Horst Schlumpi