Newsgroup: it.comp.programmare
Titolo: Terminazioni di riga

Sto tentando di scrivere un piccolo script in Python per convertire le  
diverse terminazioni di riga (unix, mac, dos). Noto che usano 
rispettivamente (LF, CR, CR+LF), mi chiedevo quanto fosse possibile per 
ciascun tipo di file contenere gli altri terminatori (rispettivamente CR, 
LF, CR o LF isolati) per altri scopi all'interno del testo.
Per essere più chiari, dato ad esempio un file dos, quanto è probabile 
trovare un LF isolato con scopo diverso da "terminatore di riga"? E' una 
pratica frequente usare questi caratteri per altri scopi?
Grazie

Giano ha scritto:

Se un file e' un file di testo, allora c'e' un solo terminatore di riga
alla fine di ogni riga e non ce ne sono altri (se ci fossero sarebbero
terminatori di riga).
Il problema invece e' un altro: attualmente, per colpa di un po' troppa
liberta' che i sistemi operativi concedono, e' facile trovare all'interno
di un file ascii dei caratteri che ascii non sono (unicode o altre
mappature), e in tal caso, volendo convertire da DOS a MAC, per esempio,
non ti basta cambiare il terminatore di riga, ma devi anche andare a
modificare tutti questi caratteri, lettere accentate, simboli e compagnia
bella.
Siccime esistono gia' funzioni che svolgono questo compito egregiamente,
forse cio' esula dal tuo esercizio in python. Vedi tu.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 forse cio' esula dal tuo esercizio in python. Vedi tu.
Che funzioni? So che esistono tonnellate di editor che lo fanno, ma non 
Gedit che è quello che uso. Mi sarebbe piaciuto uno scriptino che 
prendesse come input nome del file, tipo target e convertisse.
Grazie per la risposta intanto!

 prendesse come input nome del file, tipo target e convertisse.
Con vi e' un attimo togliere i ^M a fine riga, e altrettanto aggiungerceli.
Senza vi, si puo' fare con sed, o con tr.
Una riga di comando senza tirare in ballo il python.
La differenza e' che sono io che vedo il formato e lo modifico di 
conseguenza.
sed -e 's/\r$//'  per togliere il ^M
sed -e 's/$/\r/'  per aggiungercelo

 sed -e 's/$/\r/'  per aggiungercelo
Che dire... Grazie mille per la consulenza completa, precisa e puntuale. 
Cercherò di risolvere in altro modo... Sed mi attira, mi interessai un 
po' di tempo fa ma mi pareva un po' troppo criptico. Riproverò!
Grazie ancora

 terminatori di riga).
Se un file � di testo (ma formalmente i file "di testo" non esistono, la
definizione � solo convenzionale) pu� possedere diversi terminatori di
riga, a seconda del sistema operativo: su Windows CR + LF, su Unix LF, su
Mac CR, etc.. Questo non dipende dalla "troppa libert�" concessa dai
sistemi operativi (l'aggettivo "troppo" implica una connotazione negativa
che non ha senso in questo contesto), ma da scelte implementative precise.
Poi, per la cronaca, non esistono "file ASCII", esistono aggregati di byte
chiamati comunemente "file", i quali possono contenere sequenze di byte
interpretate secondo certe convenzioni (codifiche Unicode comprese). Un
file si intende "di testo" perch� � editabile con un normale editor; anche
un file contenente sequenze Unicode secondo una certa codifica �
considerabile un file "di testo" bench� molto probabilmente non
corrisponda a ci� che tu intendi per "file ASCII".


 Attenzione.
Attenzione?
UTF-8 � una codifica Unicode standard. Come fa ad essere incompatibile tra
una piattaforma e l'altra? spiega che cosa intendi e sopratutto cosa
significa per te "a livello di codice ascii".


 "file ASCII".
Questo riapre la discussione.
1) E' vero o no che passando da un sistema operativo ad un altro vi sono 
incompatibilità fra codifiche?
2) Prendendo un "file di testo" (insieme di byte mostrato dall'editor 
come sequenza di righe, separate da "terminatori") e cambiando 
opportunamente il terminatore, si ottiene un file di testo che, su un 
altro sistema operativo, si presenta allo stesso modo?

 altro sistema operativo, si presenta allo stesso modo?
No, il punto non è il sistema operativo ma quale codifica usano i 
programmi finali che visualizzano il file. Se tu salvi con una codifica 
su di un sistema e pretendi di decodificare, sullo stesso sistema ovvero 
su uno diverso, usando un'altra codifica avrai dei problemi, e ci puoi 
mettere tutti i cambi di terminatore riga che vuoi che i problemi 
rimangono.
Quello che può cambiare da un sistema all'altro è la codifica standard 
cioè quella che probabilmente useranno i programmi in cui non si 
specifica nulla, magari perché le API di sistema ce l'hanno come default.

 default.
Comunque sia, il problema sta solo nei terminatori (e 
nell'interpretazione che viene loro data da software) o anche da altre 
cause?

Giano wrote:

La domanda era gia' chiara prima, non e' necessario ripeterla.
Come Andrea ha cercato di spiegare, il problema del "terminatore" e' 
banale in confronto a quello della codifica dei caratteri:
http://en.wikipedia.org/wiki/Character_encoding
Scusa l'insistenza, ma non mi e' chiaro se tu sia al corrente, ad 
esempio, delle differenze tra Unicode e UTF-8, o tra 8859-1 e cp1252

 esempio, delle differenze tra Unicode e UTF-8, o tra 8859-1 e cp1252
Sono al corrente delle differenze fra codifiche, cosa sono, cosa vogliono 
dire. Non sono al corrente di quale sia la concezione "convenzionale" di 
file di testo di un certo tipo, cioè cosa effettivamente sia un file di 
testo Windows o Unix o Mac. Ho ripetuto la domanda perchè nei vari post, 
c'è chi dice che il problema stia anche nella codifica, altri solo nel 
terminatore. Io ho sempre pensato solo al terminatore, la codifica è un 
altro problema. Ma c'è chi ha detto il contrario e per questo ho 
domandato nuovamente.

 altro problema.
Devi definire cosa intendi con "il problema", vedi bene che usando una 
definizione così vaga per qualcun altro ci rientrano anche questioni di 
codifica che invece tu chiami ”altro problema".
Un esempio di spiegazione può essere:
"ho creato un file su windows con Write che usa MFC l'ho messo su IIS e 
l'ho copiato su un sistema UNIX via http con questa pagina poi da lì 
l'ho spedito per posta elettronica ad un Mac e alla fine aprendolo con 
TextEdit non si leggono bene i terminatori di riga" 
a questo magari si può trovare una risposta, la risposta a "il problema" 
invece non si può dire quale sia.
Oppure è solo 42.

 Oppure è solo 42.
Cosa significa?
Grazie per la pazienza!

 Cosa significa?
Eh, questo è compito tuo.

 significa per te "a livello di codice ascii".
Per codice ascii intendo il carattere corrispondente ad un valore numerico
da 0 a 255
Questo:
     printf("%cn", cod);
Con cod che va da 32 a 126 ottengo lo stesso risultato su tutte le
piattaforme.
Con cod minore di 32 o maggiore di 126 ottengo risultati diversi a seconda
delle piattaforme o del codepage, o di qualche altro cavolo di mappature o
transcodifiche.
Poi ci sono i caratteri unicode che sono formati da una coppia di byte,
che alcuni editor e/o alcuni sistemi interpretano correttamente
visualizzando il carattere corrispondente, altri invece non interpretano e
visualizzano in "row mode" una coppia di caratteri corrispondenti al
codice ascii dei singoli byte.
Non aiutano in questo senso neppure le primitive di lettura.
Che se io definisco un tipo char e leggo i caratteri del file un byte alla
volta, non riesco ad interpretare gli unicode.
Se invece utilizzo il tipo che mi incapsula correttamente gli unicode,
devo usare una funzione di lettura specifica e non la getc()
Insomma e' un casino.
Ed e' ancora piu' un casino farsi capire dall'utente, che manda un file da
interpretare e manco sa in che formato lo manda.


 Grazie per la pazienza!
Siamo qua apposta.


 Con cod minore di 32 o maggiore di 126
Senza il minore di 32 e che io ricordi la codifica ASCII è a 7bit.

 Poi ci sono i caratteri unicode che sono formati da una coppia di byte,
Coppia? Non proprio!
In utf-8, fino a 6 bytes.

  
rmont...@gmail.com
 (Roberto Montaruli) wrote:


Minori di 32 sono i codici di controllo, che in dos fanno visualizzare
faccine o similari, ma che sono considerati codici di controllo, movimenti
del cursore, prefissi di sequenze di escape, cose del genere.
Il set di caratteri comincia dallo spazio, ascii 32 (0x20).


 Coppia? Non proprio!

Addirittura 6 byte?! 
Piu' di un float per un carattere?
Ma che cosa devono codificarci? Il klingoniano?


 Insomma e' un casino.
?
Nessun casino, a mio parere. Un casino per chi?


 Ma che cosa devono codificarci? Il klingoniano?
Non capisco il tuo "addirittura", non vedo dove sia il problema. E che
c'entrano i float? Esistono linguaggi del mondo in cui viviamo che
necessitano di molte informazioni per essere rappresentati. Comunque,
nonostante UTF-8 possa gestire fino a 6 byte, in realt� ne vengono usati
da 1 a 4.


 dire. Non sono al corrente di quale sia la concezione "convenzionale" 
Un file � un file: formalmente non esiste il "file di testo" e il "file
binario" (che poi "binario" non vuol dire assolutamente nulla). Una
definizione in questo senso non � di alcuna importanza. Si d� al "file di
testo" un significato puramente convenzionale, ovvero una sequenza di byte
che risultano leggibili e scrivibili dal'utente secondo le regole di
lettura e scrittura dell'utente. Prima dell'avvento di Unicode e delle
varie trasformazioni, si tendeva ad attribuire anche un significato
"fisico" al file di testo: una sequenza di byte corrispondenti ai codici
ASCII stampabili, disposti per "righe", ovvero secondo sequenze
intervallate da "terminatori di riga" (anch'essi convenzionali).


 Il set di caratteri comincia dallo spazio, ascii 32 (0x20).
Il codice ASCII inizia da 0. Quelli di cui tu parli sono i "caratteri
stampabili".


 Il klingoniano?
L'alfabeto della lingua klingon non e' stato incluso in Unicode sulla
base della motivazione che quelli che scrivevano in tale lingua solevano
usare l'alfabeto latino in ogni caso. Di conseguenza la l'alfabeto della
lingua klingon non e' codificabile con UTF-8.
-- 
-riko

 Siamo qua apposta.
Non è scontato, e non è così per tutti! Comunque sia grazie a tutti 
coloro che hanno risposto e mi hanno aiutato. Spero di poter ricambiare, 
all'occorrenza.
Saluti

 editor che pure ho provato non mi soddisfano per nulla.
Dicono che Scite/Scintilla facciano faville (e passatemi il doppio 
senso).
Mi pareva anche ci fosse una applicazione per win che assomigliava a 
TextMate, se non ricordo male gli sviluppatori si sono scambiati 
suggerimenti e idee. Ma la devi trovare da solo.

 stampabili".
Appunto. Si parlava di un file di testo, ovvero costituito da caratteri 
stampabili, piu' questo terminatore di riga che cambia in base al 
sistema operativo.
Ora che ci penso, in dos i files di testo terminavano anche con un ^Z, 
ultimo carattere del file.

 ultimo carattere del file.
Si tratta del codice ASCII 26. Non doveva essere necessariamente l'ultimo
carattere del file. La tecnica di inframmezzare un byte 26 nei file
compilati era spesso adottata da Borland, per esempio. Invocando un type
sul file compilato si ottenevano a video informazioni (testo) sul
produttore del compilato.
