nicht angemeldet dedlfix
Rolf B
Gunnar Bittersmann
Matthias Apsel
Rolf B
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
Rolf B
Hallo,
eine Webanwendung zeigt Daten aus einer MS SQL Db an. Diese Daten haben auch deutsche Umlaute wie Ö, ü usw. Die Verbindung wird mit sqlsrv_connect hergestellt. Ich hatte zuerst ein CharacterSet mit UTF-8
//vorher mit UTF-8
//$connectionInfo = array( "Database"=>"myDB", "UID"=>"myName", "PWD"=>"myPW", "CharacterSet" => "UTF-8");
$connectionInfo = array( "Database"=>"myDB", "UID"=>"myName", "PWD"=>"myPW");
$con = sqlsrv_connect( $serverName, $connectionInfo);
Bei der betreffenden PHP Datei showData.php zur Anzeige der Daten hatte ich im header <meta charset="utf-8" /> drin stehen und alles war gut. (Umlaute wurden richtig angezeigt.)
Jetzt kann man die Daten aber auch als CSV Datei downloaden und diese hat dann auch UTF-8 als Kodierung. Dies wurde jetzt bemängelt weil ein Doppelklick der CSV Excel öffnet und die Umlaute nicht richtig darstellt. Man muss also vorher ind er CSV die Kodierung umstellen.
Daher habe ich nun mal in der Connection das UTF-8 entfernt und auch in der showData.php das charset=utf-8 entfernt.
Ich nahm jetzt an, dass die Umlaute richtig angezeigt werden, dem ist aber leider nicht so. Vermutlich muss man alle Daten nochnals mit utf8_encode behandeln?
Ich wundere mich nur, denn ursprünglich ist das eine uralte Webanwendung vom Jahr 2000 in PHP4 geschrieben, mit einem alten IIS und Windows Server und alter SQL DB. Und damals gab es angeblich keine Probleme mit Umlauten.
Die Frage ist nun: Wie am besten verfahren, damit Daten richtig angezeigt werden und die CSV Datei in ANsi ist?
Gruss
Werner
Tach!
eine Webanwendung zeigt Daten aus einer MS SQL Db an. Diese Daten haben auch deutsche Umlaute wie Ö, ü usw. Die Verbindung wird mit sqlsrv_connect hergestellt. Ich hatte zuerst ein CharacterSet mit UTF-8
//vorher mit UTF-8 //$connectionInfo = array( "Database"=>"myDB", "UID"=>"myName", "PWD"=>"myPW", "CharacterSet" => "UTF-8"); $connectionInfo = array( "Database"=>"myDB", "UID"=>"myName", "PWD"=>"myPW"); $con = sqlsrv_connect( $serverName, $connectionInfo);Bei der betreffenden PHP Datei showData.php zur Anzeige der Daten hatte ich im header <meta charset="utf-8" /> drin stehen und alles war gut. (Umlaute wurden richtig angezeigt.)
Jetzt kann man die Daten aber auch als CSV Datei downloaden und diese hat dann auch UTF-8 als Kodierung. Dies wurde jetzt bemängelt weil ein Doppelklick der CSV Excel öffnet und die Umlaute nicht richtig darstellt. Man muss also vorher ind er CSV die Kodierung umstellen.
Es kann sein, dass eine UTF-8-BOM Wunder bewirkt.
Daher habe ich nun mal in der Connection das UTF-8 entfernt und auch in der showData.php das charset=utf-8 entfernt.
Ich nahm jetzt an, dass die Umlaute richtig angezeigt werden, dem ist aber leider nicht so. Vermutlich muss man alle Daten nochnals mit utf8_encode behandeln?
Vermutlich eher utf8_decode(). Aber wenn du nur die Kodierungsangabe entfernst, wird nicht auf magische Weise alles zu Nicht-UTF-8. Was auch immer das dann sein mag. Es ist sinnvoller, die gewünschte Kodierung anzugeben und es nicht dem Zufall zu überlassen, was die Systeme für eine Kodierung verwenden.
Ich wundere mich nur, denn ursprünglich ist das eine uralte Webanwendung vom Jahr 2000 in PHP4 geschrieben, mit einem alten IIS und Windows Server und alter SQL DB. Und damals gab es angeblich keine Probleme mit Umlauten.
Dann lief zufällig alles, ohne dass ihr Fehler bemerkt habt. Oder es war überall dieselbe Kodierung als Default eingestellt. Auch damals gab es jedenfalls schon mehr als eine Kodierung.
Wie am besten verfahren, damit Daten richtig angezeigt werden und die CSV Datei in ANsi ist?
Der beste Weg ist immer, nicht auf Default-Werte zu setzen, sondern explizit Kodierungsangaben vorzunehmen, und wenn eine andere Kodeirung gewünscht ist, dann sollte man das umkodieren. Beachte, dass das nicht in jede Richtung verlustfrei möglich ist.
dedlfix.
Hallo dedlfix,
uralte Webanwendung vom Jahr 2000 […] angeblich keine Probleme mit Umlauten.
Dann lief zufällig alles, ohne dass ihr Fehler bemerkt habt. Oder es war überall dieselbe Kodierung als Default eingestellt. Auch damals gab es jedenfalls schon mehr als eine Kodierung.
oder es gab keine Umlaute, weil die DB-Experten ohnehin mit englischer Tastatur gearbeitet haben (Ich weiß, dass man trotzdem Umlaute eingeben kann), wie es zumindest in den 90ern noch üblich war (zumindest, was ich damals kennengelernt habe).
Bis demnächst
Matthias
@@Matthias Apsel
weil die DB-Experten ohnehin mit englischer Tastatur gearbeitet haben (Ich weiß, dass man trotzdem Umlaute eingeben kann), wie es zumindest in den 90ern noch üblich war
Ich arbeite auch heute noch mit englischer (US) Tastatur – egal, wie diese beschriftet ist. Ich will mir ja für @, [, ], {, }, … nicht die Finger brechen.
LLAP 🖖
hallo
Keine Ahnung, aber eventuell kann es für Excell helfen, wenn man die Datei mit einer BOM ausstattet.
Hallo,
ich hatte mal das gleiche Problem und kann meinen Vorrednern nur zustimmen: man muss einen BOM in die csv-Datei schreiben damit Excel das richtig darstellt. Alternativ kann man die Datei auch in Excel importieren, da kann man die Codierung manuell festlegen.
LG count
Hallo,
Ich wundere mich nur, denn ursprünglich ist das eine uralte Webanwendung vom Jahr 2000 in PHP4 geschrieben, mit einem alten IIS und Windows Server und alter SQL DB. Und damals gab es angeblich keine Probleme mit Umlauten.
Wenn man, was im Jahr 2000 so üblich war, nur bytesemantisch gearbeitet hat, gab es auch mit UTF-8 noch nie Probleme.
Die Frage ist nun: Wie am besten verfahren, damit Daten richtig angezeigt werden und die CSV Datei in ANsi ist?
Die Frage ist, mit welcher Kodierung die Zeichen in dieser Datei gespeichert sind. Für bestimmte Zeichen lässt sich das sicher feststellen. Also nicht mit Excel auf die Datei losgehen, sondern mit einem Texteditor und ggf. auf die hexadezimale Ansicht umschalten.
MfG
PS: Ich sehe gerade, das P war von heute morgen, ist das mittlerweile gelöst!?
Hallo pl,
was auch immer bytesemantisches Arbeiten bedeuten soll.
Das Grundproblem haben wir schon in mehrern Threads diskutiert: Ohne BOM weiß der Konsument einer Bytesequenz nicht, dass sie einen in UTF-8 codierter Text darstellt. Excel interpretiert sie dann als "Ein Byte, Ein Zeichen" gemäß der regional verwendeten Windows-Defaultcodepage und lässt sich auch bei späterem Antreffen einer UTF-8 Sequenz nicht mehr davon abbringen.
Beim Öffnen per Doppelklick ist Excel besonders arg lobotomisiert; es ÖFFNET die Datei. Es kommt nicht auf den Gedanken, sich vielleicht per Textkonvertierungsassistent Hilfe zu holen.
Und auch über den Datei öffnen Dialog ist Excel 2016 nicht völlig brauchbar; hat die Datei ein BOM, öffnet sich bei Verwendung von "Datei öffnen" der Textkonvertierungsassistent und schlägt UTF-8 als Zeichensatz vor. Fehlt das BOM, und die Datei sieht grob nach CSV aus, überspringt es den Assistenten und zerreißt die Umlaute.
Was besser funktioniert, ist über das Daten Ribbon "Externe Daten abrufen" zu nutzen. Da gibt es "Aus Text" und dann kommt der Import Wizard, so dass man hier auch UTF-8 Dateien mit fehlendem BOM abrufen kann.
Es wäre praktisch, wenn Excel bei Doppelklick auf eine CSV Datei IMMER den Wizard aufrife.
Rolf
hi @Rolf B
was auch immer bytesemantisches Arbeiten bedeuten soll.
Bytesemantic heißt bytesemantic. D.h., daß Daten ab Erhebung über die Verarbeitung und Speicherung bis zur Ausgabe nicht als Zeichen betrachtet werden sondern als Bytesequenzen.
Hinsichtlich Speicherung in Dateien, also auch CSV ist zu sagen, das dies immer Bytesemantic ist. Das trifft auch für die Speicherung in Datenbanken zu und natürlich auch für die Übertragung.
Charactersemantic kommt erst mit der Kodierung ins Spiel. Zeichenorientiert sind z.B. Stringvergleiche (Collation) und Stringoperationen (Uppercase, Substring..). Eine Case insensitive Collation ist auch ein schönes Beispiel für Charactersemantic: Wenn 'ä' == 'Ä' sein soll, was zwei völlig verschiedene Bytesequenzen sind, muss das über eine bestimmte Kodierung vermittelt werden.
Es wäre praktisch, wenn Excel bei Doppelklick auf eine CSV Datei IMMER den Wizard aufrife.
Excel ist hier zur Problembehandlung nicht nur nebensächlich sondern auch unbrauchbar. Zu Prüfen wära, ob die Daten vom Lesen aus der DB bis zur Erstellung der CSV Datei verändert wurden. Wurde durchgehend bytesemantisch gearbeitet, ist eine Veränderung am Wenigsten wahrscheinlich.
Wenn in der gesamten Verarbeitungskette nicht zeichenorientiert irgendwelche Stringoperationen wie substring, oder upper/lowercase durchgeführt wurden, landen die Bytes genauso in einer CSV Datei wie sie aus einer Datenbank gleich welcher Art gelesen wurden.
Und genau das lässt sich ja feststellen. MfG
@@pl
Bytesemantic heißt bytesemantic. D.h., daß Daten ab Erhebung über die Verarbeitung und Speicherung bis zur Ausgabe nicht als Zeichen betrachtet werden sondern als Bytesequenzen.
Ach so ist das. Bei der Datenerhebung gibt der Nutzer nicht etwa die Zeichenfolge „Hotti“ in ein Eingabefeld ein, sondern die Bytesequenz 48 6F 74 74 69.
Und bei der Ausgabe betrachten wir auch keine Zeichen, sondern Bytes.
Ich glaube, wann immer 48 6F 74 74 69 sich zu Zeichen und Bytes äußert, kommt Unsinn raus.
LLAP 🖖
Hallo Gunnar Bittersmann,
Ich glaube, wann immer 48 6F 74 74 69 sich zu Zeichen und Bytes äußert, kommt Unsinn raus.
44 75 6D 65 69 6E 73 74 55 6E 73 69 6E 6E 3F
Bis demnächst
Matthias
Moin,
fehlen da,
Ich glaube, wann immer 48 6F 74 74 69 sich zu Zeichen und Bytes äußert, kommt Unsinn raus.
44 75 6D 65 69 6E 73 74 55 6E 73 69 6E 6E 3F
nicht noch 20?
Viele Grüße
Robert
Hallo Robert B.,
nicht noch
20?
Nein,wozu?Siehtdochauchsoganznettaus.
Bis demnächst
Matthias
@@Matthias Apsel
nicht noch
20?Nein,wozu?Siehtdochauchsoganznettaus.
Werbehauptet,duplenktest,derlügt.
LLAP 🖖
Bei Ein/Ausgabe vermittelt ein Gerät zwischen Byte~ und Charactersemantic.
Übertragen werden grundsätzlich Bytes. Mich wunderts nur, daß Du schon wieder mit diesem Thema anfängst wo ich dachte daß Du es längstens verstanden hast.
MfG
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
@@pl
Übertragen werden grundsätzlich Bytes.
Falsch. Übertragen werden Bits.
Aber das ist ziemlich irrelevant. Dir tränen beim Zwiebelschälen immer die Augen, so dass du selbige davor verschließt?
Lange Rede, kurzer Sinn: textuelle Daten werden ab Erhebung über die Verarbeitung und Speicherung bis zur Ausgabe als Zeichenketten betrachtet. Wenn man sie an irgendeiner Stelle (auch während der Verarbeitung!) als Bytesequenzen betrachtet, macht man was falsch.
LLAP 🖖
Tach!
Lange Rede, kurzer Sinn: textuelle Daten werden ab Erhebung über die Verarbeitung und Speicherung bis zur Ausgabe als Zeichenketten betrachtet. Wenn man sie an irgendeiner Stelle (auch während der Verarbeitung!) als Bytesequenzen betrachtet, macht man was falsch.
Ganz so einfach ist es nun auch wieder nicht, denn wir leben nicht in einem reinen Javascript-Kosmos. Eher früher als später kommt die Physik ins Spiel, und dann muss man sich zumindest mal mit der Kodierung auseinandergesetzt haben. Und das ganz besonders, wenn es darum geht, mit oder für fremde Systeme zu arbeiten.
dedlfix.
@@dedlfix
Ganz so einfach ist es nun auch wieder nicht, denn wir leben nicht in einem reinen Javascript-Kosmos. Eher früher als später kommt die Physik ins Spiel, und dann muss man sich zumindest mal mit der Kodierung auseinandergesetzt haben.
Ja, dann sollte man wissen, dass in der darunterliegenden Zwiebelschicht Zeichenketten durch Bytesequenzen dargestellt werden und man ggfs. mal umcodieren muss. Das heißt aber nicht, dass man Zeichenketten an irgendeiner Stelle als Bytesequenzen verarbeiten muss oder sollte.
LLAP 🖖
Übertragen werden grundsätzlich Bytes.
Falsch. Übertragen werden Bits.
Es kommt darauf an, auf welchem Layer Du bist. Unsereiner (Programmierer) jedenfalls befindet sich auf dem Layer wo es nicht um Bits geht sondern um Bytes.
Das ist übrigens auch in RDBMS so üblich. Ebenso werden auch Datentypen auf Byteebene definiert und nicht auf Bitebene: Ein Tiny Integer ist z.B. die kleinste Speichereinheit mit 1 Byte.
Lange Rede, kurzer Sinn: textuelle Daten werden ab Erhebung über die Verarbeitung und Speicherung bis zur Ausgabe als Zeichenketten betrachtet. Wenn man sie an irgendeiner Stelle (auch während der Verarbeitung!) als Bytesequenzen betrachtet, macht man was falsch.
Die meisten Fehler passieren wenn die Verarbeitung zeichnorientiert erfolgt. Der Hinweis, daß es im Jahr 2000 mit Umlauten keine Probleme gab bestätigt ja diese Erfahrung:
Eine byteorientierte Verarbeitung hingegen ist viel weniger fehleranfällig.
Wer allerdings den Unterschied zwischen byte~ und charactersemantics nicht kennt, kann auch mit dieser Erfahrung nichts anfangen. Und wird diese Erfahrung wohl auch niemals selber machen!
MfG
Hallo pl,
Der Hinweis, daß es im Jahr 2000 mit Umlauten keine Probleme gab
… ist falsch. Im Jahre 2000 hat man an diversen Stellen entweder den replacement character � gesehen oder die typischen UTF-8-Sequenzen. Auch die Browser-Unterstützung war bestenfalls mäßig und ziemlich buggy.
Eine byteorientierte Verarbeitung hingegen ist viel weniger fehleranfällig.
Validierung, parsing, etc, pp kann nur fehlerfrei funktionieren, wenn man den Stream als Zeichen liest. Nur schon diese Standard-Aufgabe in einem Parser „skippe alle Whitespaces“ ist nur möglich, wenn man den Stream als eine Menge von Zeichen betrachtet.
Im Gegenteil also, wenn man einen Stream als eine Menge von Bytes betrachtet, macht man seinen Code anfälliger für Fehler.
LG,
CK
@@pl
Übertragen werden grundsätzlich Bytes.
Falsch. Übertragen werden Bits.
Es kommt darauf an, auf welchem Layer Du bist.
Richtig. Ganz unten sind’s Bits, die sequentiell auf die Reise gehen. In höheren Schichten wird man Bits sinnvoll gruppieren – zunächst zu Bytes; weiter höher zu Zeichen.
Unsereiner (Programmierer) jedenfalls befindet sich auf dem Layer wo es nicht um Bits geht sondern um Bytes.
Deinereiner vielleicht. Dann bist du halt auf niedriger Stufe steckengeblieben. Passiert manchen.
Aber nicht allen. Programmierer schaffen es üblicherweise auf die höhere Stufe und verarbeiten Zeichenketten als solche.
LLAP 🖖
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
Hallo Rolf,
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.
Amen!
Leider wird das nie der Fall sein… *duck*
LG,
CK
hi @Rolf B
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.
Genau da ist Dein Irrtum. Bytesemantic heißt eben nicht, daß ein Zeichen ein Byte ist.
Im Übrigen kann man durchaus eine zeichenorientierte Verbindung zur DB herstellen, so wie das hier gezeigt wurde. Nur speichern CSV Dateien eben keine Zeichen sondern Bytes. Ergo baut man zweckmäßigerweise keine zeichenorientierte Verbindung auf, weil die Collation gar keine Rolle spielt.
MfG
hallo
Nur speichern CSV Dateien eben keine Zeichen sondern Bytes. Ergo baut man zweckmäßigerweise keine zeichenorientierte Verbindung auf, weil die Collation gar keine Rolle spielt.
Du meinst %2C-Dateien.
@@pl
Nur speichern CSV Dateien eben keine Zeichen sondern Bytes.
„Nur speichern JPEG-Dateien eben keine Bilder, sondern Bytes.“
Deine Aussage wird auch durch Hinzufügen von Interpunktionszeichen nicht besser.
LLAP 🖖
hi,
Daher habe ich nun mal in der Connection das UTF-8 entfernt und auch in der showData.php das charset=utf-8 entfernt.
Ich nahm jetzt an, dass die Umlaute richtig angezeigt werden, dem ist aber leider nicht so. Vermutlich muss man alle Daten nochnals mit utf8_encode behandeln?
Wenn die Daten in einer CSV Datei gespeichert werden sollen ist es korrekt, für die Connection keine Kodierung zu setzen. Ansonsten hättest Du eine zeichenorientierte Verbindung und müsstest vor dem Speichern in der Datei wieder auf Bytesemantic umschalten. Mehr dazu bei MS.
MfG
Tach!
Wenn die Daten in einer CSV Datei gespeichert werden sollen ist es korrekt, für die Connection keine Kodierung zu setzen. Ansonsten hättest Du eine zeichenorientierte Verbindung und müsstest vor dem Speichern in der Datei wieder auf Bytesemantic umschalten. Mehr dazu bei MS.
Das Thema ist nach wie vor PHP. Es gibt da keine Umschaltung von und nach Bytesemantic. Man nimmt da entsprechende Funktionen, um Strings in andere Kodierungen zu bringen. Und Strings sind nach wie vor byteorientiert. Was aber nicht weiter tragisch ist, wenn man die Strings nur durchreicht (und gegebenenfalls umkodiert).
Auch hat man keine zeichenorientierte Verbindung, wenn man keine Kodierungsangabe auf der Verbindung setzt, weil PHP nicht zeichenorientiert arbeitet. Man hat dann nur eine Verbindung, auf der irgendeine Default-Kodierung verwendet wird, die nicht diejenige sein muss, die man gern hätte.
dedlfix.
Tach!
Wenn die Daten in einer CSV Datei gespeichert werden sollen ist es korrekt, für die Connection keine Kodierung zu setzen. Ansonsten hättest Du eine zeichenorientierte Verbindung und müsstest vor dem Speichern in der Datei wieder auf Bytesemantic umschalten. Mehr dazu bei MS.
Das Thema ist nach wie vor PHP. Es gibt da keine Umschaltung von und nach Bytesemantic.
Doch die gibt es: Nämlich beim Herstellen der Verbindung!
Siehe sqlsrv_connect() Dokumentation.
MfG