Zeichenkodierung: Charset Detector

[Jazzman_Marburg]

Hallo werte Gemeinde!

Sagt mal, hat wohl jemand mal versucht den sog. "Charset Detector" (http://chsdet.sourceforge.net/) in einer Anwendung einzubinden?
Wie der Name es schon nahelegt geht es darum, das Encoding eines Files/Strings zu bestimmen. Unter sourceforge bekommt man auch sämtliche Sourcen -- die ReadMe Datei führt auch ein Beispiel Aufruf auf -- nur bin ich wie es scheint nicht in der Lage diesem Beispiel zu folgen.
Vielleicht hat das jemand ja schon mal gemacht und kann weiterhelfen?

Für die, die es interessiert, hier das Beispiel aus der ReadMe:

Delphi-Quellcode:

-----------Sample
  The definition file "chsd_dll_intf.pas" can be found in the same direcory.
  Bellow is small usage sample.
  
  // WS: WideString; // Wide string which can be used in Unicode controls.
  
  // Get encoding of some buffer
  chsd_Reset;   
  chsd_HandleData(aBuf, aLen);

  if not chsd_Done then
    chsd_DataEnd;

  ChSInfo := chsd_GetDetectedCharset();
  
  // convert buffer to WideString
  OutputLength := MultiByteToWideChar(ChSInfo.CodePage, 0, aBuf, aLen, nil, 0);
  SetLength(WS, OutputLength);
  MultiByteToWideChar(ChSInfo.CodePage, 0, aBuf, aLen, PWideChar(WS), OutputLength);
  
  // If you using Unicode SynEdit
  SynEdit.Lines.Text := WS;

Ich habe die chsd_dll_intf Unit in der Uses-Klausel aufgenommen -- Compiler sagt ok.
Dann habe ich chsd_Reset auf das Onclick Event eines Buttons gelegt -- Fehler beim Compilieren:
"Das Programm kann nicht gestartet werden, da chsdet.dll auf dem Computer fehlt. Installieren Sie das Programm erneut, um das Problem zu beheben."

Meine konkrete Frage:
Auf sourceforge findet man diese DLL -- ich könnte sie auch schnell registrieren -- aber ich dachte, da ich ja sämtliche Soruce habe, bräuchte ich die DLL nicht.

Wie gesagt -- scheinbar missverstehe ich da etwas -- und wenn das jemand schon mal hinbekommen hat, wäre prima.

Österlichen Dank im voraus
Gruß
Jazzman

[rollstuhlfahrer]

Ich denke, dass die Pascal-Dateien nur ein Beispielaufruf sind, die alle auf die DLL verweisen. Evtl. kannst du dir ja mal die Pascal-Quellen anschauen.

Bernhard

[himitsu]

Wenn es sich nicht grade um einen MultiByte-Zeichensatz handelt und man weiß, daß es kein SingleByte-Zeichensatz ist, dann kann man sowas doch garnicht bestimmen?

Jedenfalls nicht, wenn man z.B. über ein Wörterbuch, mit allen möglichen Sprachen, versucht die vorgefundenen Werte/Bytes abzugleichen.

[Jazzman_Marburg]

Zitat von himitsu:

Wenn es sich nicht grade um einen MultiByte-Zeichensatz handelt und man weiß, daß es kein SingleByte-Zeichensatz ist, dann kann man sowas doch garnicht bestimmen?
Jedenfalls nicht, wenn man z.B. über ein Wörterbuch, mit allen möglichen Sprachen, versucht die vorgefundenen Werte/Bytes abzugleichen.

Das weiss ich nicht recht -- deswegen wollte ich damit ja mal rumprobieren. Auf sourceforge gibt es einen Kommentar zum Charset Detector:
"Best solution I've seen so far, definitely worth using." Der "guessing"-Algorithmus scheint eben gut zu sein.

Zitat von rollstuhlfahrer:

Ich denke, dass die Pascal-Dateien nur ein Beispielaufruf sind, die alle auf die DLL verweisen. Evtl. kannst du dir ja mal die Pascal-Quellen anschauen.
Bernhard

Naja, es sind 28 Units die scheinbar mit Uses chsd_dll eingebunden werden -- eher nicht "nur" Beispielaufrufe.

Forschen wir weiter...
Danke & Gruß
Jazzman

[himitsu]

Es kommt auch darauf an, was du erreichen willst.
Klar ist jedoch, daß es keinen Algorithmus geben kann, welcher nahezu 100%ig den Zeichensatz erkennt.

Das zeigt ja schon eine andere einfache grobe Unterscheing:
(dieser Code soll da noch viel feiner/detailierter unterscheiden)

Ansi oder Unicode

In unserem Sprachraum könnte kann ja "einfach" sagen "kommen viele #0 an den geraden Byte-Positionen vor (mit 1-Indizierung gezählt), dann ist es Unicode.
Aber damit würden dann vorallem die Strings mit asiatischen Texten alle als Ansi erkannt.


Wenn du also eine "sichere" Unterscheidung brauchst und du die Texte selber erstellst oder deren Format festlegen kannst, dann ist die sicherste Methode, wenn man die Codepage (ihre Nummer oder einen Namen) zusammen mit diesem "Text" abspeichert.

[Jazzman_Marburg]

Zitat von himitsu:

Klar ist jedoch, daß es keinen Algorithmus geben kann, welcher nahezu 100%ig den Zeichensatz erkennt.
...
Wenn du also eine "sichere" Unterscheidung brauchst und du die Texte selber erstellst oder deren Format festlegen kannst, dann...

Hi!

Das ist klar -- ich sprach ja auch von einem guten "guessing"-Algorithmus. D.h. es läuft auf eine Heuristik raus, die dann auch ihre Grenzen hat.

Und, nein -- ich erstelle die Texte nicht selber -- im Gegenteil ich bekomme Texte, deren Kodierung ich vernüntig schätzen möchte.

Aber, das alles hat ja nichts mit meiner Eingangsfrage zu tun: Mir ging es ja darum dieses Ding zum Laufen zu bekommen. Damit habe ich Schwierigkeiten -- nicht damit, dass es nicht 100%ig sichere Ergebnisse liefert.

Danke & Gruß
Jazzman

[himitsu]

OK, es ging mir ja erstmal nur darum, unnötige Arbeit zu ersparen,
also falls sich dieses durch ein "sicheres" System" hätte ersetzen lassen können.

A: Welche Delphi-Version nutzt du?

B:

Zitat:

Dann habe ich chsd_Reset auf das Onclick Event eines Buttons gelegt

Ähhhh, was hast du da genau gemacht?

Vielleicht zeigst du mal etwas Code, wie du es nun selber versucht hattest.
Aus dem Demo-Code (Beispiel aus der ReadMe) sieht man ja nicht, was du in deinem Code machst.

C: Hier mal die übersetzen Header für alle Delphiversionen (auch 2009 und 2010):

Delphi-Quellcode:

{$ALIGN 4}

const
  NS_DLL                 = 'chsdet.dll';
  NS_OK                  = 0;
  NS_ERROR_OUT_OF_MEMORY = $8007000e;

types
  TCharsetInfo = record
    Name:     PAnsiChar;        // charset name
    CodePage: LongInt;          // MS Windows CodePage id
    Language: PAnsiChar;        //
  end;

  TAboutHolder = record
    MajorVersionNr: LongWord;   // Library's Major Version
    MinorVersionNr: LongWord;   // Library's Minor Version
    BuildVersionNr: LongWord;   // Library's Build/Release Version
    About:          PAnsiChar;  // Copyleft information
  end;

  TBOMKind = (
    BOM_Not_Found,
    BOM_UCS4_BE,    // 00 00 FE FF           UCS-4,    big-endian machine    (1234 order)
    BOM_UCS4_LE,    // FF FE 00 00           UCS-4,    little-endian machine (4321 order)
    BOM_UCS4_2143,  // 00 00 FF FE           UCS-4,    unusual octet order   (2143)
    BOM_UCS4_3412,  // FE FF 00 00           UCS-4,    unusual octet order   (3412)
    BOM_UTF16_BE,   // FE FF ## ##           UTF-16,   big-endian
    BOM_UTF16_LE,   // FF FE ## ##           UTF-16,   little-endian
    BOM_UTF8        // EF BB BF              UTF-8
  );

procedure chsd_Reset; stdcall;
  external NS_DLL;

function chsd_HandleData(aBuf: PAnsiChar; aLen: LongInt): LongInt; stdcall;
  external NS_DLL;

function chsd_Done: Boolean; stdcall;
  external NS_DLL;

procedure chsd_DataEnd; stdcall;
  external NS_DLL;

function chsd_GetDetectedCharset: TCharsetInfo; stdcall;
  external NS_DLL;

procedure chsd_GetKnownCharsets(var KnownCharsets: PAnsiChar); stdcall;
  external NS_DLL;

procedure chsd_GetAbout(var About: TAboutHolder); stdcall;
  external NS_DLL;

function csd_GetDetectedBOM: TBOMKind; stdcall; 
  external NS_DLL;

procedure csd_DisableCharsetCP(CodePage: LongInt); stdcall; 
  external NS_DLL;

[Jazzman_Marburg]

Hallo himitsu!

Lieben Dank für Deine schnelle Reaktion.
A. Also, was ich tat ist mit zwei Sätzen zu beschreiben:

1. In die Main Unit in der Uses Anweisung die chsd_dll_intf aufgeführt.
(Complieren klappt prima)
2. Ein Button auf die Form gelegt und im Object-Inspector ein Doppelcklick auf das OnClick Event:

Delphi-Quellcode:

procedure TForm1.BitBtn1Click(Sender: TObject);
begin
  chsd_Reset;
end;

Das war es -- zu weiterem Tun kam ich nicht, da Compilieren zwar klappte, aber bei der Ausführung der o.g. Fehler kam. Mehr habe ich nicht gemacht, da das ja schon mit einem Fehler endete.

B. Delphi Version: Turbo Delphi, aka Delphi 2006.

C. Was hätte ich mit diesem Header tun sollen? (ist dieser Kram nicht mit Uses chsd_dll_intf automatisch bekannt?)

Vielen Dank!

Gruß
Jazzman

[himitsu]

Und wo genau liegt diese chsdet.dll , im Verhältnis zur EXE?

Zitat:

ist dieser Kram nicht mit Uses chsd_dll_intf automatisch bekannt?

joar,

aber ab Delphi 2009 ist PChar als PWideChar deklariert, wärend es in der DLL aber immernoch einem PAnsiChar entspräche.
Diese Typen wären also inkompatibel.
(bei dir gibt es aber diesbezüglich noch keine Probleme)

[Jazzman_Marburg]

Zitat von himitsu:

Und wo genau liegt diese chsdet.dll , im Verhältnis zur EXE?

Jetzt im gleichen Verzeichnis (/bin) wie die EXE.
(Vor Deiner Frage, hatte ich die DLL überhaupt nicht dabei, da ich ja davon ausging, dass wenn ich die Sourcen habe, keine DLL brauche.)

Jetzt gibt es einen anderen Fehler wenn ich versuche das Projekt auszuführen:

"Einsprungpunkt nicht gefunden: Der Prozedureinsprungpunkt 'chsd_Reset' wurde in der DLL 'chsdet.dll' nicht gefunden"

Wir sind also einen Schritt weiter -- aber nicht vielmehr.

Mich verwirrt die Sache mit der DLL immer noch -- wozu benötige ich das Ding?
Will sagen: Der Autor von Charset Detector stellt beides zur Verfügung:
A) die DLL
B) die gesamten Sourcen

Wenn ich nun diese Sorucen z.B. weiterentwickeln möchte -- wozu benötige ich dann die DLL. Ich dachte, dass ich mir mit den Sourcen die DLL entweder selber neu erstellen kann (falls ich meine Erweiterungen in Form einer DLL weitergeben möchte -- oder ich benötige sie garnicht).

Herrjeh, was kompliziert...

Danke
Jazzman