CR/LF und LF
-
Wieso werden Kombinationen CR/LF selbst dann automatisch (unter DOS/Win)
nach hex 0A gewandelt, wenn man Files mit ios::binary öffnet und daraus
mit read oder get liest ?
Wie öffnet man Files unter DOS/Win so, daß man
a) das File BYTE-weise (char) lesen kann ohne irgendwelche automatischen
Ersetzungen a la hex 0D0A --> hex 0A
und ohne, daß man bei manchen Daten Sachen wie FFFFFF80 liest, obwohl man
char einliest ?
-
Wirklich sicher, dass du binär öffnest und auch Byteweise liest?
Zeig mal Quellcode...
-
Hallo! Hier mal die relevanten Zeilen:
#define BREITE 16
char buf[ BREITE+1 ] ;
ifstream infile;switch( argc )
{
case 2 : mode = ios::in || ios::binary || ios::nocreate ;
} // ende switch
....Bla Bla...try
{ infile.open( argv[1], mode ) ;
...Blabla...
}
catch( int err )
{ ...BLABLA... }
// nun lesen:
do
{
infile.read( buf, BREITE ) ;
nread = infile.gcount( ) ;
for ( i=0 ; i < nread ; i++)
{
cout.width(2) ; cout.fill('0') ;
cout << hex << (unsigned int)buf[i] << ' ' ;
}
}
...Und so weiter.
Problem:a) Ausgabe manchmal von der Form "ffffff80" obwohl width(2) (siehe oben) !!??
(wohl, wenn das Byte über hex 80 ist und als negative Zahl interpretiert wird,
aber warum macht der das ?)b) CR/LF wird nach hex 0A gewandelt, ohne, dass Sachen wie hex 0D überhaupt
im Buffer landen !?!? Es wird aber definitiv ios::binary geöffnet.
Das ganze spielt unter DOS/Win mit ihren LF/CR-Seuqenzen (so ein Zirkus mit dem
Zeilenende-Zeichen, als
ob man sich da nicht mal einigen könnte mit den Unix'lern...)
-
dotc schrieb:
a) Ausgabe manchmal von der Form "ffffff80" obwohl width(2) (siehe oben) !!??
(wohl, wenn das Byte über hex 80 ist und als negative Zahl interpretiert wird,
aber warum macht der das ?)Weil width() nunmal nicht abschneidet.
-
aber wieso muss er denn abschneiden, wenn er char in hex verwandelt ??
00 bis ff geht doch in 2 Zeichen??
-
dotc schrieb:
aber wieso muss er denn abschneiden, wenn er char in hex verwandelt ??
Du bringst hier 2 völlig unterschiedliche Sachen durcheinander. char ist ein Datentyp, hex ein Datenformat. Du kannst das eine nicht in das andere 'verwandeln'. Was du hier machst, ist ein char (signed) in unsigned int zu casten. Und da ein vorzeichenbehafteter Wert nunmal nicht ohne weiteres in einen vorzeichenlosen Wert umgewandelt wird, gibt es hier diese Ausgabe. Dazu findest du aber mit Hilfe der Suchfunktion genügend Beiträge, um das warum und weshalb jetzt nicht schon wieder durchzukauen.
Wie kannst du das nun beheben? Eine einfache Möglichkeit wäre zB alle unnötigen Bits mit Hilfe des binären UND (&) auszublenden.
-
das problem ist die umwandlung char->unsigned int geht nicht direkt (wenn char signed ist), sondern wird vom compiler so gemacht: char->int->unsigned int. mach mal das ganze mit static_cast< unsigned int >( static_cast< unsigned char >( buf [ i ] ) ), oder deklarier den puffer gleich mit unsigned char.
-
Danke für die Tips; also nehme ich unsigned char für die Bytes.
-
Danke.
Habe den Buffer buf jetzt als unsigned char deklariert; die Darstellung als
hex sieht nun OK aus, der Fehler ist also offenbar behoben.Es bleibt aber das zweite Problem bestehen: Wieso werden 0A0D (LF/CR) automatisch
in LF (hex 0A) verwandelt, obwohl das File mit ios::binary geöffnet
wird ?
-
Danke für Eure Hilfe, den entscheidenden Fehler habt Ihr
(sorry...) leider nicht gefunden; ich hab' ihn nun selbst gesehen:mode = ios::in || ios::binary || ios::nocreate
muss heissen:
mode = ios::bin|ios::binary|ios::nocreate
Jetzt geht's auch mit CR/LF wieder richtig.
Ciao