nicht angemeldet
Henry
Henry
dedlfix
Henry
MudGuard
Henry
Henry
Tabellenkalk
dedlfix
Gunnar Bittersmann
Henry
dedlfix
Henry
Auge
Der Martin
Hallo,
es gibt die Möglichkeit bei DHL, außer einem geschäftlichen, ein privates Kundenkonto zu registrieren. Das hat den theoretischen Vorteil auch Kundendaten für den Versand als CSV zu importieren. Doch das scheitert in vielerlei Hinsicht und ist sogar bedenklich.
Weil ich schon meine Befürchtungen hatte, habe ich es mit einer relativ kleinen Adressliste ausprobiert. Beim Import kam keine richtige Rückmeldung, woraufhin ich nochmal den Absendebutton geklickt hatte, was dazu führte, dass alle Adressen 2x drin sind. Also keine automatische Dopplerprüfung, keine Feldzuweisung, kein gar nichts. Immer noch keine Rückmeldung, also mal ins Adressbuch geschaut. Obwohl oberste Zeile unmißverständlich Begriffe wie land strasse hausnumemr enthielten, war der Inhalt verkehrt. Land wurde einfach zu Deutschland, obwohl alles Ausland war, Hausnummer gar nicht vorhanden, Umlaute zu Hieroglyphen weil der Import wohl kein UTF-8 kennt. Dann dachte ich schmeiß ich den Mist mal wieder raus, aber nö... so einfach gibt DHL die Adressen dann auch nicht wieder raus, müssen alle mühsam einzeln gelöscht werden. Gibt's denn so was? Ist so ein Unternehmen nicht imstande oder Willens so ein simles Import/Adresstool einigermaßen sauber hinzukriegen?
Nutzt hier noch jemand diese Möglichkeit bei DHL und kann meine Erfahrung bestätigen?
Gruss
Henry
Hallo,
von den anderen Problemen abgesehen, weiss ich nun zumindest welchen Zeichensatz die erwarten, cp1252.
Gibt es mit PHP eine einfache Möglichkeit UTF-8 in cp1252 umzuwandeln, bzw. auszugeben?
Gruss
Henry
Tach!
Gibt es mit PHP eine einfache Möglichkeit UTF-8 in cp1252 umzuwandeln, bzw. auszugeben?
CP1252 ist Windows-1252, eine erweiterung von ISO-8859-1. Kann man mit iconv() oder mb_convert_encoding() umwandeln.
dedlfix.
Hallo dedlfix,
CP1252 ist Windows-1252, eine erweiterung von ISO-8859-1. Kann man mit iconv() oder mb_convert_encoding() umwandeln.
danke, dann müsste
mb_convert_encoding( $txt, 'Windows-1252', 'UTF-8' );
funktionieren.
Gruss
Henry
Hi,
mb_convert_encoding( $txt, 'Windows-1252', 'UTF-8' );funktionieren.
Probleme gibt es, wenn Zeichen vorhanden sind, die es in cp1252 nicht gibt.
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
mb_convert_encoding( $txt, 'Windows-1252', 'UTF-8' );funktionieren.Probleme gibt es, wenn Zeichen vorhanden sind, die es in cp1252 nicht gibt.
Auch ganz interessant. Ist es denn möglich solche Fälle verlässlich durch zusätzlich mb_detect_encoding() anzusichern, oder alternative Möglichkeiten?
Gruss
Henry
Hallo,
Auch ganz interessant. Ist es denn möglich solche Fälle verlässlich durch zusätzlich mb_detect_encoding() anzusichern, oder alternative Möglichkeiten?
Obwohl ich diese Funktion anscheinend nicht richtig verstehe, weil...
if(mb_detect_encoding($txt,'UTF-8')){echo 'UTF-8 kodiert';}
if(mb_detect_encoding($txt,'ISO-8859-1')){echo 'ISO-8859-1 kodiert';}
erhalte ich als Ergebnis: UTF-8 kodiert ISO-8859-1 kodiert Ja und beides kann doch nicht gleichzeitig richtig sein oder doch?
Daher habe ich mal mb_check_encoding() ausprobiert:
if(mb_check_encoding($txt,'UTF-8')){echo 'UTF-8 kodiert';}
if(mb_check_encoding($txt,'ISO-8859-1')){echo 'ISO-8859-1 kodiert';}
und ja, hier funktioniert es scheinbar. Ausgabe: ISO-8859-1 kodiert
Oder doch nicht?
Denn wenn ich eine UTF-8 Datei einlese mit folgendem Inhalt "ßä#eöt+3#öt3+4lrägojpjö3gmrp42°^t'*" erscheint wieder Beides: UTF-8 kodiert ISO-8859-1 kodiert
Alles sehr verwirrend, diese ganzen Kodierungslabyrinthe. Selbst jeder Editor erkennt eine UTF-8 Datei ohne BOM als solche an, sobald auch nur ein Umlaut drin ist. Was mache ich falsch?
Andere Frage, hat nichts damit zu tun. Backticks ` kann ich hier, wie auch in anderen Textfeldern mit Shift+AltGr+Symbol sofort erstellen. In Editoren aber nur der komplizierte Weg mit Shift+Symbol+ irgendwann Leertaste oder irgendwas. Warum nicht überall wie im Browser, bzw. wo kommt diese Sache eigentlich her, dass ein Backtick durch shift+symbol bereits unsichtbar gespeichert wird aber erst aktiviert wird durch weiteres Zeichen/Leertaste, was ist der Sinn?
Gruss
Henry
Hallo,
Andere Frage, hat nichts damit zu tun. Backticks ` kann ich hier, wie auch in anderen Textfeldern mit Shift+AltGr+Symbol sofort erstellen. In Editoren aber nur der komplizierte Weg mit Shift+Symbol+ irgendwann Leertaste oder irgendwas. Warum nicht überall wie im Browser, bzw. wo kommt diese Sache eigentlich her, dass ein Backtick durch shift+symbol bereits unsichtbar gespeichert wird aber erst aktiviert wird durch weiteres Zeichen/Leertaste, was ist der Sinn?
Weil „Backtick“ eine Umbenennung des Gravis ist, ein sogenanntes diakritisches Zeichen. Irgendein Programmierer, vermutlich Amerikaner, der dieses Zeichen auf der Tastatur fand, hatte keinen Bock gehabt, zu recherchieren, wie es wirklich heißt…
Jedenfalls wird es erst zusammen mit einem anderen Zeichen z.b. e → è sinnvoll.
Gruß
Kalk
Moin,
Andere Frage, hat nichts damit zu tun. Backticks ` kann ich hier, wie auch in anderen Textfeldern mit Shift+AltGr+Symbol sofort erstellen. In Editoren aber nur der komplizierte Weg mit Shift+Symbol+ irgendwann Leertaste oder irgendwas. Warum nicht überall wie im Browser, bzw. wo kommt diese Sache eigentlich her, dass ein Backtick durch shift+symbol bereits unsichtbar gespeichert wird aber erst aktiviert wird durch weiteres Zeichen/Leertaste, was ist der Sinn?
Weil „Backtick“ eine Umbenennung des Gravis ist, ein sogenanntes diakritisches Zeichen. Irgendein Programmierer, vermutlich Amerikaner, der dieses Zeichen auf der Tastatur fand, hatte keinen Bock gehabt, zu recherchieren, wie es wirklich heißt…
das "Feature" nennt sich Dead Keys, d.h. ein Zeichen, das für sich allein möglicherweise keinen Sinn ergibt (vor allem ´`^~), wird vom Tastaturtreiber zunächst vorgemerkt und dann automatisch mit dem nächsten Zeichen kombiniert, wenn die Kombination ein gültiges Zeichen ist. Wenn nicht (z.B. ´ gefolgt von 4), werden beide Zeichen separat ausgegeben. Das Leerzeichen hat hier eine Sonderrolle, es wird bei einer solchen Kombination ignoriert.
Dieses Verhalten ist auch je nach Tastaturtreiber anders. Von meinem Linux-Desktop weiß ich, dass ich alternativ auch das Tastaturlayout "German (no deadkeys)" wählen könnte.
Ciao,
Martin
@@Der Martin
das "Feature" nennt sich Dead Keys […] Dieses Verhalten ist auch je nach Tastaturtreiber anders.
Yep. Bei meinem (US, macOS) ist weder [`] noch [~] noch [^] ein dead key. Zum Programmieren ist das auch gut so; da haben diese Zeichen ja für sich eine Bedeutung.
Die kombinierenden diakritischen Zeichen gibt’s mit [⌥]+[`], [⌥]+[n] bzw. [⌥]+[i]. So kann ich sòmi, sueño und rêve schreiben – ein Traum.
LLAP 🖖
Tach!
Obwohl ich diese Funktion anscheinend nicht richtig verstehe, weil...
if(mb_detect_encoding($txt,'UTF-8')){echo 'UTF-8 kodiert';}
if(mb_detect_encoding($txt,'ISO-8859-1')){echo 'ISO-8859-1 kodiert';}
erhalte ich als Ergebnis:
UTF-8 kodiert ISO-8859-1 kodiertJa und beides kann doch nicht gleichzeitig richtig sein oder doch?
Man kann Kodierungen grundsätzlich nicht erkennen. Es gibt lediglich einige Indizien, anhand derer man eine Annahme zu einer Kodierung treffen kann. Bei UTF-8 geht das, wenn Zeichen oberhalb von ASCII im Text vorkommen. Die müssen in der korrekten Byte-Sequenz kodiert sein.
Die einfachen Test-Funktionen beschränken sich meist darauf, ungültige Bytesequentzen zu finden, um eine bestimmte Kodierung ausschließen zu können.
Bei ISO-8859-1 ist jedem Byte ein Zeichen zugeordnet. (Die Ausnahmen 00..1F und 80..9F ignorieren wir mal.) Und weil jeder Bytewert ein Zeichen ergibt, gibt es keine Bytefolge, die kein korrektes ISO-8859-1 wäre. Dasselbe trifft auf alle Ein-Byte-Kodierungen zu, die keine unbelegten Bereiche haben.
Ob das Ergebnis sinnvoll ist, kann kein simpler Algorithmus feststellen. Dazu braucht es Dinge wie eine lexikalische Analyse, ob die Zeichen aneinandergereiht Wörter ergeben. Ansonsten kann man nicht sicher sehen, ob die beiden Bytes C3 A4 ein UTF-8-ä oder die beiden Zeichen à und ¤ sein sollen.
Alles sehr verwirrend, diese ganzen Kodierungslabyrinthe. Selbst jeder Editor erkennt eine UTF-8 Datei ohne BOM als solche an, sobald auch nur ein Umlaut drin ist. Was mache ich falsch?
"sobald auch nur ein Umlaut drin ist" weil die eine ganz bestimmte Byte-Sequenz ergeben müssen, von der es eher unwahrscheinlich ist, dass die als ISO-8859-1 interpretiert, ein sinnvolles Ergebnis ist. Die Aussage kann man verallgemeinern zu allen Zeichen außerhalb von ASCII, beziehungsweise mit Unicode-Codepoint größer als 127.
dedlfix.
@@dedlfix
Bei ISO-8859-1 ist jedem Byte ein Zeichen zugeordnet. (Die Ausnahmen 00..1F und 80..9F ignorieren wir mal.)
Und 7F auch. 😉
Ansonsten kann man nicht sicher sehen, ob die beiden Bytes C3 A4 ein UTF-8-ä oder die beiden Zeichen à und ¤ sein sollen.
LLAP 🖖
Hallo dedlfix,
Man kann Kodierungen grundsätzlich nicht erkennen. Es gibt lediglich einige Indizien, anhand derer man eine Annahme zu einer Kodierung treffen kann. Bei UTF-8 geht das, wenn Zeichen oberhalb von ASCII im Text vorkommen. Die müssen in der korrekten Byte-Sequenz kodiert sein.
Danke für die umfangreichen Ausführungen, ein Frage bleibt jedoch. Gibt es in PHP keine verlässliche Funktion, die anhand der Indizien das ebenso gut erkennt wie ein Editor? Weil, so wie ich es probiert habe, offensichtlich nicht.
Gruss
Henry
Tach!
Man kann Kodierungen grundsätzlich nicht erkennen. Es gibt lediglich einige Indizien, anhand derer man eine Annahme zu einer Kodierung treffen kann. Bei UTF-8 geht das, wenn Zeichen oberhalb von ASCII im Text vorkommen. Die müssen in der korrekten Byte-Sequenz kodiert sein.
Danke für die umfangreichen Ausführungen, ein Frage bleibt jedoch. Gibt es in PHP keine verlässliche Funktion, die anhand der Indizien das ebenso gut erkennt wie ein Editor? Weil, so wie ich es probiert habe, offensichtlich nicht.
Siehe obiges Zitat. Für Ein-Byte-Kodierungen gibt es prinzipbedingt keine Indizien. Man kann lediglich den Text analysieren, ob der sinnvoll ist.
Man kann auch nicht UTF-8 und ISO-8859-1 und ASCII voneinander unterscheiden, wenn der Text lediglich ASCII-Zeichen enthält. Er ist dann zu allen drei Kodierungen kompatibel.
dedlfix.
Hallo dedlfix,
e ein Editor? Weil, so wie ich es probiert habe, offensichtlich nicht.
Siehe obiges Zitat. Für Ein-Byte-Kodierungen gibt es prinzipbedingt keine Indizien. Man kann lediglich den Text analysieren, ob der sinnvoll ist.
Man kann auch nicht UTF-8 und ISO-8859-1 und ASCII voneinander unterscheiden, wenn der Text lediglich ASCII-Zeichen enthält. Er ist dann zu allen drei Kodierungen kompatibel.
Jetzt bin ich wieder verwirrt.
Ich habe doch dieses Beispiel:
Denn wenn ich eine UTF-8 Datei einlese mit folgendem Inhalt
"ßä#eöt+3#öt3+4lrägojpjö3gmrp42°^t'*"
erscheint wieder Beides: UTF-8 kodiert ISO-8859-1 kodiert
Ein Editor sagt mir hier klar, das ist UTF-8. Müsste der dann eigentlich sagen, klar, geht aber auch als ISO durch? Weil da gibts dann Probleme, wenn ich das als ISO behandeln würde.
Gruss
Henry
Hallo
Hallo dedlfix,
e ein Editor? Weil, so wie ich es probiert habe, offensichtlich nicht.
Siehe obiges Zitat. Für Ein-Byte-Kodierungen gibt es prinzipbedingt keine Indizien. Man kann lediglich den Text analysieren, ob der sinnvoll ist.
Man kann auch nicht UTF-8 und ISO-8859-1 und ASCII voneinander unterscheiden, wenn der Text lediglich ASCII-Zeichen enthält. Er ist dann zu allen drei Kodierungen kompatibel.
Jetzt bin ich wieder verwirrt.
Ich habe doch dieses Beispiel:
Denn wenn ich eine UTF-8 Datei einlese mit folgendem Inhalt"ßä#eöt+3#öt3+4lrägojpjö3gmrp42°^t'*"
erscheint wieder Beides: UTF-8 kodiert ISO-8859-1 kodiert
Eben, weil (ich zitiere): „Man kann auch nicht UTF-8 und ISO-8859-1 und ASCII voneinander unterscheiden, wenn der Text lediglich ASCII-Zeichen enthält. Er ist dann zu allen drei Kodierungen kompatibel.“
Die Zeichen in deiner Beispieleingabe sitzen in allen drei Kodierungen an den selben Stellen. Also ist die Eingabe in allen drei Kodierungen gültig.
Ein Editor sagt mir hier klar, das ist UTF-8.
Er hat für sich laut Programmierung diese Entscheidung getroffen.
Müsste der dann eigentlich sagen, klar, geht aber auch als ISO durch?
Warum sollte er, wenn es doch gültiges UTF-8 ist und selbiges heutzutage (mehr oder minder) Standard ist?
Weil da gibts dann Probleme, wenn ich das als ISO behandeln würde.
Es gibt keine Probleme mit gültigem ISO-8859-1, wenn gültiges ISO-8859-1 als ISO-8859-1 behandelt wird.
Tschö, Auge
Tach!
Ich habe doch dieses Beispiel:
Denn wenn ich eine UTF-8 Datei einlese mit folgendem Inhalt"ßä#eöt+3#öt3+4lrägojpjö3gmrp42°^t'*"
erscheint wieder Beides: UTF-8 kodiert ISO-8859-1 kodiert
Eben, weil (ich zitiere): „Man kann auch nicht UTF-8 und ISO-8859-1 und ASCII voneinander unterscheiden, wenn der Text lediglich ASCII-Zeichen enthält. Er ist dann zu allen drei Kodierungen kompatibel.“
Das trifft hier aber nicht zu.
Die Zeichen in deiner Beispieleingabe sitzen in allen drei Kodierungen an den selben Stellen. Also ist die Eingabe in allen drei Kodierungen gültig.
Die Bytes dieses Textes, in UTF-8-kodiert, ergeben korrekt UTF-8-Sequenzen. Damit ist es gültiges UTF-8. Da aber jedes Byte auch einem Zeichen von ISO-8859-1 zugeordnet ist (Ausnahmen ignoriert) ergibt das auch gültiges ISO-8859-1. Nur hat man dann nicht mehr den Text von oben sondern die Umlaute und ß sind durch zwei andere Zeichen ersetzt. Es gibt keine Bytesequenz, die nicht auch gültiges ISO-8859-1 ist (Ausnahmen ignoriert).
Ein Editor sagt mir hier klar, das ist UTF-8.
Er hat für sich laut Programmierung diese Entscheidung getroffen.
Ja, wenn gültige UTF-8-Sequenzen erkannt werden, wird es wohl UTF-8 sein, entscheidet der Editor. Anderenfalls wird es eine Ein-Byte-Kodierung sein. Welche er da nimmt, kann zum Beispiel davon abhängen, welche Lokalisierungseinstellungen im System zu finden sind, und welche Kodierung dazu üblicherweise verwendet wird. Oder es ist im Editor konfiguriert, welche Kodierung für Nicht-UTF-8-Texte er nimmt.
Henry, wenn du unbekannten Text analysieren möchtest, kannst du nur genauso vorgehen.
Ist es gültiges UTF-8? => UTF-8 ansonsten: ISO-8859-1
Du kannst dir dann zwar nicht sicher sein, dass es nicht auch anderes ISO-8859-x ist, aber die Wahrscheinlichkeit sollte gering sein, wenn die Quelle deutsche oder westeuropäische Texte sind. Ist es tatsächlich eine andere ISO-8859-x-Kodierung, kannst du es nicht mit vertretbarem technischem Aufwand herausfinden, wenn du nicht irgendeine fertige Komponente dafür verwendest, die mit irgendwelchen Inhaltsanalysen genauer zu raten versucht.
dedlfix.
@@dedlfix
Ist es gültiges UTF-8? => UTF-8 ansonsten: ISO-8859-1
🤔 Wäre man nicht mit der Annahme Windows-1252 besser dran?
Du kannst dir dann zwar nicht sicher sein, dass es nicht auch anderes ISO-8859-x ist, aber die Wahrscheinlichkeit sollte gering sein, wenn die Quelle deutsche oder westeuropäische Texte sind.
ISO-8859-15?
LLAP 🖖
Tach!
Ist es gültiges UTF-8? => UTF-8 ansonsten: ISO-8859-1
🤔 Wäre man nicht mit der Annahme Windows-1252 besser dran?
Ja, eher das.
Du kannst dir dann zwar nicht sicher sein, dass es nicht auch anderes ISO-8859-x ist, aber die Wahrscheinlichkeit sollte gering sein, wenn die Quelle deutsche oder westeuropäische Texte sind.
ISO-8859-15?
Welche Verbreitung hat das denn? Alos nicht, wer es nutzen könnte, sondern wer es tatsächlich (statt Win-1252) nimmt.
dedlfix.
@@dedlfix
ISO-8859-15?
Welche Verbreitung hat das denn? Alos nicht, wer es nutzen könnte, sondern wer es tatsächlich (statt Win-1252) nimmt.
Hm, vermutlich war zu Zeiten, als das €-Zeichen kam (und zwei andere Zeichen?), längst UTF-8 angesagt.
LLAP 🖖
Tach!
ISO-8859-15?
Welche Verbreitung hat das denn? Alos nicht, wer es nutzen könnte, sondern wer es tatsächlich (statt Win-1252) nimmt.
Hm, vermutlich war zu Zeiten, als das €-Zeichen kam (und zwei andere Zeichen?), längst UTF-8 angesagt.
Nein, das war meiner Erinnerung nach noch nicht der Fall. Eher hat(t)e man keine Not, auf -15 zu gehen, weil man Windows-1252 statt reinem -1 verwendet (hat) und da das Eurozeichen vorhanden ist.
dedlfix.
Hallo,
Denn wenn ich eine UTF-8 Datei einlese mit folgendem Inhalt
"ßä#eöt+3#öt3+4lrägojpjö3gmrp42°^t'*"
erscheint wieder Beides: UTF-8 kodiert ISO-8859-1 kodiert
Ein Editor sagt mir hier klar, das ist UTF-8.
da ist anscheinend eine zusätzliche Logik-Ebene.
Müsste der dann eigentlich sagen, klar, geht aber auch als ISO durch?
Ja, eigentlich schon. Die zusätzliche Logik sagt aber wahrscheinlich: Wenn's den komplizierteren Regeln für UTF-8 genügt, wird's wohl auch tatsächlich UTF-8 sein.
Weil da gibts dann Probleme, wenn ich das als ISO behandeln würde.
Beim Bearbeiten auf jeden Fall.
Ciao,
Martin
