Text Konvertierung

  • Moin,

    um noch einmal auf das ß zurückzukommen:

    Der Standard-Zeichensatz für englische und deutsche Windows-Versionen ist CP1252. Dieser Zeichensatz enthält das ß auf Position DF. Wenn die Konvertierung nicht gelingt, scheint mir das Prolem eher hier zu liegen:

    é,ü,ö,Ã,ä,è

    é,ü,ö,ß,ä,è

    Hammersbacher StraÃe

    Die UTF-8 Codierung für das Zeichen ß ist kein einzelnes Ã, sondern die Folge ß. Das Zeichen à leitet immer eine zwei byte lange Folge ein, die zusammen ein Zeichen ergeben.

    In Deinem Fall ist also entweder schon beim Erstellen des Seiteninhalts bei der UTF-8 Kodierung etwas vermasselt worden oder das fehlende Ÿ wird in Deinem Skript entfernt.

  • Klingt plausibel, da dies bei allen anderen Sonderzeichen ja der Fall ist.

    Aber warum (ausgerechnet) hier das fehlt weiß ich leider nicht. Wie gesagt das ist das was bei mir direkt in die Datei geschrieben wurde. Aber dann muss ich wohl mit der aktuellen "Lösung" leben.

  • Es könnte sein, dass irgendwer zwischenfurch versucht, die originale UTF-8 Kodierung als ISO_8859-1 zu interpretieren. Da ist es das zweite Zeichen für das ß (das Ÿ mit den Code 9F nicht als Zeichen vorhanden. Du schreibst:

    Zitat

    Ich arbeite bei mir in Autoit immer mit einer anderen Codierung, da ich das für ein weiterführendes Tool brauche (99% meiner Scripte versorgen dieses, daher per Standard auf anderer Codierung eingestellt).

    Kann es damit zusammenhängen?

    Einmal editiert, zuletzt von Velted (9. Januar 2023 um 10:54) aus folgendem Grund: Code für Ÿ korrigiert!

  • Ich vermute es.

    Scite ist bei mir für die CodePage auf Unicode (code.page=65001 bzw. output.code.page=65001) in den global properties eingestellt.

    Ich musste das umstellen, da ich die finalen Daten mit einem Programm, das mit Lazarus (Pascal) geschrieben wurde, zu verarbeiten.

  • Erfahrungsgemäß funktioniert das nicht immer so wie man sich das vorstellt.

    Ich kenne schnöde DOS Zeichensätze die sich mal so mal so darstellen. Daher habe ich mir angewöhnt alles was ich mache in Autoit ist UDF 8. Wenn der Output nicht so ist wie ich mir das vorstelle - wird entsprechend gefiltert. Basta. Ich habe es aufgegeben das ergründen zu wollen - siehe dazu Andys Beitrag.

    LG

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Moombas 9. Januar 2023 um 14:59

    Hat den Titel des Themas von „Text Konverierung“ zu „Text Konvertierung“ geändert.
  • Also eben nochmal geschaut, ich ersetze mit Stringreplace �? durch ein ß.

    In der Datei steht dies als à im Original (UTF8) und wird dann zum oben genannten nach dem StringtoBinary() bzw. BinarytoString().

  • In der Datei steht dies als à im Original (UTF8)

    Hab den Thread mal kurz überflogen. Was aus meiner Sicht wichtig ist: WIE schaust du dir die Datei an? In einem Editor - kann sein dass dort falsch dargestellt wird. In SciTE-Output? - dito.

    Was tatsächlich enthalten ist, sagt dir ausschließlich ein Hex-Editor.

    Denn wenn du schreibst, dass in der Datei nur à steht, dann betrachtest du die Datei nicht in UTF8, sondern in ANSI. Die Bytefolge für ß (in UTF8 Kodierung) siehst du im Hex-Editor als: C3 9F.

  • Interessant vermurkst. :D

    Statt

    C3 9F wurde

    C3 83 C2 9F eingefügt.

    Das ist dann auch nicht mehr interpretierbar. Bleibt nur die Frage nach dem Warum. :/

    Wenn ich richtig gesehen habe, hast du die Daten erstmals im Array und schreibst diese dann mit _FileWriteFromArray weg.

    Hier würde ich ansetzen und nicht die Funktion nutzen, sondern mal selbst durch das Array iterieren. Jeden Eintrag mit StringToBinary wandeln und dann angucken was drin ist. Ggf. eine eigene Schreibfunktion erstellen.

  • Moin,

    das habe ich bisher übersehen. Wenn Du im StringReplace() �? ersetzt, werden zwei Zeichen durch ein Zeichen ersetzt. Wenn danach nichts fehlt, wird das ß ursprünglich auch durch zwei Zeichen dargestellt. Kannst Du mal zeigen, wie der Text vor der Konvertierung aussieht?

    Edit: Zu spät!

  • Das kann an jeder Strassenecke passieren!

    Was Du brauchst ist nicht die Erkenntniss was in welchem Editor wie aussieht - sondern wie sieht Dein Ergebnis im ZIELPROGRAMM aus!!!!

    LG

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Wie gesagt, Peter S. Taler es gibt ja einen Workaround.

    Velted  BugFix : Ich verwende ja nie die Daten aus der Datei um sie weiter zu verarbeiten, sondern immer das was ich 1:1 im Array drin stehen habe, das in der bereits geposteten Abfrage entsteht und wird an über die Funktion ja zurückgegeben und erst dann in der Datei zusätzlich abgelegt. Das speichern in die Datei ist nur zur Sicherheit/Testen/Prüfen.

    Danach wird das Array nur nach den erforderlichen Werten durchsucht und ein neues mit diesen Daten erstellt und später als Finaler Datensatz gespeichert.

    Da hier 1:1 die Daten aus der Abfrage genommen werden, werden sie natürlich auch "falsch" übernommen.

    Beim Test aus diesen übergebenen Daten, ist es dort bereits (nach Umwandlung in Hex) C3 83 C2 9F.

  • Also ich glaube ich bleibe bei der aktuellen "Lösung".

    Ist halt so, schade nur das dort fix eine gewisse codierung genommen wird, die man nciht beeinflussen kann.

  • Ich denke ich konnte das Rätsel nun lösen:
    Stutzig bin ich geworden, dass aus C3 9F nicht zu C3 83 C5 B8 in der Datei wird.
    Das würde man nämlich erhalten, wenn man UTF-8 kodierte Daten als ANSI interpretiert und diesen interpretierten Ergebnisstring dann wieder per UTF-8 kodiert abspeichert.

    Stattdessen erhielt Moombas ja aber C3 83 C2 9F.

    Daher war klar, dass eine andere Codepage als ANSI verwendet wurde, wo das Zeichen an der Stelle 9F ein anderes ist, welches dann wiederrum bei UTF-8 an einer anderen Stelle liegt.

    Und tatsächlich - die gesuchte Codepage ist iso88591-1.

    Hier erstmal das Skript um aus einem "ß" einen Binary mit C3 83 C2 9F zu erzeugen:

    Nun wissen wir also was zu tun ist um die Datei von Moombas wieder korrekt einzulesen:

    Einmal editiert, zuletzt von AspirinJunkie (10. Januar 2023 um 14:57)

  • Nachtrag: Ich konnte die Codeopage auslesen die winhttp nutzt (65001 per Default), kann sie aber auch im Http Objekt ändern per $oHTTP.Option(2) = ???

    AspirinJunkie : Welche Codepage hattest du oben gepostet, die da genutzt wird? Eventuell funktioniert es ja diese hier zu verwenden?

    Geht deine aktuelle Lösung ohne eine externe Datei? Die Datei ist für mich ja zur weiteren Verarbeitung eigentlich nicht gedacht.

    Einmal editiert, zuletzt von Moombas (10. Januar 2023 um 13:26)

  • 28591 (ist iso-8859-1)

    Geht deine aktuelle Lösung ohne eine externe Datei? Die Datei ist für mich ja zur weiteren Verarbeitung eigentlich nicht gedacht.

    Ja klar.
    Hier im Beispiel wird der String aus der Datei gelesen.
    Wo der herkommt ist im Grunde wurscht. Es geht um die Variable $sTmp.
    Wenn die auch so irgendwo anders herkommt bei dir sollte es auch damit klappen.