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
