Textfiles mit unterschiedlichen codepages gesucht

[Jazzman_Marburg]

Hallo Leute.

Ich bastle gerade an einem "Codepage Indetifizierer" -- d.h. das Ding versucht die Codepage zu ermitteln, in welcher die Datei gespeichert worden ist. (Bitte keine Diskussion über die Unmöglichkeit dieses Vorhabens. Eine gute Schätzung reicht völlig aus -- und die habe ich.) Jetzt suche ich irgendwo im Netz nach Text-Files; toll wäre wenn sie alle den gleichen -- Standardtext -- enthielten, aber ganz sicher in verschiedenen Codepages gespeichert worden sind, so dass ich diese Files als Stichproben für mein Projekt verwenden kann.

Habt ihr eine Idee wo ich solche Text-Files (am liebsten auch von verschiedenen Plattformen (Macs, Linux etc.) herbekommen könnte?

Lieben Dank & Gruß
Jasmin

[Bernhard Geyer]

Zitat von Jazzman_Marburg:

Jetzt suche ich irgendwo im Netz nach Text-Files; toll wäre wenn sie alle den gleichen -- Standardtext -- enthielten, aber ganz sicher in verschiedenen Codepages gespeichert worden sind, so dass ich diese Files als Stichproben für mein Projekt verwenden kann.

Gleicher Text, aber sicherlich doch übersetzt? Ansonsten wird ein deutscher Umlaug auf russischer Codepage "zerschossen" werden.

Zitat von Jazzman_Marburg:

Habt ihr eine Idee wo ich solche Text-Files (am liebsten auch von verschiedenen Plattformen (Macs, Linux etc.) herbekommen könnte?

Da gibt es keinen Unterschied. Einzig das/die Zeichen für eine neue Zeile sind bei Windows/Unix/Mac unterschiedlich.

[Jazzman_Marburg]

Zitat von Bernhard Geyer:

Gleicher Text, aber sicherlich doch übersetzt?

Ja.

[himitsu]

Zitat von Jazzman_Marburg:

Bitte keine Diskussion über die Unmöglichkeit dieses Vorhabens.

Sowas gab es schonmal (letzes Jahr) hier in der DP und dort wurden auch ein paar Lösungen diskutiert.

Zitat von Bernhard Geyer:

Da gibt es keinen Unterschied. Einzig das/die Zeichen für eine neue Zeile sind bei Windows/Unix/Mac unterschiedlich.

Jupp.

#13 = Mac
#10 = Linux
#13#10 = Windows

Aber dieses ist auch nicht ganz zuverlässig, denn z.B. das neue RichEdit-Control in Windows arbeitet standardmäßig mit #10.


Im Endefekt geht sowas nur über eine Sprachanalyse, wobei du da dann schauen kannst, wie die jeweiligen Nicht-ASCII-Zeichen kodiert sind, um die verwendete Codepage abzuschätzen.

Was man relativ leicht abschätzen kann, ist ob UnicodeBE, UnicodeLE (UTF-16), UTF-7, UTF-8, Ansi (in unbekannter Codepage).

[Jazzman_Marburg]

Zitat von himitsu:

Was man relativ leicht abschätzen kann, ist ob UnicodeBE, UnicodeLE (UTF-16), UTF-7, UTF-8, Ansi (in unbekannter Codepage).

Sicher -- die BOMs lassen sich einfach erkennen.

Aber ich glaube ich schon was gefunden, was mir erstmal helfen wird:
Codepage Conversion
Vielen Dank & Gruß
Jazzman

[Luckie]

Zitat von Jazzman_Marburg:

Sicher -- die BOMs lassen sich einfach erkennen.

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

Dann solltest du Raymond mal deinen Trick verraten.

[Jazzman_Marburg]

Zitat von Luckie:

Zitat von Jazzman_Marburg:

Sicher -- die BOMs lassen sich einfach erkennen.

Dann solltest du Raymond mal deinen Trick verraten.

Hallo.

Och, ich denke Raymond wird den Trick (der keiner ist) schon kennen, denn er schreibt ja selbst:

Zitat:

If a BOM is found, then life is easy, since the BOM tells you what encoding the file uses. The problem is when there is no BOM. Now you have to guess, and when you guess, you can guess wrong. For example, consider this file: ...

Also, wenn BOMs da sind, ist es easy -- leider hält sich die halbe (IT)Welt nicht daran, und ohne wird es tricky!

Danke für den Hinweis (ich kannte die Taexte nicht -- aber soweit ich es erkennen kann, bestätigen sie mein Vorgehen).

Gruß
Jazzman

[Luckie]

Ach so OK. Mit BOM ist es einfach, das ist klar. Ich dachte, du hättest für ohne BOM einen Trick gefunden.

[himitsu]

Im Europäischen und ähnlichen Sprachräumen kann man, durch 'ne sehr einfache Musteranalyse, derartige Formate auch ohne BOM relativ zuverlässig erkennen.
Sobald aber z.B. Unicode und oder asiatische Sprachräume ins Spiel kommen können, dann kann man es eigentlich vergessen und man ist auf ein BOM oder externe Informationen angewiesen.

Wie gesagt, wenn du jetzt nur von Multibyte-Codepages ausgehst, dann kommst du um eine Sprachanalyse nicht drumrum, da ein Byte nunmal ein Byte bleibt, egal was für ein Buchstabe sich darin versteckt.
Ob nun ein Byte, mit dem Wert $A9 z.B. ein deutsches Ä darstellt oder ein Russisches Irgendwas, das bkommst du aus diesem Byte niemals raus.
Sowas geht eben nur über eine Verbindung der umliegenden Bytes, z.B. indem man signifikante Muster der zu erkennenden Sprachen (codiert in mehreren Codepages) sucht.

Wenn man UTF-7 ignoriert, dann ist diesbezüglich ASCII das Einzige Format, welches man relativ sicher erkennen kann.


Wie gesagt, es gab in den letzten Jahren schonmal soein Thema und dieses wurde dann nach vielen Diskusionen unter dem Ergebnis "teilweise nicht zuverlässig genug und im Rest nicht lösbar" aufgegeben.
(wobei die Sprachanalyse damals auch, Aufgrund von "zu aufwändig" ignoriert wurde)


PS: Du kannst dein Vorhaben hiermit vergleichen:
http://www.delphipraxis.net/internal...t.php?t=177809
Nur daß du als Lösung das Passwort&Algorithmus (Codepage) suchst, womit dieser Text verschlüsselt (gespeichert) wurde.