Wir basteln uns eine Binärdatei (eindeutig keine Textdatei, da $FFFE kein
Unicode-Zeichen ist):
Natürlich ist
#255#254 indirekt ein
Unicode-Zeichen, nämlich ein UTF-16 BOM. (Hättest du meinen Code gelesen, dann hättest du es gesehen). Wenn du die Datei in einem beliebigen
Unicode-Text-Editor lädst, hält er das wegen des BOM für eine
Unicode-Datei und stellt deswegen natürlich den Rest nicht mehr dar, weil - wie du richtig sagst - das kein
Unicode-Zeichen ist.
Häng noch ein paar
ASCII-Zeichen dran, und Notepad interpretiert das chinesisch ...
Du siehst also, dass sogar weit verbreitete Text-Editoren das für einen Text halten (wegen des BOM) - insofern befinde ich mich in guter Gesellschaft. Und streng definitionsgemäß ist es (wegen des BOM) ja eine
Unicode-Textdatei, nur eben eine verkorkste
Unicode-Textdatei.
Nur DU hältst es für eine Binärdatei, weil sie von deinem Spiel als strukturierte Datendatei gespeichert wurde. Das wissen aber andere Programme nicht. Für die ist es eine
Unicode-Textdatei mit einem BOM. Wäre der Spielstand 254:254:255:254 gewesen, würde jeder moderne Text-Editor die Datei als ganz normalen Text darstellen, weil der BOM dann fehlt, denn es
IST ja definitionsgemäß eine Textdatei.
Für
Unicode-Text-Editoren ist das eben die durch den BOM bedingte Rest-Unsicherheit, die ich in mehreren Postings genannt habe, und die sich nicht vermeiden lässt - für den Rest ist es eine ganz normale Textdatei.
PS:
da Du ja nicht prüfst, ob es eine Textdatei ist, sondern nur, ob es so einigermaßen danach aussieht.
Auch das ist nicht richtig: Meine Funktion prüft
NICHT "ob es so einigermaßen [nach einer Textdatei] aussieht", sondern sie prüft, ob Indikatoren für eine Binärdatei enthalten sind. Steht auch ganz deutlich im Titel dieses Themas.