Newsgroup: it.comp.lang.c++
Titolo: [SEMI OT] codici ASCII

sto cercando di scrivere un semplice editor esadecimale (tipo AXE ma mooolto
più semplice)
ma non riesco proprio a capire come funzionino i codici ASCII.
Ho scritto il prog. ma mi sono accorto che la visualizzazione di Axe era
diversa dalla mia. alla
fine ho capito che i codici ASCII da 127 (o 128) fino a 255 non
corrispondono (mentre da 0 a 127 si)
Ad es. se leggo il carattere  ¢  in una variabile di tipo "char" mi
restituisce un negativo, se uso
unsigned char mi restituisce 127 + il numero negativo (sul mio pc 189), ma
ciò non corrisponde a quello che "vede"
AXE che magari per lui corrisponde a 212. Non sono riuscito a trovare
nessuna corrispondenza!! aiutatemi!
Un'altra cosa, ma poi su MSDN c'è una tabella di codici ASCII
"internazionale" come pure da molte parti si
trovano queste tabelle, ma mai che ce ne sia una uguale all'altra. Se faccio
ALT+numero non c'è ne uno che
corrisponda (da 128 in poi)
ciao

 corrispondono (mentre da 0 a 127 si)
Il codice ASCII e' definito su 7 bit. Quindi solo i codici da 0 a 127 sono
definiti. Tutto il resto va spesso sotto il nome di "ASCII esteso". E ci sono
molte diverse estensioni.
Questo dovrebbe spiegare il tuo arcano.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


Aspetta, aspetta. ok questo spiega molte cose ma non mi č di molto aiuto.
Cioč, io assumo che AXE funzioni in modo corretto (e al 99% lo fa)
quindi lui "vede" un qualsiasi tipo di file come una sequenza di:
A0 FF 01 55  hex
che corrispondono a (tiro a caso)
180 255 1 87 d
Ora i riesco a "leggere" correttamente 1 e 87 ma 180 e 255 non
corrispondono.
Se tramite AXE cambio il codice FF in F0 mi aspetto che nel file sia
rispecchiato
un comportamento coerente ,ed il valore che ho cambiato deve essere riflesso
in
un modo giusto.
Ma se con il mio programma al posto di FF leggo magari CF, che
faccio???
Cioč ancora: da AXE leggo il file prova.dat e trovo che due byte sono ad
esempio:
 FF F0 quindi nel file c'č un campo che prende
questi valori, se non mi sbaglio li legge da destra a sinistra, e magari
corrispondono
al valore  8567,  io leggo lo stesso file prova.dat e leggo invece CF C0 che
mi corrispondono a 6201 !!!!???
cioč allora AXE usa una tabella ASCII sua personale, visto che quella
che "vede" il debugger del C++ č diversa? scusa ma ho una discreta
confusione
in testa
ciao e grazie

ciň non corrisponde a quello che "vede"
ASCII e' un codice formato da una parte standard (a 7 bit,
da 0 a 2^7-1, ovvero da 0 a 127) e una parte estesa.
Poi, dei caratteri da 0 a 127 solo una parte e' "printable"
(credo nell'intervallo 31-127).
Il numero negativo che ottieni e' il classico "wrap around",
dovuto all'overflow di valori contenibili nel tuo char.
--
CyberWalkie - walkietalkie(at)
libero.it

 in testa
La tabella ASCII non c'entra nulla. Nei tuoi esempi tu stai parlando di file
binari, non di file testo.


ma, io spero che sia dovuto al caldo....
ho riguardato ora il programma, ed in effetti tutto funzionava regolarmente.
Avevo
riguardato il debug almeno 10 volte, e quello che mi diceva era CHE ERA
GIUSTO
ma non me ne accorgevo...
Io leggevo il file in un  "unsigned char cBuf[512]" e corrispondevano sia i
numeri decimali sia
la conversione in codice ASCII (anche quello esteso), esattamente come in
AXE.
solo che poi, non si sa perchč, prima creavo una CString str_file dal
vettore cBuf, poi
definivo  int hex[3000] e mi ostinavo a fare un ciclo
hex[i] = __toascii(str_file.GetAt(i));   <-- e qui sbaglio di brutto,
toascii funziona da 0..127!
inoltre la cosa bella č che tutte queste complicazioni sono INUTILI, per
quello che
voglio fare mi basta cBuf !!!
ma, speriamo bene

 toascii funziona da 0..127!
E sopratutto quello che facevi non aveva molto senso. Pensaci.
Accendi il condizionatore: aiuta molto.
