Vorstellung Unit: File encoding detector

[LTE5]

Ich möchte euch gerne meine Arbeit aus den vergangenen Tagen vorstellen.
Ich bin kein Profi und habe mich erst vor wenigen Tagen in Streams eingelesen.

Ich brauchte eine Lösung, um mehr oder weniger zuverlässig das Encoding einer Datei herausfinden zu können.
Über BOM ist das ja leider nicht immer feststellbar, daher habe ich eine andere Lösung entworfen.

Sie ist weder professionell noch gut, aber sie funktioniert. Es ist mehr oder weniger eine Zusammenstellung aus Dingen die ich im Internet gefunden habe.
Daher bitte ich um Feedback! Ihr könnt die Unit auch gerne kopieren, anpassen und hier im Beitrag wieder posten.

Der Aufruf ist einfach

Delphi-Quellcode:

var IsUnicode: Boolean;
begin
 IsUnicode := TEncodingDetect.IsFileUnicode('pfad-zur-datei.txt');

So ist es auch möglich

Delphi-Quellcode:

 Memo1.Lines.Clear;

 Memo1.Lines.Add('File unicode: ' + BoolToStr(TEncodingDetect.IsFileUnicode('pfad-zur-datei.txt'), True));
 Memo1.Lines.Add('String unicode: ' + BoolToStr(TEncodingDetect.IsTextUnicode('ʥ'), True));
 Memo1.Lines.Add('String unicode: ' + BoolToStr(TEncodingDetect.IsTextUnicode('ABC'), True));
 Memo1.Lines.Add('File content: ' + TFile.ReadAllText('pfad-zur-datei.txt', TEncodingDetect.GetEncoding('pfad-zur-datei.txt')));

[LTE5]

Ich musste deine Antwort zweimal lesen. Denn ich habe eigentlich noch mit Kritik gerechnet und dass irgendetwas, was absolut funktionieren muss, nicht funktioniert.

Aber wenn es bisher nur das ist

[Fukiszo]

Ich arbeite gerade an einem Tool namens "FileID".
Es identifiziert enorm viel Datei-Formate, über 3000 verschiedene binärer art.
Unter anderem auch Text dateien und deren "Encoding", was ich bei mir so realisiert hab:
ich les an offset 0 der datei das erste byte und bestimme dadurch mit was es codiert wurde.
Als referenz nahm ich mir Notepad++ und erstellte pro format ein paar dateien.
(des weiteren prüft mein tool ob irgendwelche nicht-lesbaren (binär) zeichen enthalten sind
um generell zu bestimmen ob's ne text-datei ist)
Ich hoff es hilft. (ist halt ne andere methode um ans ziel zu gelangen)

[himitsu]

Zitat:

ich les an offset 0 der datei das erste byte und bestimme dadurch mit was es codiert wurde.

Falsch!

Bei UTF-8 ist das BOM genau 3 Byte lang.
Im Prinzip ist das mit dem BOM recht einfach zu verstehen, denn es ist zufällig das Unicodezeichen #$FEFF welches mit dem jeweiligen Encoding (Codepage) codiert wurde und was praktisch an erster Stelle des decodierten Unicode-Textes steht.

siehe $FFFE http://www.unicode.org/charts/PDF/UFFF0.pdf
https://de.wikipedia.org/wiki/Byte_Order_Mark
Seinen Namen hat das Byte-Order-Mark von den Codes $FFFE und $FEFF der UTF-16 / UCS2 in Big Endian und Little Endian.


Bei vielen "Binär"-Dateien ist das Magic-Byte, auch wenn es sich "Byte" nennt oft 2 bis 4 Byte lang.
z.B. "PE" bei Portable Execute, also den kompilierten EXE und DLL (und BPL, welche auch "nur" aufgemotzte DLL sind)



Und was sind "nicht-lesbare (binär) zeichen"?
Bei Chinesisch, Russisch, Swahili und Dergleichen, ist für "uns" Vieles nicht lesbar.

[Fukiszo]

nicht lesbar = code $00 - $21 (oder war's $23?) zum beispiel.
mit nicht lesbar mein ich man sollte nicht versuchen diese ascii codes darzustellen, sie enthalten keine "schriftzeichen", egal von wo.
und ich start meine identifizierung mit dem ersten byte, danach geht identifierung weiter mit zweitem dritten usw.
es gibt viele dateien deren signatur mit $FF beginnt.

ich hoff es hilft.

ps: ich gab ja keine werte zum vergleich an, ich meint halt nur das ich signaturen per byte abfrage kontrolliere,
und nicht per CLASS definitionen auslese.

[Daniel]

Moin,

weitere Ideen sind ja grundsätzlich nichts schlechtes. Aber ich bin nicht sicher, ob Du dieses Thema gelesen hast. Es geht hier gerade auch um Dateien, die keine entsprechende Kennung aufweisen. Der von Dir vorgestellte Ansatz wurde auf Seite 2 diskutiert und verworfen.
Lass Dich nicht entmutigen, das kann passieren - aber wirf bitte vorher kurz einen Blick auf die Themen, zu denen Du etwas schreiben möchtest.