Re: Deutsche Umlaute und UTF8

[Susanne Ebrecht]

Hallo,

ich kommentiere jetzt einfach inline:

f4ckm5@stripped schrieb:
>
> Hallo,
>
> in Ihrem Blogeintrag heißt es:
>
>> Unter Windows habt Ihr keine Chance das Encoding zu ändern. Bei 
>> deutschen Windows wird CP850 verwendet
> ...
>
> Diese Aussage ist falsch.
>
> # Codepage der Eingabeaufforderung abfragen (Windows XP deutsch SP3)
> C:\>chcp
> Aktive Codepage: 850.
>
> # Codepage der Eingabeaufforderung ändern (Windows XP deutsch SP3)
> C:\>chcp 1252
> Aktive Codepage: 1252.

Ja natürlich, man kann auch via chcp die Codepage unter Windows ändern. 
Dieser Schritt ist nur in 99% überflüssig. Wie unten erwähnt, geht es 
dabei lediglich um das Eurozeichen, was wohl doch eher selten benötigt 
wird. Kyrillische Schriftzeichen lassen sich auch damit nicht eingeben. 
Meine eigenen Versuche, es auf eine Codpage umzustellen, die sowohl 
West- als auch Osteuropäische Sprachen schlugen fehl. Theoretisch laut 
den Microsoft Seiten ist auch dieses möglich, praktisch funktionierte es 
nicht.

>
> Und schon ist die Codepage für die Konsole unter Windows auf 
> Windows-1252 entspr. im Groben ISO/IEC 8859-1  entspr. latin1 
> geändert. Dass Microsoft in Windows-1252 die Steuerzeichen zwischen 
> 0x80 und 0x9F für darstellbare Zeichen misbraucht hat, steht dabei auf 
> einem anderen Blatt. Jedenfalls kann man danach deutsche Umlaute und 
> sogar das Eurozeichen ohne Probleme über eine latin1 Clientverbindung 
> in latin1 Tabellen oder auch UTF8 Tabellen einfügen und auch korrekt 
> ausgeben lassen (Achtung: Rasterschrift vs. Lucida Console).

Das Eurozeichen ist ein generelles Problem. Unter Windows bekommt man es 
in die MySQL LATIN1 Spalte vernünftig hereingeprügelt, aber unter 
Unix/Linux bei der Verwendung von ISO-8859-15 nicht wieder heraus.
Das Eurozeichen lässt sich bei Verwendung von ISO-8859-15 auch nicht 
vernünftig einfügen.
ISO-8859-1 unterstützt kein Eurozeichen.

Für das Eurozeichen ist meine Empfehlung: Nehmt UTF8 für Eure Spalte. 
Einfach, weil damit bekommt Ihr es vernünftig überall hinein und heraus.

Da das MySQL LATIN1 kein Standard Latin1 ist, sondern eigentlich 
Codepage 1252 ist hier in der Unix/Linux Welt Vorsicht angebracht. Das 
Standard LATIN1 unterstützt ebenfalls kein Eurozeichen.

Der Zeichensatz mit Eurozeichen heisst LATIN9. Dieser wurde bis jetzt 
von MySQL nicht unterstützt. Zukünftig wird MySQL 5.1 und höher (6.0, 
...) Latin9 unterstützen. Entweder schon in der derzeit aktuellen 
Version oder aber es kommt mit der nächsten Version heraus.

Dennoch ist UTF8 hier die bessere Wahl.  Der einzige Grund gegen UTF8 
war in Deutschland bislang die Collation.  Auch hier hat sich etwas 
getan. Sowohl in 5.1 als auch in 6.0 wird es utf8_german2_ci 
(Telefonbuchsortierung (a=ae, u=ue, o=oe, ß=s) geben. Auch hier ist es 
entweder schon in der aktuellen Version oder kommt mit dem nächsten Release.

> Wer bis dahin als deutscher Nutzer tatsächlich Bedarf an erweiterter 
> Zeichenunterstützung hat, sollte besser Tools wie den Query Browser, 
> eine Linux Konsole mit UTF-8 oder eine webbasiertes Datenbankfrontend 
> mit entsprechenden Einstellungen benutzen.

Statt Query Browser würde ich hier MySQL Workbench empfehlen. MySQL ist 
dabei, den gesamten Umfang der alten GUI Tools (Query Browser, 
Administrator, Migration Toolkit) in Workbench zu implementieren. Query 
Browser trifft es hier als erstes.

>
> Gerade Anfängern, die noch keinen tieferen Einblick in die Thematik 
> der Zeichenkodierung und -umwandlung haben dürfte der "chcp 1252"-Tip 
> über die erste Frustration mit der MySQL Konsole hinweghelfen. 
> Jedenfalls habe ich als Anfänger verzweifelt nach einem solchen Tip 
> gesucht und nicht einmal die 'cp850' Lösung finden können. Auch in 
> vielen Foren liest man häufig die Frage nach den Umlauten, erhält aber 
> meist keine brauchbare Antwort.

Das liegt daran, dass es kaum Personen gibt, die sich damit auskennen. 
Für PostgreSQL und MySQL zusammen gibt es weltweit 5 Experten. Zwei 
deutsche (wobei einer hier mitlerweile nach Finland ausgewandert ist),  
ein Russe, ein Kanadier und ein Japaner.

Auch wenn PostgreSQL hier intern völlig anders funktioniert als MySQL so 
ist das Prinzip dasselbe. Das Prinzip ist sogar noch ausserhalb vom 
Datenbankthema gleich. Ich bekomme häufig auch Encoding Fragen zu völlig 
anderer Software oder zu Betriebssystemen. Hat man einmal das Prinzip 
verstanden, lässt es sich auf fasst alle Client-Server Anwendungen 
anwenden. Egal wie die Software das ganze intern implementiert hat.

Immer wieder schwierig ist es jedoch, das ganze native english Speakern 
beizubringen. Hier fehlt häufig einfach das Verständnis, dass es 
Sprachen gibt, die mehr Buchstaben, als a-z haben. Es ist mir durchaus 
schon passiert, dass ich nach mehreren Stunden Diskussion von einem 
amerikanischen Entwickler die Aussage bekam: "Ja aber utf8 und latin1 
ist doch dasselbe" ... In den ersten 7-bit hat er ja Recht, aber die 
interessieren bei dem Thema keinen.

Bei fast jeder größeren Open Source Veranstaltung reiche ich einen 
Vortrag zu dem Thema ein. Leider werden diese Vorträge häufig von den 
Orgas abgelehnt und stattdessen wählen die Orgas andere Vorträge von mir 
aus. Eine Orga hat mir als Begründung auf Nachfrage geantwortet: das 
Thema sei zu trocken, dafür würde sich kaum jemand interessieren.

Meine Folien von Vorträgen zu dem Thema sollten sich jedoch alle im Netz 
finden lassen.


Liebe Grüße

Susanne

-- 
Sun Microsystems GmbH 
Dipl.-Inf. Susanne Ebrecht, Support Engineer
52066 Aachen, Germany

http://www.sun.com

Registered Office: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Commercial register of the Local Court of Munich: HRB 161028
Managing Directors: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Chairman of the Supervisory Board: Martin Haering