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:

Zitat von Moombas

é,ü,ö,Ã,ä,è

é,ü,ö,ß,ä,è

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.

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?

65001 ist die numerische Bezeichnung für UTF-8.

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

Kannst Du vielleicht doch ein Beispiel für den ursprünglich von InetRead() gelieferten Text mit Umlauten und ß im Hex-Format einstellen?

Zitat von Moombas

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.

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!

C3 83 C2 9F entsteht, wenn man C3 9F in UTF-8 übersetzt. Bleibt nur noch die Frage, wo bzw. wann das passiert.

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

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:

#include <WinAPIConv.au3>

; Ausgangsstring liegt in UTF-8 Kodierung vor:
$sString = "ß"
$bAusgang = StringToBinary($sString, 4)    ; = C3 F9

; Interpretation des Binary C3 F9 als wäre es ein iso-8859-1 kodierter String:
$tTmp = _Binary2WChar($bAusgang)
$sIso88591 = _WinAPI_MultiByteToWideChar($tTmp, 28591, 0, True)
; Ergebnis: Ein String mit den Zeichen à (195 = C3) und etwas undefiniertem (steht an Stelle 159 wo im ANSI das Ÿ steht)

; Dieser String bestehend aus den 2 Zeichen wovon eines nicht darstellbar ist wieder in UTF-8 konvertieren:
$bTmp = StringToBinary($sIso88591, 4)
MsgBox(0,"Binary-Darstellung des kodierten Strings", $bTmp)


Func _Binary2WChar($bBin)
    Local $tTmp = DllStructCreate("Byte[" & BinaryLen($bBin) & "]")
    DllStructSetData($tTmp, 1, $bBin)
    Return $tTmp
EndFunc

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

#include <WinAPIConv.au3>

; Ausgangsdaten als UTF-8 interpretiert laden:
$hFile = FileOpen("Original_Data.txt", 256)
$sTmp = FileRead($hFile)
FileClose($hFile)

; es würde hier auch kürzer gehen, da FileRead bei dieser Datei UTF-8 annimmt:
;  $sTmp = FileRead("Original_Data.txt")

; Konvertierung in iso-8859-1 Kodierung:
$bTmp = _WinAPI_WideCharToMultiByte($sTmp, 28591, True, True)

; Interpretation des Binary als UTF-8:
$sTmp = BinaryToString($bTmp, 4)

; Ausgabe des Strings:
MsgBox(0,"",$sTmp)

28591 (ist iso-8859-1)

Zitat von Moombas

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.