Qualche buona ragione per aprire i file in modalità testo?

Question

Qualche buona ragione per aprire i file in modalità testo?

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

4

I sistemi operativi (quasi) POSIX e Windows sono noti per distinguere tra I / O di file 'modalità binaria' e 'modalità testo'. Mentre la modalità precedente non trasforma alcun dato tra il file o il flusso reale e l'applicazione, quest'ultima "traduce" il contenuto in un formato standard in una modalità specifica della piattaforma: le terminazioni di riga vengono convertite in modo trasparente in '\n' in C, e alcune piattaforme (CP / M, DOS e Windows) tagliano un file quando viene trovato un byte con valore 0x1A .

Queste trasformazioni mi sembrano un po 'inutili.

Le persone condividono file tra computer con sistemi operativi diversi. La modalità testo causerebbe la gestione di alcuni dati in modo diverso su alcune piattaforme, quindi quando ciò è importante, è probabile che utilizzi la modalità binaria.

Ad esempio: mentre Windows usa la sequenza CR LF per terminare una riga in modalità testo, la modalità testo UNIX non tratterà CR come parte della sequenza di fine riga. Le applicazioni dovrebbero filtrare quel rumore da soli. Le versioni precedenti di Mac utilizzano solo CR in modalità testo come terminazioni di riga, quindi né UNIX né Windows potrebbero comprendere i suoi file. Se ciò è importante, un'applicazione portatile probabilmente implementerà l'analisi da sola anziché utilizzare la modalità testo.

L'implementazione dell'interpretazione newline nel parser potrebbe anche eliminare un po 'di overhead dell'utilizzo della modalità testo, poiché i buffer avrebbero bisogno di essere riscritti (e possibilmente ridimensionati) prima di tornare all'applicazione, mentre ciò potrebbe essere meno efficiente di quando accadrebbe nel applicazione invece.

Quindi, la mia domanda è: c'è qualche buona ragione per fare ancora affidamento sul sistema operativo host per tradurre terminazioni di linea e troncamenti di file?

file-handling portability parsing

posta Rhymoid 19.11.2011 - 17:42

fonte

3 risposte

2

Mentre Unix (MacOS-X è Unix allo scopo di questo) e Windows considerano i file come un flusso di byte e differiscono solo in alcuni piccoli dettagli su cosa sia un file di testo e cosa no, quando altri SO entrano in gioco gioca hai più varietà. Tre esempi:

in alcuni sistemi operativi, i file di testo sono un insieme di linee a larghezza fissa e le linee sono riempite con spazi fino alla larghezza fissa (e sai capire perché C e C ++ non garantiscono che gli spazi alla fine di un linea sono conservati)
altri sistemi operativi hanno una nozione di numeri di linea permanenti e il runtime C deve saltare,
la chiamata di sistema (per usare una terminologia Unix) usata per aprire un file di testo può essere diversa da quella usata per aprire una binario.

Probabilmente potresti immaginare un modo per non specificarlo, dovresti abbandonare l'interoperabilità per i tuoi programmi C o C ++ con quelli che rispettano la convenzione del sistema operativo.

risposta data 19.11.2011 - 18:06

fonte

1

Con la lettura in modalità testo, hai qualcosa come "caratteri", binario conosce solo byte.

Almeno in Ruby 1.9 puoi definire una codifica, quando leggi un file in modalità testo.

Esempi:

File.open('sample.txt', 'r') # Read in default encoding
File.open('sample.txt', 'r:utf-8') # Read a utf-8 file
File.open('sample.txt', 'r:utf-8:cp1251') # Read a utf-8 file and convert it to cp1252

Facendo questo, hai la possibilità di fare differenze tra byte e caratteri. Quando leggi binario, hai solo byte.

risposta data 19.11.2011 - 21:50

fonte

Leggi altre domande sui tag file-handling portability parsing

Serve aiuto con la struttura delle directory nel porting codebase su SVN Come salvare le immagini in file in un'applicazione web ed evitare di rimuoverli con ogni build?

score 4 · Accepted Answer

Senza la traduzione, ogni programma di elaborazione di testo Unix riconoscerebbe solo '\n' come un indicatore di fine riga e ogni programma di elaborazione testi di Windows riconoscerebbe '\r' seguito da '\n' . (E i programmi Mac pre-OSX riconoscono '\r' .) E qualsiasi programma che scrive testo dovrebbe scrivere esplicitamente il marker di fine riga locale, il che significa che dovrebbe essere a conoscenza di su quale sistema operativo è in esecuzione.

E questo riguarda solo i casi relativamente semplici in cui una fine riga è indicata da una sequenza di caratteri. Altri schemi sono comuni (anche se meno in questi giorni); vedi IBM mainframe e VMS, per esempio.

Con la traduzione, i programmi possono semplicemente trattare il testo come testo e non abbiamo bisogno di tre o più programmi "ciao, mondo" diversi.

Questo a volte causa problemi quando è necessario elaborare un file esterno (un file di testo di Windows che è stato copiato su un sistema Unix o viceversa). Cygwin, un ambiente simile a Unix che gira sotto Windows, è una ricca fonte di tali problemi. Ma di solito la soluzione migliore è tradurre il file prima di elaborarlo. E la maggior parte delle volte, i programmi si occupano di file di testo che sono stati creati sullo stesso sistema operativo.

È meglio scrivere un programma in grado di tradurre tra i formati, piuttosto che richiedere un programma ogni per gestire tutti i diversi formati. E inevitabilmente qualcuno scriverà uno strumento che comprenda i formati Unix e Windows, ma si rompe quando viene confrontato con un vecchio file di testo Mac, e qualcun altro potrebbe interpretare l'interpretazione un po 'male perché la ruota che hanno reinventato non era perfettamente round.