0x00 ist bei txt anders als bei bmp´s ! KOMISCH

[Specialguest@home]

Hi Maedels,

momentan arbeite ich am Zippen von Bilddateien anhand der ZLIB Bibliothek.

Ich bin soweit, dass ich Textdateien jeglicher Form einlesen, zippen und auch entzippen kann.
Dabei ist es egal ob es sich um Text mit Steuerzeichen oder auch ohne handelt.

Eigentlich moechte ich aber Bitmaps zippen. Diese enthalten extrem viele Steuerzeichen.
Und genau da liegt das Problem. Leider wird das 0x00 nicht richtig erkannt, solange es sich um Bitmaps handelt.
Bei der Textdatei wird das 0x00 komischerweise richtig erkannt und auch gezippt/entzippt.
Das weiss ich wirklich genau, da ich mir die Dateien immer mit einem Hexviewer anschaue.

Bei der Bitmapdatei werden die ganzen 0x00 ausgelassen wodurch das Datenvolumen sich stark verringert, welches der Zipper
dann jedoch am Ende der Datei durch Auffuellen mit 0x00 ausgleicht um die Dateigroesse richtig herzustellen.

Eigenartig

Nun habe ich einfach die "schwarzweiss.bmp" in "schwarzweiss.txt" umgewandelt und sie wieder durch den Algorithmus gejagt.
Man sollte davon ausgehen, dass nun die 0x00 richtig erkannt werden. Leider Fehlanzeige.
Nein, auch hier laesst der Algorithmus die 0x00 geschmeidig weg.

Muss ich das verstehen

Leider kann ich "fstream"-Objekte nicht verwenden, da ich fuer PocketPc code.
Ich verwende fopen, fread, fwrite, etc.

Hat wer 'ne blasse Ahnung woran das mit den 0x00 liegen koennte
Zusammengefasst: Bei Textdateien erstellt mit irgendeinem Texteditor liesst er 0x00 einwandfrei und bei Bitmapdateien nicht.


Gruss
sven

 

[Endurion]

Klingt verdächtig nach einem fopen ohne dem "b", also nicht binärem Modus.

Bei Text-Dateien ordnungsgemäß 0 zu lesen heisst nicht allzuviel, weil bei Textdateien gibt es höchstens eine 0, und zwar ganz am Ende, wenn überhaupt.

Zeig mal deinen Einlese-Code.

 

[Specialguest@home]

wir lesen binar ein -> "rb")

FILE *inDatei;
inDatei = fopen("\\text.txt", "rb");

int Dateigroesse = 0, wert = 0;
fseek (inDatei,0,SEEK_END);
Dateigroesse = ftell (inDatei);
fseek (inDatei,0,SEEK_SET);
char *Puffer = new char[Dateigroesse+1];

if(inDatei != NULL)
{
	wert = fread(Puffer, 1,Dateigroesse,inDatei);
}
fclose (inDatei);

Das gazne haben wir auch zeichenweise gemacht!

FILE *inZip;
inZip = fopen("\\gezippte.rar", "rb");
int Dateigroesse = 0, wert = 0;
fseek (inZip,0,SEEK_END);
Dateigroesse = ftell (inZip);
fseek (inZip,0,SEEK_SET);

char *Puffer = new char[Dateigroesse];
Puffer = "";
char *Puffer2 = new char[2];
*(Puffer2+1) = '\0';
int j=1;
do{
           wert = fread(Puffer2,sizeof(char),1, inZip);
           strcat(Puffer, Puffer2);
           j++;
} while(j<Dateigroesse);
fclose (inZip);

Da wir auf PPC proggen, kann es sein das dort ein komflikt mit Unicode und ANSI handelt?
Wir haben bereit simple textdateien mit PPC geschrieben und da mußten wir den zu specihernen Stream mit wcstombs konvertieren!

sven

 

[Specialguest@home]

schreiben tun wir auch binar

FILE *EntzipDatei;
EntzipDatei = fopen("entzippte.txt", "wb");
fwrite(neu, 1, neuLen, EntzipDatei);
fclose (EntzipDatei);

sorry vergessen!

sven

 

[rockbaer]

Welche Funktion aus der zlib verwendest du zum komprimieren?

 

[Specialguest@home]

large_inflate unf large_deflate
Aus der example.c

sven

 

[Endurion]

Das erste Einlese-Sample sieht eigentlich ok aus, beim zweiten gibt's vermutlich Probleme, sobald eine 0 auftaucht.

Du sagst, dass da evtl. Unicode im Textfile steht? Dann sind sehr wahrscheinlich haufenweise 0en drin. strcat ist dafür dann absolut ungeeignet, wenn das letzte gelesene Zeichen eine 0 ist, wird diese mit strcat NICHT angehängt, da es dann einen leeren String sieht (C-Strings, 0 ist das abschliessende Zeichen, der Ende-Marker).

Wenn's um die zlib-Befehle geht, muss ich leider passen.

 

[Specialguest@home]

Okay ENTWARNUNG

Es klappt soweit! Wir haben einfach beim zeichenweisen Einlesen der BMP datei jeden Zeichen geprüft und wenn es 0x00 ensprach dieses einfach siimpel maskiert! Wir haben uns für unsere Zwecke ein Zeichen aus dem BMPcode rausgenommen welches "sogut" wie nie vorkommt! und zwar '55'

55 == schwarz weiß schwarz weiß schwarz weiß schwarz weiß

keine Sau kann so eng nebeneinander pixel aufm PPC zeichnen!
Ist zwar noch ein kleines Restrisiko! Aber wir werden es erstmal so testen und ggf nochmal drüber nach denken!

Mit der 0 in der txt hatten wir uns wohl vertan! Habt recht dies kommt kaum vor höchtens mal am ende!

thx a lot

sven

 

[rockbaer]

Versuch mal anstatt deflate/inflate compress2/uncompress zu benutzen, dann sollten auch 0bytes kein Problem sein.

 

[Specialguest@home]

Wir haben das so weit umgestellt!
jedoch leifert die compress methode nicht wie die inflate die Dateigröße als rückgabewert zurück!
Wie komme ich da sonst ran?

Also ich brauche dir Größe des BYTE in das ich reingeschrieben habe!
irgendwie so was wie getlength()!
sven