[gelöst] Zeichensatz der MySQL-Datenbank

guklplatzwart · 27 Jan. 2012

Hallo @all.

Nach mehrmaligem bemühen der SuFu mit den Begriffen ->Zeichensatz, character-set<- bin ich in diesem Forum nicht zu einer Antwort auf meine Frage gekommen. Auch verschiedenartige nachfragen bei Google brachten mich nicht auf den Pfad der Erkenntnis. Dabei ist die Frage im ersten Moment ganz einfach:

Wie bekomme ich ein "ü" auch als ein "ü" in eine MySQL-Datenbank?

OK - fangen wir also vorne an. Die Umgebung der Datenbank sieht folgendermaßen aus:
SUSE 11.3 - MySQL 5.1.57 - Apache 2.2.15 - PHP 5.3.3 - Standard runlevel 3

Was soll passieren:
Der Eintrag aus einem Texteingabefeld einer Weboberfläche (textarea) soll in die Datenbank geschrieben werden. Da später eine Abfrage per $_GET erfolgt, brauche ich eben einen Umlaut auch als Umlaut in der Datenbank und nicht als htmlentities. Das es geht zeigt mir die Datenbankverwaltung auf diversen Webspaces. Nur auf meiner lokalen Maschine will das nicht funktionieren.

Mein Browser verwendet die Standard-Zeichenkodierung iso-8859-1. Der meta-tag im html-Dokument wird angegeben mit content="text/html; charset=iso-8859-1". Die Kollation der Datenbank-Tabellen ist latin1_german1_ci. Auch sind die Datenbank-Felder, welche nicht integer sind, alle latin1_german1_ci. Bei diesen Rahmenbedingungen gelingt es mir nicht einen Umlaut in die Datenbank zu bekommen. Ein Fragezeichen (?) nimmt den Platz des Umlauts ein.

Lösungsversuche:
Der PMA zeigt mir an, dass der MySQL-Zeichensatz utf8 ist. Folglich habe ich mir gedacht, dass der MySQL-Zeichensatz in der Konfigurationsdatei (/etc/my.cnf) zu ändern/einzutragen sei. Hier brachte die Google-Suche erfolg, indem ich erfuhr welcher Eintrag wie lauten muß und wo er hingehört. Dabei habe ich verschiedene Varianten ausprobiert (mal das eine kommentiert, mal was anderes kommentiert). Hier mal ein Ausschnitt aus der my.cnf im kommentierten zustand:

Code:

[client]
#password	= your_password
port		= 3306
socket		= /var/run/mysql/mysql.sock
#default-character-set = latin1 

[mysqld]
port		= 3306
socket		= /var/run/mysql/mysql.sock
# Change following line if you want to store your database elsewhere
datadir	= /var/lib/mysql
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
#default-character-set = latin1
#collation-server = latin1
#init-connect='SET NAMES latin1_german1_ci'
#character-set-server = latin1 

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
#default-character-set=latin1

Dabei hatte ein editieren der my.cnf (als root) grundsätzlich immer ein nicht neustarten der Datenbank zur folge.

Nachdem das also misslungen war habe ich nochmal hier im Forum nachgeschaut und dabei folgenden Satz gelesen: "Nimm einfach UTF-8 und gut ist. Dann können die Einträge auch Klingonisch sein

."

Also hab ich mich an die Arbeit gemacht und alles auf utf8 umgestellt (den Browser, das html-Dokument und die Kollationen der Datenbank). Aber auch das brachte keinen Erfolg. Schlimmer noch: Der Umlaut und sämtliche folgenden Zeichen wurden nun gar nicht mehr berücksichtigt.

In der Konsole habe ich dann auch mal folgendes eingegeben: mysql --default-character-set=latin1
Die Kontrolle haben ich mit folgendem Befehel gemacht:

Code:

mysql> show variables like "%character%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Nach Abmeldung und Neuanmeldung an MySQL habe ich dann nochmal eine Kotrolle gemacht.

Code:

mysql> show variables like "%character%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Also ist die Konsoleneingabe: mysql --default-character-set=latin1 nur temporär gültig.

Auch die Lektüre der MySQL-Dokumentation brachte mich nicht wirklich weiter. Dort werden zwar die Optionsdateien (Konfigurationsdateien) zu den verschiedenen Systemen (Unix/Win) behandelt, aber einen Lösungsansatz konnte ich dort nicht entdecken.

Erwähnen möchte ich noch, dass auch einfache Textdateien auf Win geschrieben in der Linuxkonsole keine Umlaute anzeigen. Auch wenn ich vesuche in der Konsole in diese Textdateien Umlaute rein zu schreiben geschieht nichts. Dabei wird das deutsche Tastaturlayout (qwertz) benutzt.

Vielleicht ist hier jemand so wissend und kann mir den Pfad der Erkentnis zeigen.

Sollte es sich allerdings um ein wohl gehütetes Geheimnis der Webhoster handeln, welches sie nach Möglichkeit nicht preisgeben wollen, werde ich wohl nicht drum herum kommen sämtliche Umlauteinträge per PMA zu erledigen. (Der kann das. Warum auch immer?)

Vielen Dank fürs lesen und sollte jemand einen Lösungsansatz haben wäre ich ihm wirklich dankbar.

MfG
guklplatzwart

abgdf · 27 Jan. 2012

Yast2 als root -> System -> Sprache wählen -> Primäre Sprache "Deutsch" -> Details: Haken bei "UTF-8 als Kodierung verwenden" löschen. Ggf. reboot.
Besser?

guklplatzwart · 27 Jan. 2012

Hallo abdgf.

Dein Lösungsansatz

abgdf schrieb:
Yast2 als root -> System -> Sprache wählen -> Primäre Sprache "Deutsch" -> Details: Haken bei "UTF-8 als Kodierung verwenden" löschen. Ggf. reboot.
Besser?

hat mich schonmal weitergebracht. Vielen Dank dafür.

Nachdem ich das also erledigt habe, konnte ich folgende Veränderungen festellen:
Die rudimentäre GUI von Yast wird mir nun in deutsch und korekt dargestellt (bezogen auf die Umlaute). Auch eine geöffnete Textdatei wird in der Konsole nun korekt gezeigt. Ich kann sogar Umlaute hinzufügen.

Als nächstes habe ich die my.cnf einfach mal folgendermaßen editeiert:

Code:

    [client]
    #password   = your_password
    port      = 3306
    socket      = /var/run/mysql/mysql.sock
    default-character-set = latin1

    [mysqld]
    port      = 3306
    socket      = /var/run/mysql/mysql.sock
    # Change following line if you want to store your database elsewhere
    datadir   = /var/lib/mysql
    skip-external-locking
    key_buffer_size = 16M
    max_allowed_packet = 1M
    table_open_cache = 64
    sort_buffer_size = 512K
    net_buffer_length = 8K
    read_buffer_size = 256K
    read_rnd_buffer_size = 512K
    myisam_sort_buffer_size = 8M
    default-character-set = latin1
    #collation-server = latin1
    #init-connect='SET NAMES latin1_german1_ci'
    #character-set-server = latin1

    [mysql]
    no-auto-rehash
    # Remove the next comment character if you are not familiar with SQL
    #safe-updates
    default-character-set=latin1

Mit ->/etc/init.d/mysql restart habe ich den MySQL neu gestartet. Hurra - er startet auf einmal sogar neu. *tierisch freu* Die anschließende Kontrolle brachte folgendes Ergebnis:

Code:

mysql> show variables like "%character%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Der PMA zeigt mir allerdings immernoch den MySQL-Zeichensatz mit utf8 an. Trotzdem habe ich mal versucht über die Weboberfläche einen Texteintrag mit einem Umlaut zu machen. Vorher habe ich natürlich alles auf iso-8859-1 bzw. latin1_german1_ci umgestellt. Leider werden mir Umalute immernoch durch ein Fragezeichen ersetzt.

Aber zumindest gibt es schonmal einen Fortschritt zu vermelden. In der my.cnf kann ich nun auch andere Zeichensätze als utf8 angeben und der Dienst wird auch neu gestartet. Also muss ich wohl irgendwo noch einen kleinen Schalter umlegen der dies bewerkstelligt. Hat jemand eine Idee wo der sein könnte?

MfG
guklplatzwart

panamajo · 27 Jan. 2012

abgdf schrieb:
Haken bei "UTF-8 als Kodierung verwenden" löschen.

Das Default Encoding des Systems beeindruckt MySQL genau gar nicht.
EDIT: Ok das Problem dass die Darstellung auf dem Linux Gerät grundsätzlich komisch ist hatte ich da noch nicht erfasst

panamajo · 27 Jan. 2012

guklplatzwart schrieb:
Mein Browser verwendet die Standard-Zeichenkodierung iso-8859-1. Der meta-tag im html-Dokument wird angegeben mit content="text/html; charset=iso-8859-1".

Das sind ja alles nur Hinweise für den Client wie Content darzustellen ist, aber wenigstens kann man davon ausgehen dass Daten die per HTTP POST an den Server geschickt werden im iso-8859-1 Encoding ankommen.

guklplatzwart schrieb:
Die Kollation der Datenbank-Tabellen ist latin1_german1_ci.

Die Kollation ist lediglich Metainformation wie Felder sortiert werden sollen. Das Ändern der Kollation verändert Feldinhalte nicht sondern eben nur deren Interpretation.

guklplatzwart schrieb:
Auch sind die Datenbank-Felder, welche nicht integer sind, alle latin1_german1_ci. Bei diesen Rahmenbedingungen gelingt es mir nicht einen Umlaut in die Datenbank zu bekommen. Ein Fragezeichen (?) nimmt den Platz des Umlauts ein.

Diese ? siehst du wo, im PMA oder in der MySQL Konsole?

guklplatzwart schrieb:
Lösungsversuche:
Der PMA zeigt mir an, dass der MySQL-Zeichensatz utf8 ist. Folglich habe ich mir gedacht, dass der MySQL-Zeichensatz in der Konfigurationsdatei (/etc/my.cnf) zu ändern/einzutragen sei.

Dort können u.a. die Defaults eingetragen werden. Trotzdem können mehrere unterschiedliche Zeichensätze verwendet werden, bis hinunter auf einzelne Felder (was wenig Sinn ergibt).

guklplatzwart schrieb:
Dabei hatte ein editieren der my.cnf (als root) grundsätzlich immer ein nicht neustarten der Datenbank zur folge.

Das ist normal, MySQL weiss ja nicht ob du mit dem Ändern der Konfiguration fertig bist. Wenn es soweit ist kannst du MySQL mit

Code:

rcmysql reload

Bescheid geben, dann wird die Konfiguration neu eingelesen. Es gibt jedoch ein paar Einstellungen die ein

Code:

rcmysql restart

erfordern.

guklplatzwart schrieb:
Nachdem das also misslungen war habe ich nochmal hier im Forum nachgeschaut und dabei folgenden Satz gelesen: "Nimm einfach UTF-8 und gut ist. Dann können die Einträge auch Klingonisch sein ."

Das ist insofern richtig als dass UTF-8 ab MySQL 5.1 der Default ist. Wenn Client und Server beide UTF-8 verwenden gibt es keine Probleme. Ansonsten muss man sich einigen (s.u.)

guklplatzwart schrieb:
Also hab ich mich an die Arbeit gemacht und alles auf utf8 umgestellt (den Browser, das html-Dokument und die Kollationen der Datenbank). Aber auch das brachte keinen Erfolg. Schlimmer noch: Der Umlaut und sämtliche folgenden Zeichen wurden nun gar nicht mehr berücksichtigt.

[...]

Code:

mysql> show variables like "%character%"; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+

Also wenn du bis hierher tatsächlich alles auf UTF-8 umgestellt hast bist du mit diesen Werten doch auf der sicheren Seite. Vmtl. sind die u.g. Darstellungsprobleme der Grund dass Umlaute nicht korrekt dargestellt werden.

guklplatzwart schrieb:
Also ist die Konsoleneingabe: mysql --default-character-set=latin1 nur temporär gültig.

Korrekt. Du gibst damit dem MySQL Client mit für diese Sitzung latin1 als Default zu nehmen. Das beeinflusst andere Clients genau gar nicht.

guklplatzwart schrieb:
Erwähnen möchte ich noch, dass auch einfache Textdateien auf Win geschrieben in der Linuxkonsole keine Umlaute anzeigen. Auch wenn ich vesuche in der Konsole in diese Textdateien Umlaute rein zu schreiben geschieht nichts.

Das erschwert die Fehlersuche erheblich. Welches Encoding haben diese Dokumente? Mit welchem Encoding arbeitet die Linux Kiste?

guklplatzwart schrieb:
sämtliche Umlauteinträge per PMA zu erledigen. (Der kann das. Warum auch immer?)

Am einfachsten löst man solche Probleme indem man direkt nach dem Connect zum MySQL Server das Encoding explizit setzt:

Code:

SET NAMES 'utf8'

für UTF-8

Code:

SET NAMES 'latin1'

für iso-8859-1

guklplatzwart · 27 Jan. 2012

Hallöchen.

Vielen Dank an @abgdf und @panamajo. Eure Hinweise haben mich zur Lösung geführt.

abgdf schrieb:
Yast2 als root -> System -> Sprache wählen -> Primäre Sprache "Deutsch" -> Details: Haken bei "UTF-8 als Kodierung verwenden" löschen. Ggf. reboot.
Besser?

Wie weiter oben schon beschrieben konnte ich dadurch Win/ANSI Dokumente nun korekt lesen und auch Umlaute hinzufügen. Ebenso hatten sich Darstellungsprobleme in Luft aufgelöst. Viel wichtiger war jedoch, dass ich nun die my.cnf editieren konnte ohne vergeblich auf den Neustart des MySQL zu warten. In die my.cnf konnte ich nun auch andere Zeichensätze als utf8 eintragen. Hier gehe ich davon aus, dass das gesamte System nun auch andere Zeichensätze verarbeiten konnte als nur utf8.

Das editieren der my.cnf führte (wie gewünscht) zu anderen Laufzeitvariablen (s. Post Nr.:3). Da ich annehme, dass MySQL bei der Verbindung über die Weboberfläche von einer utf8-Verbindung ausgegangen ist, ergab sich ein Zeichen wirr warr. Erst

panamajo schrieb:
Am einfachsten löst man solche Probleme indem man direkt nach dem Connect zum MySQL Server das Encoding explizit setzt:

Code:

SET NAMES 'latin1'

für iso-8859-1

brachte das gewünschte Ergebnis. Auf meiner lokalen Maschine funktioniert jetzt der Datentransfer wie gewünscht.

Jetzt bekomme ich auch ein "ü" als ein "ü" in die Datenbank und kann es auch als "ü" auslesen! Insofern kann der Thread als gelöst betrachtet werden.
Lediglich die Frage: Wie machen die Webhoster das ohne die explizite Anweisung von ->"SET NAMES '$zeichensatz'"; ? ? Aber das wird wohl noch lange deren Geheimnis bleiben - schätze ich mal.

Vielen Dank nochmal für das Lotsen auf "den Pfad der Erkentnis".

MfG
guklplatzwart

panamajo · 27 Jan. 2012

guklplatzwart schrieb:
Lediglich die Frage: Wie machen die Webhoster das ohne die explizite Anweisung von ->"SET NAMES '$zeichensatz'"; ?

Webhoster machen da gar nichts, idR. ist auch gar nichts nötig.

Fehlt die explizite Angabe des Encodings nimmt MySQL die Default Werte. Bis MySQL 5.0 war dies Latin1, ab 5.1 UTF-8. Wobei man beachten sollte dass MySQL entsprechend seiner Konfiguration implizit alle Feldinhalte umwandelt.

Es war z.B. ein weit verbreiteter Irrtum dass man bei MySQL 4.1 oder 5.0 beim Anlegen einer neuen Datenbank die Kollation auf utf8_irgendwas setzt und damit sei dann alles in UTF-8.
Tatsächlich ist in diesem Fall character_set_client weiter latin1. Schickt man jetzt UTF-8 Daten über eine Verbindung (man hat die Website ja brav in UTF-8 encodet) denkt sich MySQL: Ok, Latin1 Daten, die Tabelle ist als UTF-8 gekennzeichnet, also schnell umcodieren. So erhält man in der DB UTF-8 encodetes UTF-8. Und merkt es nicht, da beim Lesen der Daten dieselbe Umwandlung dazu führt dass wieder valides UTF-8 ankommt.

abgdf · 27 Jan. 2012

panamajo schrieb:
abgdf schrieb:

Haken bei "UTF-8 als Kodierung verwenden" löschen.

Zum Vergrößern anklicken....

Das Default Encoding des Systems beeindruckt MySQL genau gar nicht.

Ich bin immer noch auf SuSE 10.0 unterwegs und hab' eben wie beschrieben Latin1 als Standard-Encoding. Um mir hier das Problem anzugucken, hab' ich MySQL installiert und konnte dort direkt Umlaute verarbeiten. Ausgabe ist ohne Antasten von /etc/my.cnf:

Code:

mysql> show variables like "%character%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.05 sec)

Daraufhin schien es mir, daß er wohl bei der MySQL-Installation das Standard-Encoding des Systems automatisch übernommen haben müßte. Jetzt schreibst Du:

panamajo schrieb:
Fehlt die explizite Angabe des Encodings nimmt MySQL die Default Werte. Bis MySQL 5.0 war dies Latin1, ab 5.1 UTF-8.

Das kann es allerdings auch gewesen sein, denn mein MySQL ist noch 4.1.13. So gut kenne ich mich mit MySQL dann wieder auch nicht aus.
Ganz praktisch ist noch der Befehl "recode":

Code:

recode UTF-8..ISO-8859-1 datei

wandelt eine Textdatei von utf-8 nach latin1,

Code:

recode CP1252/CR-LF..ISO-8859-1 datei

vom Windows-typischen Format nach latin1 (Linux), meist reichen dafür aber schon die Befehle "dos2unix" und "unix2dos".
Aber generell können diese Encodings immer wieder Probleme bereiten, auf die man meist überhaupt keine Lust hat.
Freut mich also, daß die Datenbank von guklplatzwart nun ganz gut läuft. Und diesen "geheimen UTF-8-Haken" in YaST zu entfernen, ist, wenn man standardmäßig in Latin1 arbeitet, sicher immer eine gute Idee.

panamajo · 27 Jan. 2012

abgdf schrieb:
Aber generell können diese Encodings immer wieder Probleme bereiten, auf die man meist überhaupt keine Lust hat.

Deshalb ja auch die Tendenz für alles UTF-8 zu verwenden. Da dort alle anderen Zeichensätze abgebildet werden können muss man sich nicht mit anderen Encodings rumschlagen. Und Probleme hat man nur wenn Encoding als Plural vorkommt.

guklplatzwart · 28 Jan. 2012

@panamajo und @abgdf - Um ein wenig Licht in die Sache zu bringen: Bei meinem Problem geht es eigentlich um die Darstellung der deutschen Sonderzeichen unter utf-8.

Also fangen wir auch hier wieder vorne an:
Meine Erfahrungswerte sagen mir das ein html-Dokument mit ->content="text/html; charset=UTF-8" immer mit einem Restrisiko behaftet ist, dass ein deutsches Sonderzeichen nicht als lesbares deutsches Sonderzeichen dargestellt wird. Sondern das ein Fragezeichen oder utf-8 Doppelbit oder auch noch was anderes erscheint. Diesem Restrisiko kann man mit ->content="text/html; charset=iso-8852-1" begegnen. In diesem Fall wird ein Sonderzeichen, welches nicht als htmlentities beschrieben wird, auch als lesbares Sonderzeichen dargestellt. Das es schlussendlich auch mit utf-8 möglich ist ist mir bekannt. Trotzdem besteht immer ein Restrisiko.

Wie ich in meinem Eröffnungspost bereits beschrieben habe ist auf diversen Webspaces dieses Problem nicht vorhanden. Dort steht ein "ü" auch als "ü" (mit PMA geprüft) in der Datenbank und wird auch als "ü" von dort ausgelesen. Wie das dort funktioniert ist mir in letzter Konsequenz eigentlich egal solange ich mit der westlichen Zeichenkodierung (im html-Dokument) das Restrisiko vermeide. Lediglich auf meiner lokalen Maschine wollte genau das überhaupt nicht funktionieren.

Bisher habe ich auf meiner lokalen Maschine dieses Problem entweder über den PMA oder per htmlentities umgangen. Denn die Anzahl der Einträge in die Datenbank hielten sich dabei bisher in ganz engen Grenzen. Aktuell habe ich jedoch ein Webprojekt zu betreuen, wo diese Grenzen erheblich gesprengt werden. Und da ich mich nun mal (auf Grund der Erfahrungswerte) für den westlichen Zeichensatz entschieden habe, habe ich nach einer Lösung gesucht, die es mir erlaubt diesen Zeichensatz vollumfänglich zu verwenden - auch und gerade in der Datenbank.

Ich möchte hier jedoch keine Diskusion über Zeichensätze in html-Dokumente lostreten. Sollte dazu bedarf bestehen läst sich das bestimmt in einem anderen Forum erledigen. Hier geht es um MySQL.

Nochmals vielen Dank an @panamajo und @abgdf für die Beiträge zur Problemösung.

MfG
guklplatzwart

panamajo · 28 Jan. 2012

guklplatzwart schrieb:
Meine Erfahrungswerte sagen mir das ein html-Dokument mit ->content="text/html; charset=UTF-8" immer mit einem Restrisiko behaftet ist, dass ein deutsches Sonderzeichen nicht als lesbares deutsches Sonderzeichen dargestellt wird. Sondern das ein Fragezeichen oder utf-8 Doppelbit oder auch noch was anderes erscheint. Diesem Restrisiko kann man mit ->content="text/html; charset=iso-8852-1" begegnen. In diesem Fall wird ein Sonderzeichen, welches nicht als htmlentities beschrieben wird, auch als lesbares Sonderzeichen dargestellt. Das es schlussendlich auch mit utf-8 möglich ist ist mir bekannt. Trotzdem besteht immer ein Restrisiko.

Sry aber das ist Quatsch. Wir reden hier von determinitischen Algorithmen, sowas wie ein "Restrisiko" gibts da nicht.
Nenn mir eine URL bei der die von dir beschriebene fehlerhafte Darstellung trotz korrektem HTML zu beobachten ist.

abgdf · 28 Jan. 2012

Zu Encodings in Webseiten kann ich nicht viel sagen, außer, daß ich das im Browser manchmal umstellen muß, weil die Darstellung einfach nicht korrekt ist.
Aber was Du oben gesagt hast, mach' einfach alles in UTF-8, das kann alles darstellen, dann gibt's nirgendwo Probleme, deckt sich auch nicht mit meiner Beobachtung. Das ist zwar theoretisch der Anspruch von UTF-8, nur so richtig geklappt hat das irgendwie noch nie.
Am wenigsten Probleme habe ich mit Latin1 (ISO 8859-1, siehe "man latin1"). Deutsche Umlaute sind damit kein Problem, Windows-Dateien auch nicht (es bleibt da nur die "dos2unix"-Geschichte). Deshalb stelle ich alles soweit wie möglich darauf ein und vermeide möglichst UTF-8 (auch wenn das überwiegend auch funktioniert, aber nur in sagen wir 3/4 der Fälle). So.

[gelöst] Zeichensatz der MySQL-Datenbank

guklplatzwart

Newbie

abgdf

Guru

guklplatzwart

Newbie

panamajo

Guru

panamajo

Guru

guklplatzwart

Newbie

panamajo

Guru

abgdf

Guru

panamajo

Guru

guklplatzwart

Newbie

panamajo

Guru

abgdf

Guru