sqlsrv_connect ohne UTF-8, Umlaute Problem
bearbeitet von Rolf BHallo pl,
irgendwann bekommst Du eine Rechnung über eine neue Tischkante. So oft, wie ich bei deinen "Fachinformationen" da schon hineingebissen habe...
Dateien enthalten Bytes. 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".
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.
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.
_Rolf_
--
sumpsi - posui - clusi