Ergebnis 1 bis 12 von 12

Text mit falschem Charset, Fehlerhafte Zeichen

  1. #1 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.800
    Hallo Zusammen,
    ich habe hier eine umfangreiche csv Datei, welche laut Besitzer im UTF-8 Format codiert sein soll. Öffne ich die Datei allerdings im UTF-8 Format sind einige Sonderzeichen Fehlerhaft. Bsp:
    Code:
    • Noch mehr Zeit
    
    Häufigkeit Fahrten mit Sozius…%4
    Ich habe bisher keinen Weg gefunden die Fehlerhaften Zeichen wiederherzustellen. Alternativ würde mir auch eine Methode reichen automatisch alle diese Fehlerhaften Zeichen bzw Kästchen aufzuspüren.
    Habt ihr da eine Idee?

    EDIT:
    mir fällt gerade auf, das die Zeichen hier nach dem abspeichern richtig angezeigt werden. Also Statt eines Kästchens "•" und "…". Dann müsste es doch einen Weg geben das ganze automatisiert umzuwandeln?

    Viele Grüße
    Feuerstern ist offline

  2. #2 Zitieren
    Ritter Avatar von Kalkihe
    Registriert seit
    Jan 2008
    Ort
    Kerlsruhe
    Beiträge
    1.578
    Womit öffnest du die Datei denn? Mit Excel oder mit irgendeinem selbst geschriebenem Tool?
    Zitat Zitat von Matteo Beitrag anzeigen
    Gewagte These: Ein Bewohner von Kalkihes Wohnheim arbeitet offensichtlich in Professor Hunts Unternehmen.
    Kalkihe ist gerade online

  3. #3 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.800
    Die Datei öffne ich mit Libre office calc wo ich auch UTF-8 beim öffnen auswähle. Die Datei wurde aber über eine Schnittstelle in einen Onlineshop importiert. In der Datenbank und im Shop Frontend stehen die Texte dann mit dem selben Darstellungsfehler.
    Feuerstern ist offline

  4. #4 Zitieren
    Halbgott Avatar von Progrinator
    Registriert seit
    Apr 2018
    Ort
    München
    Beiträge
    9.174
    Gibt es nicht verschiedene UTF8 (Zumindest wird es in PHPMyAdmin mehrere angezeigt (UTF8gerlalic, UTF8German ... )

    Ansonsten habe ich keien Ahnung.
    Progrinator ist offline

  5. #5 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.800
    Ich habe jetzt noch etwas rumprobiert. Wenn ich den Text nach ISO-8859-1 umwandel und das Charset der Webpage auf charset=ISO-8859-1 setzte, wird der Text richtig angezeigt
    Code:
    $txtConv = iconv('UTF-8', 'ISO-8859-1', $txt);
    Ergebnis:
    [Bild: EOMRt.jpg]

    Im Produktiv Betrieb muss ich aber charset=UTF-8 einsetzten. Dann sieht der Text auf der Webseite leider so aus:

    [Bild: r4L4r.jpg]

    Es muss doch einen Weg geben den Text so umzuwandeln, dass er unter UTF-8 so aussieht wie unter ISO-8859-1.
    Feuerstern ist offline

  6. #6 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.328
    Zitat Zitat von Feuerstern Beitrag anzeigen
    Ich habe jetzt noch etwas rumprobiert. Wenn ich den Text nach ISO-8859-1 umwandel und das Charset der Webpage auf charset=ISO-8859-1 setzte, wird der Text richtig angezeigt
    Du könntest z.B. mal Input und Output in garantiert unveränderter Form (natürlich ohne vertrauliche Informationen drin) in ein Zip-Archiv tun und hier verlinken, damit sich das mal jemand angucken kann. Mein Hex-Editor spricht auch manchmal UTF-8.

    Edit:

    Falls du keinen Dateizugriff hast, empfiehlt sich ein lokaler Webserver, z.B. im XAMPP-Paket. Gutes Hosting erlaubt aber, das Schreiben zu aktivieren (kann aus Sicherheitsgründen standardmäßig oder dauerhaft deaktiviert sein). Speichern müsste schon im Binärmodus erfolgen, damit nicht wild herumkonvertiert wird.

    Nur so eine dumme Idee: Hast du schon probiert (ich rate mal, dass es um PHP geht), den HTTP-Header auf UTF-8 zu setzen?
    Das müsste bei HTML (rate ich mal) ungefähr so aussehen (ohne Gewähr):
    header('Content-type: text/html; charset=utf-8');

    Was sagen andere Browser? Was sagen Texteditoren, wenn man die HTML-Seite (rate ich mal, könnte auch plain text sein) direkt abspeichert und mit ihnen beguckt?

    Edit#2:
    Ich habe jetzt mal geguckt, was das Forum ausgeliefert hat. Weil ich nicht annahm, dass es die Ellipse '…' auch ohne Unicode gibt (in ISO 8859-1 tatsächlich nicht enthalten, aber in Windows-1252 als 85h), hatte ich mich ins Bockshorn jagen lassen. Es ist aber ganz einfach:
    • ist bei ANSI/ISO binär 10010101 -> kein gültiges Zeichen unter UTF-8 -> Fehlersymbol
    … ist bei ANSI/ISO binär 10000101 -> kein gültiges Zeichen unter UTF-8 -> Fehlersymbol
    Unter Einbeziehung von Kompatibilität mit ASCII ist gar nicht notwendig, dass diese Zeichen jemals als UTF-8 vorlagen! Die Fehlersymbole legen nahe, dass es z.B. schon eher Windows-1252 gewesen sein könnte. Im zu ASCII kompatiblen Teil (nur die untersten 7 Bit) liegen sie natürlich nicht, aber nur der ist mit UTF-8 kompatibel. Sobald das oberste Bit gesetzt ist, gibt es ohne Konvertierung zwangsläufig einen Fehler. Ich tippe also darauf, dass das Ausgangsmaterial nicht in UTF-8 vorgelegen hat. Das ANSI-Material geht trotzdem als UTF-8 durch den Konverter, weil die unteren 7 Bit sowieso kompatibel sind, wodurch die unangetastet bleiben. Das eine Bit darüber macht diejenigen Einzelbytes, wo es gesetzt ist (solange sie keinem UTF-8-Startbyte entsprechen und der Rest dahinter nicht auch konform ist) zwar ungültig (hinzugefügt: nur allgemein, jedoch speziell bei diesen Zeichen nicht!), aber irgendwas muss der Konverter rausschieben. Also ignoriert er das, als wären auch diese Zeichen gültig.
    (^Die Sache hat sich längst geklärt, sie sind gültig, siehe Edit#3.)
    Im zweiten Bild passt, dass in Wahrheit z.B. Windows-1252 (was erweitertes ISO 8859-1 ist) angeliefert wurde. Wo ISO 8859-1 angegeben ist, wird sich eine flinke Routine nicht unbedingt dagegen sträuben, die erweiterten Zeichen aus Windows-1252 mit auszugeben. Was sollte sie auch sonst tun. Ich glaube, was oberhalb dieses Edits steht, kannst du schon vergessen, weil der Fall ziemlich klar sein dürfte. Falls du trotzdem Dateien begucken lassen willst, ist das natürlich kein Problem.
    Wie könnte es weitergehen? Den Konverter umdrehen und zu UTF-8 wandeln, würde ich sagen. Ich weiß nicht, ob man anstatt ISO 8859-1 auch (in irgendeiner Form) Windows-1252 angeben kann. Falls die beiden Zeichen, um die es hier geht, nicht funktionieren, würde ich mal danach gucken.
    (Bei LibreOffice sollte wohl dasselbe passiert sein. Aber das wäre zu einfach, als dass man daran denken würde.)

    Edit#3:
    Speziell diese sind nicht ungültig, sondern kompatibel, wie sich herausgestellt hat. Die höherwertigen optionalen Steuerzeichen aus ISO-8859-1 wurden also nicht verquirksmurkst, sondern unter UTF-8 ist ihnen effektiv das Zeichen zum Einleiten einer Zweibyte-Sequenz vorangestellt. Siehe dazu auch meinen nächsten Beitrag. Natürlich erhält man keine allgemein korrekte Konvertierung zu UTF-8, indem man C2h voranstellt, aber dieses ist ein trivialer Spezialfall, wogegen es allgemein eher für einen Fehler spräche, so zu verfahren, weswegen ich darauf kam. Allgemein wäre es ein Fehler, hier jedoch nicht, was weitere Rückschlüsse vereinfachte.
    jabu ist offline Geändert von jabu (21.10.2019 um 03:03 Uhr)

  7. #7 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.800
    Danke für deine Ausführliche Antwort. Das Konvertieren von WINDOWS-1252 zu UTF-8 kommt der Sache schon näher, allerdings wird jetzt neben den eigentlichen Zeichen nur ein zusätzliches angezeigt:

    [Bild: text_windows1252_utf8.jpg]

    EDIT:
    Ich habe noch etwas rumprobiert. Wenn ich von UTF-8 nach LATIN1 und dann von WINDOWS-1252 zu UTF-8 konvertiere, wird es mit charset=UTF-8 richtig angezeigt:

    Code:
    $txtConv = iconv('UTF-8', 'LATIN1', $txt);
    $txtConv = iconv('WINDOWS-1252', 'UTF-8', $txtConv);
    echo "$txtConv";
    Ergebnis:

    [Bild: text_utf_8_latin1_windows1252_utf8.jpg]

    Da ich allerdings nicht weiß warum das funktioniert bin ich etwas besorgt, dass mir das ganze später noch um die Ohren fliegen könnte.

    Der Text als Download zum Testen:
    text-test.txt
    Feuerstern ist offline Geändert von Feuerstern (15.10.2019 um 04:31 Uhr)

  8. #8 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.328
    Das  ist beinahe interessant, denn es ist gleichbedeutend mit einem UTF8-Startbyte einer 2-Byte-Sequenz. Bullet und Ellipse, falls die gemeint sind, wären aber 3-Byte-Sequenzen. Auf das mögliche UTF-8-Startbyte folgen Bullet und Ellipse jedoch jeweils als einzelnes Byte, also wie in WINDOWS-1252 kodiert (nicht wie bei UTF-8, wo 3 Byte erforderlich sind).

    Warum verlinkst du nicht einfach den ursprünglichen Inhalt, um den es geht? Der hatte doch von Anfang an nicht als UTF-8 funktioniert.

    Edit:

    Die Datei, die du mir nun auf anderem Weg gegeben hast, ist hilfreich gewesen. Sie ist, wie du sagtest, als UTF-8 gemeint, vermutlich der Kodierung der Datenbank entsprechend. Einige Zeichen stehen aber (erwartungsgemäß) nicht für das, was bei der Eingabe gemeint war:
    Bei den fehlerhaften Zeichen handelt es sich um solche, die bei Windows-1252, nicht aber z.B. bei ISO-8859-1 oder ISO-8859-15, definiert sind. Der Eingabekonverter wandelte recht wahrscheinlich von ISO-8859-1 oder ISO-8859-15 zu UTF-8, und der Ausgabekonverter kehrte das vermutlich um (wobei die Anwendungsschicht und der User Windows-1252 anstatt ISO-8859-1/15 annahmen).
    Es spricht einiges dafür, dass der Vorgang über die Ein- und Ausgabekonvertierung hinweg transparent erfolgt, also auch bei den Steuerzeichen, für die Windows-1252 eine andere Bedeutung (die hier vom User erwartete) vorsieht. Anscheinend genügt es speziell bei den Steuerzeichen aus ISO-8859-1/15, das Startbyte C2h, welches eine 2-Byte-Sequenz signalisiert, voranzustellen, damit ein gültiges UTF-8-Zeichen daraus wird. UTF-8 ist nicht immer so einfach, das lässt sich nicht pauschal übertragen.
    Es gehen bei dem Abschnitt der Code-Tabelle, wo es zu den offensichtlichen Fehlern gekommen ist, falls das hier gezeigte Mapping stimmt, also keine Informationen verloren, sodass der Vorgang rückgängig gemacht werden kann.

    Also hätten wir als Ausgangspunkt ungefähr dieses:
    Eingabe >> 8859-1_zu_UTF8_Konverter >> (UTF-8)Datenbank >> UTF8_zu_8859-1_Konverter >> Ausgabe

    Weil der Vorgang auch bei den Steuerzeichen umkehrbar ist (s.o.), können auch diese für abweichende Codepages verwendet werden:
    8859-1-Zeichen >> Eingabe >> 8859-1_zu_UTF8_Konverter >> (UTF-8)Datenbank >> UTF8_zu_8859-1_Konverter >> Ausgabe >> 8859-1-Zeichen
    CP1252-Zeichen >> Eingabe >> 8859-1_zu_UTF8_Konverter >> (UTF-8)Datenbank >> UTF8_zu_8859-1_Konverter >> Ausgabe >> CP1252-Zeichen
    Dazu^ ist es natürlich nötig, dass der Browser bei Angabe von ISO-8859-1 trotzdem Windows-1252 nimmt. Das soll wohl inzwischen sogar vom Standard vorgesehen sein, siehe Wikipedia zu Windows-1252. Der effektive Unterschied ist, dass die innere (UTF8-)Ebene im zweiten Fall ungültige bzw. zwangskompatible oder falsche Zeichen enthält, im ersten nicht. Dieser zweite Fall sollte dein Problem beschreiben, am wahrscheinlichsten entweder mit ISO-8859-1 (= Latin-1) oder ISO-8859-15 (= Latin-9).

    Besser wäre also dieses...
    CP1252-Zeichen >> Eingabe >> CP1252_zu_UTF8_Konverter >> UTF8-Datenbank >> UTF8_zu_CP1252_Konverter >> Ausgabe >> CP1252-Zeichen
    ...was anstelle der C1-Steuerzeichen nützliche Zeichen setzt, wie sie in deinem Dokument gemeint sind.

    Es geht um die Werte von 80h...9Fh, welche bei Windows-1252 anstelle der Steuerzeichen die Menge der Zeichen {€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ(und fünfmal nichts)} repräsentieren, siehe Wikipedia zu Windows-1252. Anstatt die UTF-8-Sequenzen dieser Zeichen einzufügen, wurde bei deinem Material das Startbyte C2h, gefolgt vom ursprünglichen Wert aus 80h...9Fh, also einem Steuerzeichen, eingefügt (wie es bei ISO-8859-1/15 richtig wäre, was den Hinweis gibt).

    Da bei UTF-8 Einzelbytes, Startbytes und Folgebytes immer voneinander unterschieden werden können und wegen des einfachen Mappings, sollte sich leicht eine Funktion schreiben lassen, welche diese fehlerhaft kodierten 2-Byte-Sequenzen ekennt und durch die entsprechenden UTF-8-Zeichen ersetzt. Damit sollten sich die Datenbankeinträge reparieren lassen. Allerdings fixt das nicht die seltenen Fälle, wo ISO-8859-15 von WINDOWS-1252 abweicht (falls verwendet wurde). Man sollte also möglichst vorher wissen, was verwendet wurde und die Entscheidung nachher treffen, würde ich vorsichtshalber sagen. Andernfalls könnte es passieren, dass man später nachfixen muss.

    Die vorgenannte Methode hat den Vorteil, dass bei einer Datenbank, die sich irgendwann aus unterschiedlichen Quell-Kodierungen gespeist hat, die Wahrscheinlichkeit, durch die Reparatur etwas kaputtzukonvertieren, vergleichsweise gering ist. Man kann bekanntlich kein Material, welches nicht in die Zielkodierung, z.B. ISO-8859-1, hinein passt, zu dieser wandeln, ohne Informationen zu verlieren. Das könnte z.B. passieren, falls eine andere Quelle, z.B. eine Datei oder ein Modul, der Datenbank schon mal UTF-8-Inhalte (anstatt das sonst bevorzugte WINDOWS-1252) zugespielt hat. Denn im Grunde hast du das hier...
    Zitat Zitat von Feuerstern Beitrag anzeigen
    Ich habe noch etwas rumprobiert. Wenn ich von UTF-8 nach LATIN1 und dann von WINDOWS-1252 zu UTF-8 konvertiere, wird es mit charset=UTF-8 richtig angezeigt
    ...schon richtig gemacht (Begründung s.o.), aber damit nichts verloren geht, müsste garantiert sein, dass wirklich alles Material, welches du so behandelst, über den LATIN1_zu_UTF-8-Konverter ging. Andernfalls, und da liegst du mit deiner Sorge richtig, wären Fehler vorprogrammiert. Wo du sicher bist, dass die Daten über den Konverter gingen, da kanst du ihn tatsächlich umdrehen, um die falsche Konvertierung rückgängig zu machen und die richtige noch einmal vorzunehmen. Du müsstest dann natürlich die richtige Eingangsmaterial-Kodierung herausfinden, wobei Windows-1252 schon die wahrscheinlichste Kodierung ist. Aber was sage ich da, das weißt du selbst. Der Vorteil dieser bzw. deiner Methode ist, dass man den Konverter zum Fixen nicht selber programmieren muss - vorausgesetzt, die Zuordnung stimmt beim betreffenden Material.

    Zur Abgrenzung zwischen 8859-1 und 8859-15, siehe z.B. diese Tabelle bei Wikipedia. Dein Material genügte mir bisher leider nicht für eine Abgrenzung, da ich weder entsprechende Zeichen oder Werte von der einen noch von der anderen exklusiven Menge finden konnte. Aber ich könnte, da ich schon ziemlich unkonzentriert war, etwas übersehen haben. Vielleicht guckst du das mal selber durch. Es wäre z.B. mal interessant, ob du etwas mit dem Euro-Symbo finden kannst. Falls es das gibt, wäre es ziemlich peinlich, ausgerechnet dort zu patzen.

    Ich habe leider ein eingestreutes 'Æ', welches als richtiges UTF-8 vorliegt, gefunden. Woran das liegen könnte, ist bisher ungeklärt.

    Nochmal kurz zusammenfassend zu den Methoden:
    • Die erste Methode, also das selbst programmierte Fixen (so eine Art Korrekturkonverter), welcher nur die bei den Steuerzeichen zu erwartenden Unterschiede behandelt, sehe ich im Vorteil, wo der Aufwand, das irgendwann früher oder woanders mal verwendete Encoding zu ergründen oder einzeln zu behandeln (um Informationsverlust, insbes. bei UTF-8-Eingaben, zu verhindern), zu groß ist. Andere Unterschiede, abseits der Steuerzeichen, blieben dabei aber unberücksichtigt, was weiteres Fixen oder ein Erweitern des Korrekturkonverters erfordern kann. Die feinen Unterschiede zwischen ISO-8859-1, ISO_8859-15 und Windows-1252 kann man der weiter oben verlinkten Tabelle entnehmen.
    • Die zweite Methode (die derjenigen, die du schon verwendet hast, entspricht) vermeidet einigen Aufwand, und sie vermeidet, dass man die feinen Unterschiede der Encodings falsch behandelt, was aber auch hier erfordert, dass man Letztere selektiv behandelt. Wegen dieser Vorteile würde ich der eigentlich den Vorzug geben, aber es muss dann wirklich geklärt sein, dass kein Informationsverlust und keine Verfälschung entsteht. Man sollte daher ggf. Bereiche, die aus UTF-8-Eingaben resultieren, identifizieren und aussparen.

    Den Aufwand, das tatsächliche Encoding herauszufinden, hat man also auch bei der zweiten Methode. Bei der ersten Methode hat man aber eher Glück, falls man sich verschätzt hat, da sie UTF-8-Eingaben nicht verkürzt. Ihr einziger Fehler wäre dann, dass Steuerzeichen aus dem Korrekturbereich, die (hier ausnahmsweise absichtlich) per UTF-8 eingegeben wurden (wie wahrscheinlich ist das? Nicht besonders, würde ich sagen, müsstest du aber selbst entscheiden.) ebenfalls zu Windows-1252 konvertiert werden. Das passiert nicht beim (den Zeichensatz verkürzenden) Umwandeln von aus UTF-8-Eingaben resultierendem UTF-8 zu ISO-8859-1 oder ISO-8859-15 (je nachdem, was zutrifft).
    Falls per UTF-8-Eingaben irgendwas aus der Menge der Zeichen {€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ}, wie sie auch Windows-1252 definiert, verwendet wurde, womit beim Einspielen von Details aus anderen Quellen zu rechnen wäre, dann darf dort natürlich nicht zu ISO-8859-1 gewandelt werden.

    Überlegungen zur Entscheidungsfindung:
    • Falls die (teils defekten, also so, wie sie jetzt sind) UTF-8-Daten weder UTF-8-Zeichen enthalten, welche nicht unter Windows-1252 abbildbar sind, noch solche, die nicht unter ISO-8859-1 abbildbar sind (was eine Suche im UTF8-Modus über alles hinweg klären könnte), dürfte man ohne Informationsverlust und ohne Verfälschung zu ISO-8859-1 konvertieren können, wenn das Ergebnis als Windows-1252 interpretiert wird (gemäß der zweiten Methode). Voraussetzung dafür ist, dass für alle Ein- und Ausgabedaten stets ISO-8859-1 konfiguriert war. Falls das alles zutrifft, ist die zweite Methode (die du schon ausprobiert hast) relativ risikoarm.
      (Nicht unter ISO-8859-1 abbildbar ist auch der benötigte Bereich {€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ}, weswegen nichts daraus als korrekt kodiertes UTF-8 vorkommen darf, sondern nur in der bekannten Falschkodierung!).
    • Falls die (teils defekten, also so, wie sie jetzt sind) UTF-8-Daten doch UTF-8-Zeichen enthalten, welche weder unter Windows-1252 noch unter ISO-8859-1 abbildbar sind, dann sind diese bei konsequent durchgehender ISO-8859-1-Ausgabe niemals angezeigt worden. Falls man die zuvor ausgesparten Zeichen jetzt aber haben will, bliebe einem bei eingebetteten Zeichen nur die erste Methode übrig, wogegen bei klar abgrenzbaren Bereichen auch selektiv vorgegangen werden könnte. Man kann die erste Methode in ihrer einfachsten Form, also nur mit Ersetzung der mit C2h eingeleiteten Sequenz, pauschal auf alles anwenden, wenn gewährleistet ist, dass neben direkten oder sonst wie korrekten (also auf anderem Weg erfolgten) UTF-8-Eingaben der einzige andere Weg immer über ISO-8859-1 erfolgt ist und die Anwendungs- und Userschicht immer Windows-1252 (oder ihr ISO-8859-1-Subset) gemeint hat (was immerhin naheliegt). Da mit der pauschalen Anwendung der ersten Methode plötzlich auch Zeichen dargestellt werden können, die vorher nicht dargestellt werden konnten, ist eine Voraussetzung, dass diese nicht als unerwünscht bzw. schädlich gelten dürfen.

    Puh, das muss erst mal sacken, aber so kompliziert, wie man anhand der Textmenge hier vielleicht meinen könnte, ist es nicht.
    jabu ist offline Geändert von jabu (16.10.2019 um 12:25 Uhr)

  9. #9 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.800
    Danke für deine Hilfe jabu. Ich werde erstmal alle Texte nach dem Schema UTF-8->LATIN1, WINDOWS-1252->UTF-8 konvertieren und dann mal Stichprobenartig schauen ob das passt. Zur Not halte ich ein Backup vom aktuellen Stand bereit. Mit etwas Glück reicht das dann schon.
    Feuerstern ist offline

  10. #10 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.328
    Zitat Zitat von Feuerstern Beitrag anzeigen
    Danke für deine Hilfe jabu. Ich werde erstmal alle Texte nach dem Schema UTF-8->LATIN1, WINDOWS-1252->UTF-8 konvertieren und dann mal Stichprobenartig schauen ob das passt. Zur Not halte ich ein Backup vom aktuellen Stand bereit. Mit etwas Glück reicht das dann schon.
    Ja, soweit die Außenwelt immer nur ISO-8859-1 (ohne Steuerzeichen hineinzumogeln, die nicht auch WINDOWS-1252 an derselben Position hat, denn so lange bliebe es eine Untermenge von WINDOWS-1252) oder WINDOWS-1252 gesprochen hat, müsste das funktionieren.

    Hoffentlich passt auch der Rest zu UTF-8. Zum Beispiel sollte man sich wohl vergewissern wollen, dass default_charset = "UTF-8" in der php.ini (falls nicht schon angegeben) nicht zu unlösbaren Problemen führt. Aber auch lösbare können nerven oder sogar gefährlich werden:
    Wegen der unterschiedlichen Anzahl an Bytes je Zeichen bei UTF-8 wird bei der Umstellung das Thema Sicherheit und Funktion ganz neu eröffnet. Man sollte sich vergewissern, dass zwischen der Anzahl der dargestellten Zeichen und belegten Puffergrößen entsprechend unterschieden wird. Wo vorher ein Zeichen ein Byte belegte, können es nun mehrere sein, ohne dass man im Voraus wüsste, wieviele.
    Man braucht also Multibyte-Funktionen, die die Pufferlängen vorab berechnen. Damit sie das können, muss man sie wissen lassen, entweder implizit oder explizit, dass sie mit UTF-8 arbeiten sollen. Damit es auch solche wissen, denen man es nicht explizit sagen kann bzw. weil man es vergessen könnte, möchte man UTF-8 als Standard einstellen.
    Das entbindet aber nicht vor der Verantwortung dafür, solche Funktionen bzw. Stellen im Code, die noch davon ausgehen, dass ein Zeichen ein Byte belegt, allesamt aufzuspüren und nötigenfalls anzupassen.

    Das Dokument in UTF-8 zu verfassen und entsprechend zu deklarieren, ist eine Sache, das Backend für UTF-8 fit zu machen, eine andere. Falls ein Text an falscher Stelle abgeschnitten wird, auch wenn es nur bei selten bzw. bei bestimmten Zeichen vorkommt, so ist das ein typisches Indiz für solche Probleme. Man darf das dann keinesfalls ungeprüft auf sich beruhen lassen, vor allem dort nicht, wo Benutzereingaben den Inhalt beeinflussen können. Was sich ausnutzen lässt, wird auch irgendwann ausgenutzt werden. Mit Glück stürzt bloß das Skript ab, mit Pech wird eine Sitzung übernommen, oder es werden klammheimlich sensible Daten kopiert. Zwar sollte die Architektur solche direkten Kopplungen möglichst unterbinden, aber das kann sie nicht immer überall.
    Die Filter, die sicherheitshalber bestimmte Zeichen oder Zeichenfolgen wegfiltern (z.B. um das Einschleusen von JavaScript zu unterbinden), sind in dem Zuge auch zu überprüfen. Möglicherweise wurde dafür bisher zu wenig getan, was durchaus auch an den Besonderheiten verschiedener Kodierungen gelegen haben könnte, die mit UTF-8 zum Glück wegfallen. Wenn man Code oder die Bedingungen, unter denen er ausgeführt wird, verändert, übernimmt man auch Verantwortung dafür.

    Allgemein sollte das hier schon einigermaßen gut über Multibyte-Funktionen informieren:
    https://www.php.net/manual/de/ref.mbstring.php

    Ein einfaches Beispiel:
    mb_strlen (string $str [, string $encoding = mb_internal_encoding() ]) : int
    gibt die Anzahl der Zeichen zurück, wogegen
    strlen (string $string) : int
    die Anzahl der Bytes zurückgibt (eine evtl. benötigte Terminierung mit "\0", für die ein weiteres Byte erforderlich ist, nicht eingerechnet).

    Falls das System schon die ganze Zeit über mit UTF-8 gearbeitet und lediglich zum Ausliefern und Annehmen konvertiert hat, dann solltest du es vergleichsweise leicht haben. Falls in der php.ini nicht UTF-8 angegeben ist (s.o.), ist eher nicht davon auszugehen.
    jabu ist offline

  11. #11 Zitieren
    Ritter Avatar von Feuerstern
    Registriert seit
    Sep 2007
    Beiträge
    1.800
    Das gesamte System ist seit jeher auf UTF-8 ausgelegt. Bisher war das auch kein Problem, nur jetzt bei dem Versuch die externen Texte zu importieren kam es zu den Problemen bei der Darstellung der Inhalte.
    Feuerstern ist offline

  12. #12 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.328
    Zitat Zitat von Feuerstern Beitrag anzeigen
    Das gesamte System ist seit jeher auf UTF-8 ausgelegt. Bisher war das auch kein Problem, nur jetzt bei dem Versuch die externen Texte zu importieren kam es zu den Problemen bei der Darstellung der Inhalte.
    Das beruhigt ungemein.
    jabu ist offline

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •