sqlsrv_connect ohne UTF-8, Umlaute Problem

[Rolf B]

Hallo pl,

Unsereiner (Programmierer) jedenfalls befindet sich auf dem Layer wo es nicht um Bits geht sondern um Bytes.

Die Bits waren natürlich überspitzt; darum kümmert sich der Silizium-Layer. Aber trotzdem bist Du im Irrtum. Auf dem Layer der Laufzeitbibliothek geht es um Bytes. Auf dem Layer "Anwendungssoftware" sollte es um Zeichen gehen, und die Laufzeitumgebung sollte das abstrahieren.

Die Abstraktion besteht leider öfter mal darun, dass die Laufzeitumgebung MBCS-Funktionen für Zeichenkettenverarbeitung bereit stellt und Du strikt darauf achten musst, bei Bytesequenzen, die MBCS-codierte Strings darstellen, nur diese Funktionen zu verwenden.

Der Hinweis, daß es im Jahr 2000 mit Umlauten keine Probleme gab

wird durch Wiederholung nicht richtiger. Leider ist die Nostalgie nicht mehr das, was sie mal war.

Keine Umlautprobleme hatte man eher in den 1960ern, da gab's die nämlich einfach nicht. Statt dessen hatte man 7-bit ASCII und sogar Kleinbuchstaben waren Luxus. WAS DAFUER SORGTE, DASS DEUTSCHE TEXTE RECHT BLOED AUSSAHEN. Und es gab andere Codepages, z.B. IBM EBCDIC, das so inkompatibel zu ASCII ist, dass sogar die Sortierfolge Zahlen-Großschrift-Kleinschrift auf dem Kopf steht. D.h. da hatte man kein Umlautproblem sondern bereits Probleme mit den Basiszeichen, wenn man Dateien übertrug.

Nachdem es dann nationale Variationen der 7-bit Codes gab, folgte das Problem der 7-bit Sonderbelegungen in den Zeichens{tzen. IBM PCs wollten das mit Codepage 437 besser machen, sprang aber auch zu kurz. Es folgten CP850/CP858, wo die Blockgrafik durch europäische Sonderzeichen ersetzt wurde und alle Programme schredderte, die damit Oberflächen gezeichnet hatten. Danach kam Windows Latin-1 (oder CP1252), das sich an die ersten 256 Zeichen von Unicode anlehnt und darum die Umlaute verschiebt. Und bis zu dem Tag, wo JEDER Unicode macht, wird es Probleme mit den unterschiedlichen Codepages geben.

Ich verwende PCs seit es sie gibt, ich habe seit 1985 mit IBM Großrechnern und EBCDIC zu tun - erzähl mir nicht dass es irgendwann mal eine Zeit gab wo Umlaute KEIN Problem waren, solange man Zeichen mit Bytes gleichsetzte. Das funktioniert nur in einer Monokultur, wo alle beteiligten Komponenten die gleiche Codepage nutzen. Hast Du nie in einem Uralt-Nadeldrucker die Codepage einstellen müssen? Und ggf. geflucht, weil er nur CP437 kannte, dein Computer aber unbedingt CP850 oder CP1252 verwenden wollte? Ich habe schon TSR-Programme für DOS geschrieben, die sich vor die Druckerschnittstelle geklemmt haben und Codepages on-the-fly übersetzt haben, weil es einfach nicht anders ging.

Zeichenrepräsentation war immer ein Problem, seit man Texte auf Computern verarbeitet, und wird eins bleiben, bis auch der Letzte eingesehen hat, dass Zeichen keine Bytes sind.

Rolf