Hallo zusammen,

ich parse Google-Seiten nach den Namen von Darstellern, wobei viele
Namen Akzente enthalten. Die Akzente haben einmal einen Ascii Code
bis 255, und manchmal sind die Zeichen als Unicode in 2 Bytes codiert.

Ich habe nun Probleme damit, zu erkennen, ob solche 2 Byte Akzente in
einem String enthalten sind. Bei den meisten Akzenten hat das erste
Byte den Ascii-Code 195,196,197 oder 226. Das werte ich nun aus, und
die Konvertierung von Namen mit Akzenten funktioniert eigentlich
bestens.

Leider finde ich meine Funktion zur Erkennung dieser 2 Byte Akzente
irgendwie stümperhaft, und frage mich, ob es keine Funktion gibt, mit
der man zuverlässig erkennen kann, ob ein String 2 Byte Unicode enthält.

Hat vielleicht jemand einen Tip für mich?

Gruß Klaus

Hallo Klaus,

Am 13.03.2024 um 16:57 schrieb Klaus Ketelaer:
> Hallo zusammen,
>
> ich parse Google-Seiten nach den Namen von Darstellern, wobei viele
> Namen Akzente enthalten. Die Akzente haben einmal einen Ascii Code
> bis 255, und manchmal sind die Zeichen als Unicode in 2 Bytes codiert.
>
> Ich habe nun Probleme damit, zu erkennen, ob solche 2 Byte Akzente in
> einem String enthalten sind. Bei den meisten Akzenten hat das erste
> Byte den Ascii-Code 195,196,197 oder 226. Das werte ich nun aus, und
> die Konvertierung von Namen mit Akzenten funktioniert eigentlich
> bestens.
>
> Leider finde ich meine Funktion zur Erkennung dieser 2 Byte Akzente
> irgendwie stümperhaft, und frage mich, ob es keine Funktion gibt, mit
> der man zuverlässig erkennen kann, ob ein String 2 Byte Unicode enthält.
>
> Hat vielleicht jemand einen Tip für mich?
>

bist du dir sicher mit Unicode? Das verwenden Webseiten eher selten.
Meistens sind die Seiten doch UTF-8 codiert. Wohin konvertierst du die
Akzente? Bist du dir sicher, daß es für alle Unicode-Akzente eine ANSI
Entsprechung gibt?

Grüße
Ulrich

Btw.: ASCII Code hat übrigens nur 7-Bit.

Am 13.03.2024 um 20:31 schrieb Ulrich Möller:
> Hallo Klaus,
Hallo Ulrich,
> Am 13.03.2024 um 16:57 schrieb Klaus Ketelaer:
>> Hallo zusammen,
>>
>> ich parse Google-Seiten nach den Namen von Darstellern, wobei viele
>> Namen Akzente enthalten. Die Akzente haben einmal einen Ascii Code
>> bis 255, und manchmal sind die Zeichen als Unicode in 2 Bytes codiert.
>>
>> Ich habe nun Probleme damit, zu erkennen, ob solche 2 Byte Akzente in
>> einem String enthalten sind. Bei den meisten Akzenten hat das erste
>> Byte den Ascii-Code 195,196,197 oder 226. Das werte ich nun aus, und
>> die Konvertierung von Namen mit Akzenten funktioniert eigentlich
>> bestens.
>>
>> Leider finde ich meine Funktion zur Erkennung dieser 2 Byte Akzente
>> irgendwie stümperhaft, und frage mich, ob es keine Funktion gibt, mit
>> der man zuverlässig erkennen kann, ob ein String 2 Byte Unicode enthält.
>>
>> Hat vielleicht jemand einen Tip für mich?
>>
>
> bist du dir sicher mit Unicode?
Nein, ich bezeichne nur die unzähligen Codepages einfach als Unicode.

Es kommt auch erst einmal nicht darauf an, worin die Webseiten codiert
sind, sondern was ich bekomme, wenn ich die gespeicherten Webseiten von
der Festplatte einlese.

Ich kann auch nicht die gesamte Seite einfach mal in UTF8 umwandeln,
sondern muss mir das herausangeln, was zwischen gewissen Tags steht.

Da bekomme ich ANSI und ASCII und HTML und Unicode und Base64 usw.
€ & &quote; € È› Ș È™ ʹ í ć Ä‘ »…

> Das verwenden Webseiten eher selten.
> Meistens sind die Seiten doch UTF-8 codiert.
Ja, das stimmt, aber um aus den Textpassagen UTF8 zu machen, muss
ich erst einmal wissen, was darin steht.

Ich darf den Text nur dann in UTF8 wandeln, wenn Zeichen wie
ț Ș ș ʹ í ć đ darin enthalten sind. Wenn ich den Text
wandle, ohne dass "Unicode" darin steht, dann zerschieße ich
den Text.

> Wohin konvertierst du die
> Akzente?
Ich konvertiere die Akzente in Ascii-Code. In 7 Bit Code. Bei
mir gibt es halt keinen Raúl Méndez, sondern lediglich einen
Raul Mendez.

> Bist du dir sicher, daß es für alle Unicode-Akzente eine ANSI
> Entsprechung gibt?
Ich bin mir sicher, dass es für keinen Akzent eine Entsprechung in
meinem ASCII-Code gibt. Genau das ist der Sinn der Sache. Akzente
zu entfernen.

Bei meiner Frage geht es einfach nur darum, ob es einen sicheren
Weg gibt Zeichen wie ț Ș ș ʹ í ć đ zu ermitteln, denn bei
den Zeichen könnte es sich theoretisch auch einfach um 2 ANSI-
Zeichen handeln.

Es geht darum diese idiotische Funktion zu ersetzen:

Private Function IsUnicode(ByVal szText As String) As Boolean
Dim i As Integer
Dim bFound As Boolean

If InStr(szText, Chr$(195)) Then
bFound = True
ElseIf InStr(szText, Chr$(196)) Then
Debug.Assert False
bFound = True
ElseIf InStr(szText, Chr$(197)) Then
bFound = True
ElseIf InStr(szText, Chr$(226)) Then
bFound = True
Else
For i = 1 To Len(szText)
If AscW(Mid$(szText, i, 1)) > 255 Then
bFound = True
Exit For
End If
Next i
End If

IsUnicode = bFound
End Function

Gib einfach mal "Besetzung von Narcos" bei Google ein, klicke auf
mehr anzeigen, und dann speichere die Seite nal. Dann weisst du,
was ich parse. Wie Du dann sehen kannst gibt sich Google alle Mühe,
genau das zu verhindern.

Hallo Klaus,

ich habe mir die Seite mal angesehen und sie ist in UFT-8 kodiert.

Für diese Aufgaben habe ich normalerweise die beiden Bibliotheken MSHTML
und MSXML verwendet, welche mit UTF-8 kodierte Seiten umgehen können.
Probleme mit Unicode habe ich noch nicht bekommen. Bei UTF-8 können
Zeichen mehrere Bytes groß sein, bei Unicode-16 sind es immer 2 Byte.
Ein freistehendes Akut wird durch U+00A0 U+00B0 dargestellt, ansonsten
gilt die Reihenfolge, zuerst Basisbuchstabe und dann diakritischen
Zeichen. Das sollte in einem Bytearray eigentlich leicht zu finden sein.

Näheres: https://de.wikipedia.org/wiki/Diakritisches_Zeichen#Unicode

Gruß Ulrich

Am 14.03.2024 um 12:09 schrieb Ulrich Möller:
> Hallo Klaus,
Hallo Ulrich,
> ich habe mir die Seite mal angesehen und sie ist in UFT-8 kodiert.
>
> Für diese Aufgaben habe ich normalerweise die beiden Bibliotheken MSHTML
> und MSXML verwendet, welche mit UTF-8 kodierte Seiten umgehen können.
> Probleme mit Unicode habe ich noch nicht bekommen. Bei UTF-8 können
> Zeichen mehrere Bytes groß sein, bei Unicode-16 sind es immer 2 Byte.
> Ein freistehendes Akut wird durch U+00A0 U+00B0 dargestellt, ansonsten
> gilt die Reihenfolge, zuerst Basisbuchstabe und dann diakritischen
> Zeichen. Das sollte in einem Bytearray eigentlich leicht zu finden sein.
>
> Näheres: https://de.wikipedia.org/wiki/Diakritisches_Zeichen#Unicode
>
Der überwiegende Teil aller Namen besteht aus ASCII-Zeichen im
Bereich 48 bis 57, 97 bis 122. Deutsche Namen sind ab und zu im
ANSI-Format, und enthalten ggf. die Zeichen 228, 246, 252 und 223.
(Alles in Kleinschrift)

Wenn dies nicht zutrifft, dann werden die Namen auf häufig
enthaltene HTML-Codierungen geparst und entsprechend gesäubert.

Ja, und danach, muss ich wissen, ob Unicode codierte Zeichen
enthalten sind, sodass ich meine Funktion UTF8_To_Ansi() aufrufen
muss, weil halt die Seiten meist in UTF8 codiert wurden. (Wenn
ich mir Namen aus Russland "angle", muss ich andere Codepages
verwenden.)

Die bisherige Konvertierung von über 200.000 Namen hat ergeben,
dass die codierten Zeichen stets mit &HC3 bis &HC5 beginnen, was
den von mir erwähnten Wertne 195-198 entspricht. Danach folgt ein
weiteres Zeichen, das dann zusammen mit dem ersten Zeichen das
Unicode-Zeichen bildet.
Und nur dann darf ich den String in UTF8 wandeln. Wenn ich den
String ungeachtet dessen konvertiere, dann zerstöre ich alle evtl.
enthaltenen ANSI-Zeichen, incl. Deutscher Umlaute.

Daher muss ich prüfen, ob solche Zeichen enthalten sind, was ich
mit der geposteten Function tue, die ich jedoch als recht
dilettantisch empfinde.

Bis hierhin interessieren mich Akzente nicht die Bohne.

Erst wenn der Name gesäubert oder konvertiert wurde, wird der
gesamte Name durch eine Übersetzungstabelle gejagt, welche alle
Akzente entfernt.

Danach extrahiere ich die BASE64-Bilder und speichere sie unter
dem gesäuberten Namen ab, oder wenn ich Glück habe, liegt das
Bild als Datei vor, und ich muss er nur umbenennen und verschieben.
Der Name wandert dann in die Datenbank, sofern er dort nicht
vorhanden ist.

Mein Frage bezog sich eigentlich nur darauf, ob es eine Funktion
gibt, die sicher und effizient erkennt, ob ein String Unicode-
Zeichen enthält. Das ist alles;-)

Gruß Klaus

Am Thu, 14 Mar 2024 16:58:08 +0100 schrieb Klaus Ketelaer:

> Mein Frage bezog sich eigentlich nur darauf, ob es eine Funktion
> gibt, die sicher und effizient erkennt, ob ein String Unicode-
> Zeichen enthält. Das ist alles;-)

Gibt es. Aber das ist in diesem Sinne keine "Funktion". Sondern: man
entnimmt dem Header des heruntergeladenen HTML-Dokuments, welche Codierung
hier verwendet wird.

Das ist ein bisserl ähnlich, wie wenn Preise in einem Supermarkt mit
Beträgen, aber ohne Währung ausgezeichnet sind. Je nach Umgebung kann klar
sein, was gemeint ist, oder eben auch nicht so ganz. In unklaren
Situationen kommt man mit Heuristik ggfs. auch recht weit, aber "sicher und
effizient" ist das dann eben nicht mehr.

Eine ander Analogie wären Koordinaten ohne Angabe des Koordinatensystems.
Wenn dabeisteht, welches System verwendet wird, empfiehlt es sich, diese
Info dann auch zu verwerten. Das ist dann sicher und effizient.

--
Viele Grüße,
Wolfgang
https://www.enzinger.net

Am Tue, 16 Apr 2024 00:05:09 +0200 schrieb Wolfgang Εnzinger:

> Am Thu, 14 Mar 2024 16:58:08 +0100 schrieb Klaus Ketelaer:
>
>> Mein Frage bezog sich eigentlich nur darauf, ob es eine Funktion
>> gibt, die sicher und effizient erkennt, ob ein String Unicode-
>> Zeichen enthält. Das ist alles;-)
>
> Gibt es. Aber das ist in diesem Sinne keine "Funktion". Sondern: man
> entnimmt dem Header des heruntergeladenen HTML-Dokuments, welche Codierung
> hier verwendet wird.
>
> Das ist ein bisserl ähnlich, wie wenn Preise in einem Supermarkt mit
> Beträgen, aber ohne Währung ausgezeichnet sind. Je nach Umgebung kann klar
> sein, was gemeint ist, oder eben auch nicht so ganz. In unklaren
> Situationen kommt man mit Heuristik ggfs. auch recht weit, aber "sicher und
> effizient" ist das dann eben nicht mehr.
>
> Eine ander Analogie wären Koordinaten ohne Angabe des Koordinatensystems.
> Wenn dabeisteht, welches System verwendet wird, empfiehlt es sich, diese
> Info dann auch zu verwerten. Das ist dann sicher und effizient.

Eher heuristisch (oder wenn man will: statistisch) geht denn auch die
Funktion

IsTextUnicode function (winbase.h)
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-istextunicode

vor, aber die obligatorische Warnung steht gleich mit dabei:

"The IS_TEXT_UNICODE_STATISTICS and IS_TEXT_UNICODE_REVERSE_STATISTICS
tests use statistical analysis. These tests are not foolproof. The
statistical tests assume certain amounts of variation between low and high
bytes in a string, and some ASCII strings can slip through."

--
Viele Grüße,
Wolfgang
https://www.enzinger.net