Hallo und schönen Tag!

Auf sourceforge gibt es ein Projekt Charset detector:

Zitat:

Charset Detector - as the name says - is a stand alone executable module for automatic charset detection of a given text.

Eigentlich sollte dies eine nützliche Funktion sein. Also habe ich versucht, Charset detector mit folgendem Code zu verwenden:

zusammenfalten · markieren

Delphi-Quellcode:

program CharsetDetectorTest;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  CodeSiteLogging,
  chsd_dll_intf,
  System.Classes,
  System.SysUtils;

var
  LFileStream: TFileStream;
  LBuffer: TBytes;
  cs: rCharsetInfo;

begin
  try
    csd_Reset;

    LFileStream := TFileStream.Create('C:\mytext.txt', fmOpenRead);
    try
      // Read file into buffer:
      SetLength(LBuffer, LFileStream.Size);
      LFileStream.ReadBuffer(Pointer(LBuffer)^, Length(LBuffer));
      CodeSite.Send('Length(LBuffer)', Length(LBuffer));

      if csd_HandleData(PWideChar(LBuffer), Length(LBuffer)) = NS_OK then
      begin
        CodeSite.Send('chsd_Done', csd_Done);

        cs := csd_GetDetectedCharset;
        CodeSite.Send('cs.Name', PAnsiChar(cs.Name)); // -> Unknown
        CodeSite.Send('cs.CodePage', cs.CodePage); // -1
        CodeSite.Send('cs.Language', PAnsiChar(cs.Language)); // -> Unknown
      end
      else
        CodeSite.Send('csd_HandleData Failed');
    finally
      LFileStream.Free;
    end;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Leider bekomme ich als Ergebnis nur "Unknown" und -1. Was mache ich falsch?

Alleine beim Wort "Charset" sollte einem klar werden, dass es sich hier um ANSI und nicht um Unicode handeln sollte.

Somit ist WideChar falsch.


Fazit:
Wide in Ansi ändern
PChar in PAnsiChar (der Verfasser sollte erschlagen werden, vorallem da seit 4 Jahren das Delphi mit Unicode arbeitete)



[OT]
Wenn ich im Code was von BOM lese, dann würde man dafür keine DLL brauchen und wenn das Ding nicht mit Wörterbüchern arbeitet, dann ist es einfach "unmöglich" eine Codieren ala CharSet zu erkennen, vorallem nicht bei all den SingleByteCodepages.
Aber bei "Language" könnte es sein, dass er schon irgendwie ein kleines Wörterbuch drin hat, womit er die Sprache versucht zu erkennen.

[edit]
Das Dateidatum sagt, das Zeug ist 17 Jahre als und stamt aus einer Zeit vor Unicode (nach Delphizeitrechnung).
Aber dennoch war PChar schon immer als "dynamisch" definiert. Aber wer beachtet das schon.

Mhmm, es scheint zu funktionieren, wenn die Textdatei einen BOM hat. Das wäre aber witzlos.

Dann habe ich einen englischen Text abgespeichert (UTF-8 OHNE BOM): Damit habe ich wieder das UnKnown-Ergebnis erhalten.

Dann habe ich die deutschen Umlaute äüöß in den englischen Text eingefügt und wieder abgespeichert (wieder UTF-8 OHNE BOM).

Dann wird zurückgegeben:

Zitat:

cs.Name = UTF-8
cs.CodePage = 65001
cs.Language = Unicode

Wieso?

Wie kann ich in jedem Fall ein definiertes Ergebnis erhalten? Oder vielleicht ist in meinem Code ein Fehler enthalten?

Zitat von himitsu:

Alleine beim Wort "Charset" sollte einem klar werden, dass es sich hier um ANSI und nicht um Unicode handeln sollte.

Somit ist WideChar falsch.


Fazit:
Wide in Ansi ändern
PChar in PAnsiChar (der Verfasser sollte erschlagen werden, vorallem da seit 4 Jahren das Delphi mit Unicode arbeitete)



[OT]
Wenn ich im Code was von BOM lese, dann würde man dafür keine DLL brauchen und wenn das Ding nicht mit Wörterbüchern arbeitet, dann ist es einfach "unmöglich" eine Codieren ala CharSet zu erkennen, vorallem nicht bei all den SingleByteCodepages.
Aber bei "Language" könnte es sein, dass er schon irgendwie ein kleines Wörterbuch drin hat, womit er die Sprache versucht zu erkennen.

Leider ist kein Source-Code der DLL enthalten. Wie ist das möglich bei Sourceforge? So kann man nicht prüfen, was die DLL macht.

Mit Notepad++ kann man sehr schön die Codierung eines Textes wechseln. Textdateien mit BOM scheint er recht zuverlässig zu erkennen. Aber dafür brauche ich keine eigene DLL.

Jetzt habe ich einen Text abgespeichert als ISO 8859-2. Das hat er erkannt als:

cs.Name = UTF-16LE
cs.CodePage = 1200
cs.Language = Unicode

Die DLL ist egal, an der ändert sich ja nichts. Die ist so, wie sie kompiliert wurde.

Aber die Schnittstelle zur DLL ist fehlerhaft.
Ab Delphi 2009 wird durch die falschen Deklarationen teilweise Unicode verwendet.

Hmm..

Zitat von PeterPanino:

Leider ist kein Source-Code der DLL enthalten. Wie ist das möglich bei Sourceforge? So kann man nicht prüfen, was die DLL macht.

Also der Code ist doch da...

Auf der Seite

https://sourceforge.net/projects/chsdet/

oben auf 'Code', dann unten 'Browse CVS Repository' und Du kannst Dir den Code anschauen und Herunter laden..

Zitat von PeterPanino:

Dann habe ich einen englischen Text abgespeichert (UTF-8 OHNE BOM): Damit habe ich wieder das UnKnown-Ergebnis erhalten.

Dann habe ich die deutschen Umlaute äüöß in den englischen Text eingefügt und wieder abgespeichert (wieder UTF-8 OHNE BOM).

Dann wird zurückgegeben:

Zitat:

cs.Name = UTF-8
cs.CodePage = 65001
cs.Language = Unicode

Wieso?

Weil es in diesem Falle keinen erkennbaren Unterschied zwischen ANSI und UTF-8 gibt!
https://de.wikipedia.org/wiki/UTF-8

Gruß
K-H