.gx (3D Drucker) Datei kopieren -> c#

Naj H. schrieb:

> Auch wenn ich die original Datei öffne und diese nicht verändere sondern
> wieder 1 zu 1 im gleichen Format speichere kann meine Slicer Software
> diese nicht mehr laden..
> Woran liegt das?

Du bearbeitest die Datei wahrscheinlich als "Text". Es ist aber kein 
Text, jedenfalls nicht vollständig.

Wenn du sie als Text bearbeiten möchtest, dann musst du erstmal die 
Steuerzeichen "escapen" und am Ende der Bearbeitung wieder "de-escapen". 
Escapen bedeutet in erster Näherung: Ersatz durch eine Darstellung, die 
im Text-Teil nicht vorkommt. Wenn man das nicht garantieren kann, dann 
muss in zweiter Näherung auch jedes Vorkommen des Excape-Zeichens in den 
Textdaten seinerseits escaped werden. Hier allerdings, um zu notieren, 
dass es gerade KEIN Escape-Zeichen ist. So ungefähr funktioniert das.

Gleich vorweg: Ich habe absolut keine Ahnung von diesem Dateiformat und 
orientiere mich nur an der Beispieldatei. Es gibt darin (mindestens) 
drei Bereiche.
"xgcode 1.0" gefolgt von 0xA0 und irgendwas anderem. An Index 20 steht 
evtl. eine Adresse (0xB0, 0x38, 0x00, 0x00). Wenn es so ist, wäre es 
wahrscheinlich 14512 (dec), denn genau an diesem Index beginnt der 
ASCII-Teil der Datei (";generated by ffslicer" ...). Dazwischen befinden 
sich die Daten, die dir vermutlich Probleme bereiten (abgesehen von ein 
paar Bytes im Header).

Falls das kein kompletter Blödsinn ist, könntest du evtl.:
- Den Anfang der Datei (als Binärdaten) einlesen und zumindest grob 
validieren (also Start mit "xgcode" und Sinnhaftigkeit des Dateiindex 
des ASCII-Teils).
- Alles bis zu diesem Index als Binärdaten einlesen.
- Den Rest als Text einlesen und editieren.
- Den Binärteil als solchen in eine Datei schreiben.
- Den veränderten ASCII-Teil als solchen anhängen.

Du müsstest dann nur beachten, dass die Trenner im ASCII-Teil als LF 
(0x0A) geschrieben werden, nicht als "Windows-Newline" (CR LF, also 0x0D 
0x0A), falls dies bei diesem Dateiformat eine Rolle spielt.

Ich gehe hier natürlich (naiverweise) davon aus, dass du nur Werte im 
ASCII-Teil änderst und diese Änderungen keinen Einfluss auf den 
Binärteil haben.

Hier hat das Dateiformat scheinbar jemand beschrieben:
https://github.com/slic3r/Slic3r/issues/4869

Der BinaryReader dürfte für deine Zwecke nicht geeignet sein.
Das Ding wird eigentlich eher intern von z.B. BinaryFormatter genutzt 
und laut Doku gilt bei ReadString() z.B.:
"Reads a string from the current stream. The string is prefixed with the 
length, encoded as an integer seven bits at a time."
...das ist bei diesem *.gx-Format aber nicht der Fall (bzw. 
wahrscheinlich generell bei praktisch nichts, was nicht zufällig auch 
via BinaryWriter/BinaryFormatter erzeugt wurde ;D)

Verwende besser direkt nur FileStream.Read() / .ReadByte() und lies dir 
damit relevante* String-Sektionen z.B. jeweils in eigene byte[]-Arrays 
und konvertiere dir das dann z.B. via
string 
result=Encoding.GetEncoding("ISO-8859-1").GetString(quellByteArray);
jeweils in einen String.

(*vermutlich nur der Teil wo der tatsächliche gcode los geht? Und davor 
wird nichts editiert?)

Naj H. schrieb:
> habe jetzt echt einiges probiert..
> Es werden immer noch einige Zeichen nicht richtig interpretiert bzw.

Ich meinte es wie im Anhang - einfach die Binärteile (Header und Bitmap; 
danke an bluppdidupp für den Link) speichern und danach den Textteil 
(G-Code) drankleben.
Das Beispielprogramm lädt die Datei, hängt an die erste G-Code-Zeile 
etwas an und speichert das Ganze wieder (Vorsicht, sollte die Zieldatei 
existieren, wird sie überschrieben).
gxsav in.gx out.gx

Falls Du mit dem Bitmap nichts machen willst - z.B. anzeigen oder 
speichern -, werden GxBitmap.cs (und damit System.Drawing) und die 
gekennzeichneten Zeilen in GxFile nicht benötigt.