Newsgroup: it.comp.lang.c
Titolo: File binari

Ciao a tutti i frequentatori del NG.
Come posso far capire al mio programma di apertura di file di testo,
che un file è in formato binario,  e quindi di evitare di aprirlo. 

 che un file è in formato binario,  e quindi di evitare di aprirlo.
con la sfera di cristallo?
scherzi a parte un file di testo è sempre un file binario , l'unica
differenza è che nel primo la serie di caratteri ascii è limitata, ora per
effettuare tale discriminazione è sufficiente leggere i primi byte se sono
appartenenti alla serie ascii base è di testo altrimenti è un file binario.
semplice.

blindonet wrote:



Questo ovviamente l'hai letto nella sfera di cristallo :-)
Non esiste nessun metodo per sapere quali caratteri sono contenuti
all'interno di un file. L'unico metodo e' affidarsi all'estensione:
sempre che esista e sempre che chi ha realizzato il file abbia deciso
di seguire una qualche convenzione comunemente accettata.
Non e' raro trovare (soprattutto nel mondo Unix) file con estensione
".doc" che sono dei semplici file di testo.
Altrimenti provare.
C:\>iao Angelo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


se leggi i file e gli stessi contengono caratteri non visualizzabili come da
standard TTY sono da considerare binari.
Almeno tanto tempo fa era così.
il fatto che esistano file binari con convenzioni di formattazione non li
equipara a documenti di testo.
del resto i principali programmi di editor utilizzano appunto tale tecnica
discriminatoria.

 discriminatoria.
E si vede [1]. :-)
Non e' piu' sensasto affidarsi all'estensione e dire che il file e'
corrotto se non trova l'intestazione corretta?
C:\>iao Angelo
[1] Mai provato ad aggiungere qualche new line ad un file di word
    e a riaprirlo.


 corrotto se non trova l'intestazione corretta?
Dici di leggere l'estensione e, se e' riconosciuta, dare per scontato che 
sia del tipo giusto? Beh, a me pare che molti programmi per windows (se non 
DOS/Windows stessi) facciano cosi', eventualmente poi segnalando errore se 
si accorge che il file non e' correttamente formattato.
-- 
Mox
"Trust the programmer."
"Don't prevent the programmer from doing what needs to be done."
"Keep the language small and simple."
"Provide only one way to do an operation."

 si accorge che il file non e' correttamente formattato.
Pare che WinWord non lo faccia.
Salva un file vuoto con estensione ".doc", aggiungici in testa qualche
"\n" con un editor e riaprilo con WinWord.
Con Word 97 sr1, viene visualizzato un mucchio di porcheria che sparisce
quando gli "a capo" vengono rimossi.
C:\>iao Angelo


 (
http://freshmeat.net/projects/file/
):
Il comando "file" _prova_ a classificare il contenuto del file e lo fa
basandosi su un magic number che ricava dal file.
Prova, non e' detto che ci riesca [1] :-)
C:\>iao Angelo
[1] Anche se conoscere "several thousands" di "magic number" aiuta
    parecchio :-)


 che un file è in formato binario,  e quindi di evitare di aprirlo. 
"Evitare di aprirlo" hai solamente la possibilità di intuirlo dal 
filename... se vuoi una prova un po' più attendibile devi leggerlo e 
interpretarlo. Un file di testo ha solo caratteri a 7bit.
 

 ... Un file di testo ha solo caratteri a 7bit.
Ma non e' detto che un file che abbia solo caratteri ascii a 7 bit
sia necessariamente un file di testo.
A voler essere pignoli un file di testo dovrebbe essere un file con
caratteri per i quali il test isprint() risulta vero (piu' il carattere
'\n' ovviamente :-)).
C:\>iao Angelo


 '\n' ovviamente :-)).
ai mie tempi si studiava che un file di testo doveva essere conforme agli
standard definiti da TTY per le trasmissioni tra terminali stupidi.
a 7 bit
ora il termine si è esteso
ma indipendentemente dagli strumenti utilizzati per ottenere un testo
(standard C come printf) i riferimenti normativi relativi dovrebbero fare
capo alle definizioni ASCII non estese (quindi 7 bit)
in rete cercati gli standard ISO relativi.
alcuni riferimenti li trovi nella codifica UNICODE o su W3C

 a 7 bit
A questo punto (forse) dovremmo metterci d'accordo su che cosa si intende
per file di testo. E' possibile che io intenda qualcosa di piu' limitato.
Per quanto mi riguarda mi viene difficile considerare "di testo" un
file che contenga solo '\a'. In generale, un file di testo mi aspetto
di leggerlo, non di ascoltarlo. Questo non vuol dire che il mio modo di
vedere le cose sia corretto. Ripeto la mia visione delle cose potrebbe
essere piu' ristretta.


 essere piu' ristretta.
sono pienamente d'accordo su questo.
in ogni caso dato che la questione tanti anni fa' fu oggetto di analisi e
discussione dogmatica ed accademica tra università
del resto il riferimento a regole definite ISO a cui sia SGML che HTML e via
dicendo si sono dovuti attenere è dato appunto da tale diversità d'opinione
ora che tutto è binario per la grande velocità di trasmissione spesso non si
conoscono i principi della formazione dei cosiddetti standard, nati con la
perforazione delle schede e la trasmissione di dati a 7 bit (non esistevano
ancora i monitor pertanto la codifica dei dati era di vitale importanza)
in alcuni vecchi programmi di emulazione terminali ancora è attivabile la
codifica solo testo (anche su windows la puoi trovare) e quello è lo
standard.
tutto il resto è qualcosa di aggiunto.
ricordo ancora le discussioni ad usare il set ascii esteso che alcuni
puristi della programmazione escludeva per problemi di compatibilità,
infatti ancora oggi tale codifica è differente in alcuni paesi (Italia fra
questi), con l'avvento di UNICODE si è cercato di colmare tale assurdo
contrasto ideologico.
chi di voi ha lavorato su spectrum o cbm64 saprà che avevano codici ascii
estesi proprietari, le cornici tonde tanto per citare qualcosa.
comunque se ti va' di fare archeologia informatica sicuramente troverai le
definizioni dogmatiche dei file di testo.
il ricorso alla identificazione mediante estensione non è standard, dato che
è strettamente legato al SO che gestisce i loader, alcuni puristi potrebbero
storcere il naso.

 sapere se un file e' di testo o meno devi leggerti TUTTI i caratteri.
Ovviamente e' falso anche questo.
Non vedo che cosa mi impedisca di fermarmi, nella lettura, al primo
carattere che non sia stampabile. In realta', nella stragrande maggioranza
dei casi, questa lettura si ferma ai primi caratteri (se non al primo) di un
file cosiddetto "binario". E' chiaro che se, invece, sto analizzando un file
di testo, mi trovero' a scorrere tutti i caratteri, ma questo non vuol dire
che *sempre* debba leggerli tutti. Se un file contiene caratteri non
stampabili, *certamente* non dovro' leggerli tutti per riconoscerlo.
In secondo luogo, ricordo che hai scritto:
"Non esiste nessun metodo per sapere quali caratteri sono contenuti
 all'interno di un file. L'unico metodo e' affidarsi all'estensione:"
Tutt'altro. L'estensione non dice proprio nulla.
In realta', la distinzione file binario/file di testo non ha molto senso.
Bisognerebbe distinguere tra file contenenti SOLO caratteri stampabili e
sequenze di "a capo" da file contenenti ANCHE caratteri non stampabili.
Altrimenti sarebbe come dire che un numero razionale non e' un numero reale,
cosa palesemente falsa ;)
--------------------------------
Inviato via 
http://usenet.libero.it

 cosa palesemente falsa ;)
In effetti mi viene male pensare che i caratteri stampabili non siano
rappresentabili da numeri binari :-)
Ripeto, per me un file di testo e' un file che contiene solo caratteri
stampabili e "a capo". Forse non e' la definizione corretta, ma e' quella
che ritengo sia la piu' vicina alla mia visione di "testo", tipo quello
che si trova nei libri (ovviamente senza figure e girigori matematici :-)).
C:\>iao Angelo


 a 7 bit
Per  quando rigurada  il  C, la  definizione  di file  di  testo non  e`
ambigua. E` una  sequenza orientata  di caratteri, organizzati  in linee
terminate dal  carattere newline ('\n'). La corrispondenza  tra cio` che
viene  scritto ed  in seguito  riletto e`  assicurata solo  nel caso  di
caratteri stampabili  (isprint()), tabulazione  orizzontale, newline. In
tutti gli altri  casi il comportamento e` implementation  defined (ie. i
caratteri  scritti  potrebbero  essere  interpretati  come  sequenze  di
controllo o simili).
Nello  standard non  si parla  di codifica  ASCII a  7 bit. Nota  che la
codifica ASCII comprende anche caratteri non stampabili
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Not an editor command: Wq

 codifica ASCII comprende anche caratteri non stampabili
esattamente, come precisato in altro post  che evidentemente non è giunto
tempestivamente.
il riferimento a 7 bit era relativo alla definizione di file di testo
utilizzata nella comunicazione tra terminali stupidi
i caratteri non stampabili (cd codici di controllo)(in C sono stati
standardizzati con \n \t etc) e sono una reminiscenza di tali definizioni.

 de facto cos'e' "di testo" e cos'e' "binario".
Non e' stato zio Bill, e' una convenzione standard quella di aggiungere "t"
o "b" nella lettura dei file di testo, per quei sistemi che fanno
distinzione (DOS e VMS, per esempio).


 distinzione (DOS e VMS, per esempio).
Io sempre pensato che la colpa di "t", nella fopen() fosse colpa di zio
Bill, ma se mi parli anche di VMS (che ho usato pochissimo)...
allora la colpa non e' tutta di zio Bill.
Sono stato cattivo a sproposito :-)


 ... "t", nella fopen() fosse 
Ehm, della standardizzazione di "t", nella fopen() fosse ...


 Bill, ma se mi parli anche di VMS (che ho usato pochissimo)...
Il discorso da farsi e': la mia funzione di lettura ha bisogno di conoscere
la convenzione con cui e' strutturato il file che sto leggendo ?
Se il sistema che stai utilizzando usa un solo carattere per la codifica
dell'"a capo" (Unix/Linux/Macintosh/Plan9), questo problema non si pone,
perche' se leggi un file di testo come se fosse un file binario non cambia
nulla, '\n' corrispondera' a un carattere preciso e uno solo.
Se, invece, leggi da un file di testo sotto DOS (stessa regola generale si
applica a MVS e VMS), devi sapere che la coppia 0x13 0x10 e' quella dell' "a
capo" e quindi la tua funzione di lettura ha necessita' di conoscere in che
modo codificare '\n' in ingresso e in uscita.
Questo (e' intuibile) e' un aspetto strettamente legato alla piattaforma.
Come ha scritto Mike O'Dell nel suo "Perl Cookbook":
"The most brilliant decision in all of Unix was the choice of a single
character for the newline sequence."
[...]
"All systems use the virtual "\n" to represent a line terminator, called a
newline. There is no such thing as a newline character. It is an illusion
that the operating system, device drivers, C libraries, and Perl all
conspire to preserve. Sometimes, this changes the number of characters in
the strings you read and write. The conspiracy is revealed in Processing
Binary Files".


modo codificare '\n' in ingresso e in uscita.
Quando viene omesso il "t" il file viene comunque aperto in modalità
testo, succede così perché lo vuole lo standard o perchè dipende
dall'implementazione?
-- 
Marco Barisione (ICQ 84277092)

 dall'implementazione?
E`  richiesto  dallo  standard  C99. Non ho  documenti  ufficiali  sulle
versioni precedenti.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"La Via prosegue senza fine."
	Bilbo Baggins - Il Signore degli Anelli - J.R.R. Tolkien

 dall'implementazione?
Dipende dall'implementazione.
Per esempio, con Borland C++ Builder, la variabile globale _fmode governa il
modo in cui viene aperto il file, in caso di omissione o di "b" o di "t".
Se essa e' impostata su O_BINARY, allora il default e' binario, non testo.


 sia necessariamente un file di testo.
Ho detto una mezza cappella.
Esistono caratteri stampabili a 8bit, esistono caratteri non stampabili a 
7bit... 

Se essa e' impostata su O_BINARY, allora il default e' binario, non testo.
Perché il K&R non fa riferimento a "t" (almeno io non sono riuscito a
trovare nulla)? È una modifica introdotta dopo?
