sqlsrv_connect ohne UTF-8, Umlaute Problem

[Rolf B]

Hallo pl,

irgendwann bekommst Du eine Rechnung über eine neue Tischkante. So oft, wie ich bei deinen "Fachinformationen" da schon hineingebissen habe...

Dateien enthalten Bytes. Jaaaa. Diese Bytes können möglicherweise Zeichen codieren.

Wenn Programme die Datei als Bytefolge verarbeiten wollen, können sie das tun. Aber dann wissen sie nichts von Zeichen. Solche Programme heißen z.B. "COPY" oder "WGET". Oder auch PHP, wenn es nur darum geht, eine Bytefolge mit UTF-8 Encoding 1:1 vom SQL-Server zum Browser durchzureichen.

Sobald ein Programm die codierten Zeichen korrekt verarbeiten will, muss es die verwendete Codierung kennen und beachten. Gerade dein Beispiel mit "ä" und "Ä" zeigt doch, wie wichtig diese Kenntnis ist. Verarbeitest Du eine Datei mit Unicode-codiertem Text als Bytefolge, bist Du überhaupt nicht im Stande, diesen case-insensitive Vergleich anzustellen. Und zeigst das Ä dann auch noch als zwei Zeichen an (oder gar 4 wenn es eine UTF32-Datei war).

Ein Beispiel für Programme, bei denen das nicht gut läuft, sind die Windows-Befehlszeile und das Windows GUI. Aus historischen Gründen läuft in Mitteleuropa die Befehlszeile auf CP850, und das GUI auf CP1252. Erstelle ich auf der Befehlszeile (z.B. mit COPY CON) eine Textdatei mit Umlauten, und öffne sie nachher mit Notepad, sind die Umlaute Schrott. Wechsle ich vorher mit CHCP 1252 die Codepage, liefert der COPY CON ein Ergebnis das mit NOTEPAD kompatibel ist. Schreibe ich mit NOTEPAD ein CMD-File, das Text ausgibt, ist der auf der Befehlszeile verstümmelt. Speichere ich das CMD als UTF-8, kriege ich gleich mal einen ERROR wegen des BOM. Die Windows Befehlszeile kann Zeichen NICHT vernünftig verarbeiten, weil sie mit Bytesemantik arbeitet und sich mit Codepages zu retten versucht.

Ein anderes Beispiel für das Versagen bei der Verarbeitung von ZEICHEN findet sich in den häufigen Forenfragen "warum kommen keine Umlaute an". Auch da wird das Encoding nicht beachtet und stumpf die Bytefolge als Zeichenfolge verarbeitet. Und wenn die Encodings von DB und Browser verschieden sind, geht's kaputt. Bei der DB kommt noch verschärfend hinzu, dass die Speicherung in der DB und die Übertragung vom DB-Server zum Web-Server nicht das gleiche Encoding haben müssen. Anonyme Bytefolgen, voller codierter Tretminen.

Um beim Anlass zu bleiben: Excel findet kein BOM. Und fällt deshalb auf Bytesemantik mit Codepage-Krücke zurück. Und es geht schief. Aufgabenstellung ist, die in der Datei abgelegte Bytefolge so zu gestalten, dass sie sich korrekt mit Excel öffnen lässt. Aufgabenstellung ist nicht, das verwendete Encoding mittels anderer Tools zu identifizieren.

Rolf