Encoding (ASCII/UTF-8/xxx) richtig erkennen

[kaju74]

Hi.

Ich weiß, dass die 100% Erkennung einer Datei bzgl. ihres Formates nicht so einfach ist:

http://codesnipers.com/?q=node/68

Gibt es dazu bereits für Delphi eine entsprechende Implementation, die dieses Algorithmus
(oder vergleichbares) verwendet, um herauszufinden, ob eine Datei z.B. im Unicode-Format
vorliegt? Auf ein BOM kann man sich ja nicht verlassen...

Danke & lG,
Marc

[EgonHugeist]

Zitat:

Zitat von kaju74 (Beitrag 1286534)

Hi.
...Auf ein BOM kann man sich ja nicht verlassen...

Wenn du dich nicht auf die BOM verlassen kannst, worauf dann?

Es ist eigentlich unmöglich Unicode-Char(full 2Byte, eg. 2. Byte <> 0) mit diversenen !Ansi!-Sequencen auseinander zu halten.

Ich habe mich damit auch herum ärgern müssen doch irgendetwas 100% sicheres -> NOPE.

Was sicher funzte sind Sachen wie StrLen() (wenn du ein #0 an den Stream angehängt hast), welches schon bei den ersten Unicode-Chars eine andere Länge als Stream.Size zurück gibt(knallt aber bei RTF-formatierten Daten).

Dann wäre da noch sowas wie:
NotUnicode = (Stream.Size mod 2 <> 0) oder so.
Und zu guter letzt:
DetectUTF8Encoding in [etASCII,etUTF8] welches ziehmlich sicher wäre.

Alles andere ist das Befragen der Kristallkugel, IMHO.

[Sir Rufo]

Also es gibt da schon was Besseres, aber eben keine 100% Trefferquote (aus diversen Gründen):
TEncoding.GetBufferEncoding
Hier ist eben Wissen Macht, bzw. es sollte dem Anwender die Möglichkeit gegeben werden, die CodePage zu wählen/wechseln (inkl. einer Live-Vorschau). Wenn es dann so aussieht wie erwartet, dann kann er ja weitermachen.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1286537)

Also es gibt da schon was Besseres, aber eben keine 100% Trefferquote (aus diversen Gründen):
TEncoding.GetBufferEncoding

Na ja, so viel besser ist das aber nun auch wieder nicht:

Zitat:

Zitat von http://docwiki.embarcadero.com/Libraries/XE7/en/System.SysUtils.TEncoding.GetBufferEncoding

GetBufferEncoding examines the Buffer parameter and determines its encoding by looking for known byte order marks (BOM). If the buffer doesn't contain a byte order mark for one of the standard encodings, the Default standard encoding is returned.

Ohne BOM kommt halt auch nur TEncoding.Default zurück und das ist je nach Plattform ANSI oder UTF8.

[p80286]

Wenn der ganze Text vorliegt sollte es eigentlich möglich sein.
Wenn die Anzahl der x00-Bytes etwa die Hälfte aller Bytes ist, sollte es sich um 16-Bit Code handeln. Gibt es eine rel. hohe Anzahl von xC2-Bytes sollte es sich um UTF8-Kodierung handeln.
Das gilt allerdings nur für einen Europäischen Text.

Gruß
K-H

[EgonHugeist]

@Uwe,

so ist es. Die fertigen Klassen, oder deren Wissen, stoßen auch hier auf seine Grenzen.

@Sir Rufo,

mag sein, daß da mehr Erfahrung ins Spiel kommt, grundsätzlich jedoch tested Emba auf BOM, da bin ich ja schon einige Schritte oder Ideen weiter.

Wenn du jedoch eine Automatisierung einbauen willst(wovon ich ausgehe, daß der TE das vor hat), wirst du doch deinen Usern nicht zumuten, irgenwelche Lesbarkeits-Tests, wie "Schauts noch chinesisch aus? Dann klicke weiter, bis der Augenkrebs verschwunden ist.." zumuten oder?:gruebel: :zwinker:

@p80286

UTF8 und ASCII7-Bit lassen sich sich !nahezu! 100%ig erkennen, da sie einer Normung unterliegen. Einzige Ausnahme, welche mir einfallen würden, wäre ein 2Byte-WideChar Folge, welche gerade am Anfang des Streams einen Treffer generieren. Desto länger der gescannte Text, desto sicherer werden die Ergebnisse.

Aber grundsätzlich: NEIN es ist unmöglich 100% sicher zu sein. Worst case sind wie gesagt, 2Byte Wide-Chars, wo das 2. Byte <> #0 belegt ist. Hier ist es meiner bescheiden Meinung nach unmöglich eine Ansi(CP <> UTF8/ASCII7)Encodierung mit Unicode auseinander zu halten..

Schaut euch mal die Tabellen auf Unicode.org oder Wikipedia an. Zufalls matches sind eigentlich schon vorprogrammiert.

[Sir Rufo]

Wenn ich keine 100% Erkennung garantieren kann, dann bekommt der Benutzer die Möglichkeit dort einzugreifen. Das ist besser als irgendwas unkontrolliert in die Verarbeitung zu werfen.

Ja, das TEcoding ist kein Zauberstab ... das Testen auf eine gerade/ungerade Anzahl auch nicht. Ok, man kann es nicht eindeutig feststellen, sondern nur grob schätzen unter Annahme eines Kontexts (Land, Ursprung, wie war das letztens, ...). Darum ist die Möglichkeit des manuellen Eingriffs zwingend notwendig.

[EgonHugeist]

Ist richtig und auch Fazit meiner Ausführungen...

Grundsätzlich bleibt wirklich nichts anderes übrig, als eben dieses dem Enduser zuzumuten.
Schwieriger wirds aber, wenn sich die Ansi-Encodierungen auch noch anfangen teilweise überschneiden und im erst Kapitel 20, Abstatz 5 endlich mal ein eindeutig unlesbares Ergebnis ergibt. :stupid:

Der TE jedoch stellt den BOM als unzuverlässig dar, somit wollte ich ihm die Augen öffnen, was da seine Optionen sind... eigentlich nur Mumpiz. Mehr fällt mir da jedoch nicht ein.

Wäre aber ebenfalls dankbar, wenn da jemand mehr "Sachverstand" als Emba.TEncoding hat und mich eines besseren belehrt..

[Luckie]

Guck mal hier: IsTextUnicode: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

http://blogs.msdn.com/b/oldnewthing/.../24/95235.aspx
http://blogs.msdn.com/b/oldnewthing/...7/2158334.aspx

[p80286]

Zitat:

Zitat von EgonHugeist (Beitrag 1286546)

@p80286

UTF8 und ASCII7-Bit lassen sich sich !nahezu! 100%ig erkennen, da sie einer Normung unterliegen.

Um ein wenig pingelig zu sein, es gibt da ja noch das Extended ASCII was dem ANSI ja doch sehr ähnelt.

Zitat:

Zitat von EgonHugeist (Beitrag 1286546)

Aber grundsätzlich: NEIN es ist unmöglich 100% sicher zu sein.

Dem ist eigentlich nichts hinzu zu fügen, und für die ganz pingeligen nicht die verschiedenen EBCDIC-Codierungen vergessen!

Gruß
K-H