@Luckie
das ist schon in Ordnung, danke.
nur konnte ich nicht glauben, dass es dafür keinen einfacheren weg gibt.
wenn ich zum beispiel eine textdatei mit meinem hexeditor öffne, sagt er auch gleich
"...appears to be a text file.
Do you want to open it as text?"
Hat der dann jedes Zeichen überprüft, ob es
ascii ist?
aber ich weiß es nicht, villt hat er es ja.
Eine manuelle überprüfung ist ja auch ganz nett.
nur 1. ist das etwas komplexer, wie ihr schon gesagt habt, sonderzeichen, und dann kommen noch steuerzeichen dazu.
2. wirft mich das wieder in einen bereich, in dem ich mich nicht auskenne. wie lese ich einzelne bytes einer datei ein und gucke, ob das byte dem eines
ascii-codes oder steuerzeichens entspricht?
eine andere möglichkeit wäre vielleicht, einfach zu überprüfen ob jedes erste bit eines bytes 0 ist, wenn das bei jedem byte so ist, liegt es doch nahe, dass es
ascii-codes sind. da drängt sich mir die frage auf, haben
ascii steuerzeichen auch eine null am anfang? und wenn ja, wie lese ich mit delphi das erste bit eines bytes aus?
fragen über fragen... das scheint ja ein größeres problem zu werden, als ich dachte, haltet ihr noch durch?
@Panthrax
Der Ansatz ist interessant. Ein bischen stört mich da mein perfektionismus. weil nicht immer jede Textdatei dann auch als Textdatei gewertet werden würde. egal, welche kriterien eingeführt werden, normale texte würden leicht erkannt werden, aber extremfälle nicht. was ist zum beispiel mit ganz kurzen texten oder codeausschnitten?
viel interessanter ist das ko-kriterium. wenn zu viele hässliche kleine schwarze vierecke auf dem bildschirm landen, sagt er "nein".
noch dazu könnte man die dateigröße ins verhältnis setzen mit dem angezeigten text. oft wird bei falschen dateitypen nämlich gar nicht viel angezeigt. ein paar beispiele:
-eine wav-sounddatei: RIFF@¬G
-eine flash-datei: CWS–þ
-eine mp3-datei: ÿûd
-eine exe-datei: MZ
also nur wenige zeichen, meistens unter zehn. wobei ihr euch bei den beispielen noch ein paar kleine schwarze vierecke dazudenken müsst, die wurden leider nicht mitkopiert
ich ringe mich halt immer nur ungern zu ergebnissen durch, die nur die halbe wahrheit sind. denn so oder so heißt es dann nicht "das ist eine textdatei" sondern nur "das sieht aus wie eine textdatei". kann es wirklich sein, dass man nicht ordentlich zwischen
ascii und binary file unterscheiden kann, wie es jeder
ftp-client tut?
wahrscheinlich wird so oder ähnlich meine lösung aussehen, wenn das nicht anders klappt. zum beispiel wirklich die einzelnen bytes untersuchen.
wie liest mann denn nun bytes und deren einzelne bits ein?
ratlosigkeit macht sich breit
gruß