Newsgroup: it.comp.lang.c
Titolo: aiuto:lettura dato esadecimale

ciao a tutti, mi chiamo Dario.
Sono un neofita di C ed avrei un problema potreste aiutarmi?:
dunque, devo leggere un file binario e copiarne solo alcune parti in un
altro.
I byte significativi che delimitano le parti da copiare sono (in
esadecimale) \x0D \x0A.
Pensavo di leggere un byte alla volta con
char unbyte[1];
FILE *fileinp;
fread(unbyte,1,1,fileinp)
/* e confrontare il singolo risultato con il primo esadecimale...*/
if (unbyte=="\x0d").......
ma non mi funziona.
Devo convertire il byte letto?  Posso confrontare il byte letto in questo
modo?
grazie a tutti.
ciao.

 if (unbyte=="\x0d").......
Visto che unbyte e' un array e che la roba tra doppi apici e' una stringa,
il confronto corretto e'
if(unbyte[0] == 0x0d)
{
}
invece quello che stai facendo tu e' un confronto tra puntatori.
C:\>iao Angelo
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

grazie.
Infatti usando getc ho risolto, confrontando il singolo carattere.


 wrote:


Si, ma il "byte" e' unbyte[0] e il carattere e´ '\x0d'
 
  if (unbyte[0]=='\x0d').......
ovvero
  char unbyte;
  FILE *fileinp;
... 
  fread(&unbyte,1,1,fileinp)
 
  if (unbyte=='\x0d').......
funziona.
-- 
Horst

 if (unbyte=="x0d").......
La risposta te l'hanno già data. Aggiungo un paio di cose:
- Non ha senso dichiarare un array di un solo elemento. Tanto vale
dichiarare una variabile scalare.
- Per leggere file binari è consigliabile usare "unsigned char" piuttosto
di "char". Con char, i valori da 128, 129, ..., 254, 255 ti vengono
interpretati come valori negativi: -128, -127, ... -2, -1. In teoria, in
ciò non c'è niente di male ma, in pratica, io mi ci troverei molto scomodo.
Quindi, il tuo programma lo riscriverei così:
   unsigned char unbyte;
   FILE *fileinp;
   if ((fileinp = fopen("pippo.bin", "rb")) == NULL)
      ...errore apertura...
   if (fread(&unbyte, 1, 1, fileinp) != 1)
      ...errore lettura...
   if (unbyte == 0x0D)
      ...fine record...
Al posto della fread() puoi anche usare la fgetc(). Funziona perfettamente
(a patto che apri il file con la specifica "rb") ma, personalmente, la
cosa non mi garba. Istintivamente, associo fgetc() ai file di testo e
fread() ai file binari.
--
Cingar
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

grazie ancora. Terrň anche questa soluzione.


bene,
tante grazie anche a te.


 il fila da leggere lo hai aperto in modalita' binaria?
Ma perchè in modalità binaria?
Scusate per la domanda apparentemente stupida, però un byte non è sempre 
un byte? anche se lo leggi come *testo*?
Scusate, non so se mi sono spiegato (il fatto è che in unix a quanto ho 
capito solitamente non c'è questa differenza).
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Xoen
Jabber ID : 
xo...@jabber.linux.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 capito solitamente non c'è questa differenza).
perche' quando viene letto in modalita' testo tratta
in modo differente i catteri che indicano il fine
linea, mi sembra.
non posso essere piu' preciso perche' uso pochissimo
windows e sono 10 anni che non apro un
file in modalita' testo...
ciao,
g.

 capito solitamente non c'è questa differenza).
Infatti: è questo dipende dal fatto che il C è nato su Unix, e dunque la
convenzione per la fine riga usata dal C è quella tipica di Unix.


 carattere 0x0A, come avviene in Unix.
Nitpick: la sequenza di fine linea, dipendente dall'implementazione,
viene convertita in '\n'. Non e` dato sapere il valore numerico di '\n'
;)
Riassumendo:
- Se scrivo '\n' su un file aperto in modo testo il carattere newline
  verra` espanso nella sequenza di fine linea appropriata.
- Quando viene letta (sempre in modo testo) la sequenza di fine riga
  viene convertita dalla libreria C in '\n'.
Inoltre lo standard lascia una liberta` completa all'implementazione,
che puo` trasformare come gli pare i dati scritti in modo da conformarsi
alla convenzione per i file di testo sull'host in questione.
Come effetto collaterale il numero di byte effettivamente scritti
(letti) sul file puo` differire dal numero di caratteri scritti dal
programma; fseek(), quindi, non puo` essere usato per posizionarsi
direttamente ad un certo punto del file, ma solo per tornare ad una
posizione precedentemente salvata con ftell().
Luca
-- 
Home: 
http://kronoz.cjb.net
Sono un mirabile incrocio tra Tarzan e Giacomo Leopardi.
In me convivono tutte le doti intelluttuali di Tarzan e
tutta la prestanza fisica di Giacomo Leopardi.
A. Borsani

 il valore numerico di '\n' ;)
Sì, sì, verissimo. In effetti, descrivevo solo il comportamento dei
compilatori che conosco personalmente (il M$-C/C++ per DOS/Windows e il
GCC per Linux), nei quali '\n' vale 0x0D. Ma, in effetti, scriviamo
'\n' aziché '\x0d' proprio perché il valore numerico di '\n' potrebbe
teoricamente essere qualsiasi cosa.
--
Cingar

   viene convertita dalla libreria C in '\n'.
A questo punto nasce spontaneo il dubbio: Ci sono quindi problemi di 
portabilità per file di testo, cioè se apro un file di testo in sola 
lettura tutto OK (se non ho capito male), però se ci scrivo da un'altro 
S.O. che usa una codifica di '\n' differente li mescolo, o no? è un 
problema?


 S.O. che usa una codifica di '\n' differente li mescolo, o no?
Anche in lettura si pone il problema. Se, ad esempio, su Linux leggo un
file di testo creato sotto Windows mi becco sia '\r' sia '\n'. 
kronos:/tmp$ cat p.c
#include <stdio.h>
int main(int argc, char **argv) {
        int c;
        FILE *f;
        if (argc < 2)
                return 0;
        if ((f = fopen(argv[1], "r")) == NULL)
                return 0;
        while((c = fgetc(f)) != EOF)
                printf("%02x\n", c);
        return 0;
}
kronos:/tmp$ xxd tmp.txt
0000000: 6162 630d 0a                             abc..
kronos:/tmp$ ./p tmp.txt
61
62
63
0d
0a
Questo perche`:
- La convenzione di fine linea su Linux e` '\n' e quindi la libreria C
  non si aspetta di fare conversioni.
- Lo standard POSIX non prevede distinzioni tra file binari e file di
  testo: nessuna conversione deve essere fatta. Quindi la libreria C non
  puo` cercare di agire in modo "furbo" per mascherare la differenza.
In linea teorica una libreria C potrebbe cercare di "indovinare" il
formato del file di testo ed effettuare la conversione al volo, in
pratica non mi risulta che questo venga fatto da nessun implementazione.
Tipicamente si lascia questa operazioni al layer superiore.
Luca
-- 
Home: 
http://kronoz.cjb.net
"La donna è coinvolta sessualmente in tutti gli affari della vita. A
 volte perfino nell'amore." -- K. Kraus