Siro
01.02.2019, 10:06
Zum Wochenende mal ein "bisher von mir" nicht erkanntes Problem mit Source Code Dateien:
Jetzt muss ich mal vorab den altmodischen Text loswerden:
"Früher" war alles besser, weil: ;)
da hatte jedes Asciizeichen sein eigenes Byte und zwar genau 1 Byte.
Da gab es auch noch ein Carriage Return und ein Linefeed und wenn ich einen Buchstaben geschrieben habe,
dann war meine Datei genau 1 Byte groß.
Zu diesen Zeiten konnte ich über meinen Sourcen problemlos eine Checksumme bilden
und hätte jegliche Manipulation mit recht hoher Wahrscheinlichkeit erkannt.
Aber was heutzutage an meinen Sourcen rummanipuliert wird von den Editoren ist schon unheimlich...
So habe ich grad in "einigen" meiner Sourcecode Dateien 3 Bytes am Anfang gefunden, die ICH da nicht reingepackt habe.
Also habe ich meinen Texteditor genommen und die Datei geöffent und in die aller oberste Zeile, ganz am Anfang einen Buchstaben "A" gesetzt.
Theoretisch müsste ich dann im Hexeditor als erstes Byte einen Hexcode 0x41 haben.
Die Praxis zeigt, dass dort aber 0xEF 0xBB 0xBF steht.
Nach etwas googeln findet man Folgendes:
Diese Bytefolge dient als Kennung zur Definition der Byte-Reihenfolge und Kodierungsform in UCS/Unicode-Zeichenketten, insbesondere Textdateien.
Aber doch bitte nicht in meinen Programm Source Dateien....
Wenn ich hier z.B. Texte abgelegt habe und diese einlese, dann wird das logischerweise nicht mehr funktionieren,
mal abgesehen von meiner Datei Größe und Checksummen die ich früher mit abgelegt und dokumentiert habe.....
Das bedeutet, ich darf weder die Dateigröße, noch eine Checksumme meiner Sourcedateien ablegen und dokumentieren,
weil das funktioniert einfach nicht mehr. :(
Lediglich das Öffnen einer Datei und das Speichern ohne eine Änderung zu machen, kann
eine völlig andere Datei erzeugen, alleine schon weil Spaces durch TABs ersetzt werden,
oder weil das Carrigae Return nicht mehr erscheit oder weil Bytesequenzen rein gesetzt werden oder oder....
Nachvollziehbar geht irgendwie anders.
Nicht ohne Grund habe ich eine Risikoanalye für die "Entwickungs und Dokumentationswerkzeuge" angefangen, welche nun erweitert werden muss.
Siro
Jetzt muss ich mal vorab den altmodischen Text loswerden:
"Früher" war alles besser, weil: ;)
da hatte jedes Asciizeichen sein eigenes Byte und zwar genau 1 Byte.
Da gab es auch noch ein Carriage Return und ein Linefeed und wenn ich einen Buchstaben geschrieben habe,
dann war meine Datei genau 1 Byte groß.
Zu diesen Zeiten konnte ich über meinen Sourcen problemlos eine Checksumme bilden
und hätte jegliche Manipulation mit recht hoher Wahrscheinlichkeit erkannt.
Aber was heutzutage an meinen Sourcen rummanipuliert wird von den Editoren ist schon unheimlich...
So habe ich grad in "einigen" meiner Sourcecode Dateien 3 Bytes am Anfang gefunden, die ICH da nicht reingepackt habe.
Also habe ich meinen Texteditor genommen und die Datei geöffent und in die aller oberste Zeile, ganz am Anfang einen Buchstaben "A" gesetzt.
Theoretisch müsste ich dann im Hexeditor als erstes Byte einen Hexcode 0x41 haben.
Die Praxis zeigt, dass dort aber 0xEF 0xBB 0xBF steht.
Nach etwas googeln findet man Folgendes:
Diese Bytefolge dient als Kennung zur Definition der Byte-Reihenfolge und Kodierungsform in UCS/Unicode-Zeichenketten, insbesondere Textdateien.
Aber doch bitte nicht in meinen Programm Source Dateien....
Wenn ich hier z.B. Texte abgelegt habe und diese einlese, dann wird das logischerweise nicht mehr funktionieren,
mal abgesehen von meiner Datei Größe und Checksummen die ich früher mit abgelegt und dokumentiert habe.....
Das bedeutet, ich darf weder die Dateigröße, noch eine Checksumme meiner Sourcedateien ablegen und dokumentieren,
weil das funktioniert einfach nicht mehr. :(
Lediglich das Öffnen einer Datei und das Speichern ohne eine Änderung zu machen, kann
eine völlig andere Datei erzeugen, alleine schon weil Spaces durch TABs ersetzt werden,
oder weil das Carrigae Return nicht mehr erscheit oder weil Bytesequenzen rein gesetzt werden oder oder....
Nachvollziehbar geht irgendwie anders.
Nicht ohne Grund habe ich eine Risikoanalye für die "Entwickungs und Dokumentationswerkzeuge" angefangen, welche nun erweitert werden muss.
Siro