Newsgroup: it.comp.software.newsreader
Titolo: tormentone: 7 bit / 8 bit

Illustrissimi,
da quando mi avete dato qualche ragguaglio sulla codifica dei caratteri
sono un po' meno ignorante di prima, ma proprio perché ora so di non
sapere mi ritrovo con un sacco di dubbi. Per di più sono stato invitato
a fare _tabula rasa_, il che mi fa dubitare anche delle cose che
ritenevo più scontate.
Direi allora, se la cosa non vi offende, di ripartire dal caro vecchio
ASCII.
Come sappiamo l'ASCII codifica un massimo di 128 caratteri (fra
caratteri di controllo e caratteri stampabili), numerandoli da 0 a 127.
Poiché 128 è uguale a 2^7, sono sufficienti 7 bit per codificare l'ASCII
con delle sequenze binarie. Per come la so io (ma a questo punto
comincio a dubitare anche di questo) un file ASCII è costituito da una
sequenza di byte di 8 bit ognuno, nei quali il primo bit non codifica,
ed è posto uguale a 0 (anche se, pensandoci meglio, mi sembra di aver
letto che in alcuni casi viene usato per definire la "parità" del byte -
è vero?). Pertanto anche quando usiamo una codifica a 7 bit (come nel
caso dell'ASCII) il singolo byte è pur sempre costituito da un
"ottetto".
Ora, in questa pagina web:
http://zsigri.tripod.com/fontboard/cjk/csmore.html
dopo aver detto - appunto - che «each byte is 8-bit long but the first
bit is set to zero, so there are only 7 variable bits», si aggiunge che
«e-mail messages are usually sent in 7-bit encoding because 8-bit or
16-bit encoded characters may not pass correctly through some gateways».
E qui già mi fermo, perché non mi è chiaro come sia possibile che alcuni
gateways non facciano passare i messaggi codificati ad 8 bit, anche
perché purtroppo non so come funziona, nei dettagli, il protocollo delle
e-mail.
Perché se indirizzo a certi gateway un byte che ha il bit più
significativo impostato ad 1 quello non dovrebbe farlo passare? Forse
perché legge solo i 7 bit meno significativi e poi aggiunge
automaticamente uno 0 come bit più significativo? O forse il bit più
significativo viene eliminato fin dall'inizio, quando il file prende la
strada di internet, e poi viene aggiunto alla fine dalla macchina che lo
riceve?
Non solo, ma a questo punto non mi è nemmeno chiaro per quale ragione si
debba specificare se il file che si sta trasmettendo è codificato a 7 o
8 bit.
Infatti se esso deve passare attraverso un gateway che azzera
automaticamente il bit più significativo, a che serve specificare che la
codifica è ad 8 bit, ovvero che il bit più significativo può essere sia
0 che 1? Se esso è destinato ad essere azzerato questa "dichiarazione"
diventa superflua.
Ma non vedo la necessità della "dichiarazione" anche
nel caso in cui il gateway sia in grado di trasmettere tutti gli 8 bit.
In questo caso infatti il file sarà riprodotto tale e quale, bit per
bit, dopodiché il fatto che esso contenga un testo o una immagine o
della musica dovrebbe essere irrilevante per il gateway.
Come vedete mi dibatto in quella matassa di dubbi tipica di chi non ha
capito "le basi". Se ci fosse un'anima buona che ha tempo e voglia di
darmi un paio di dritte (o anche solo qualche link) mi farebbe una
grossa cortesia.
Saluti e grazie per l'attenzione.
D. 

 ASCII.
Nel frattempo ho fatto un po' di prove con il mio OE+FL ed ho fatto una
scoperta che forse potrebbe aiutarmi a capire quel che cercava
pazientemente di spiegarmi quel sant'uomo di Cataldo Vallone un paio di
giorni fa.
Al momento ho settato OE per inviare con il "Latino 9 (ISO)", che
dovrebbe essere il charset ISO-8859-15. Infatti se comincio a scrivere
un messaggio lo salvo in Bozze e vado a vedere gli headers assegnati
automaticamente da OE ci trovo, giustamente,:
     Content-Type: ... charset="iso-8859-15" ...
Quello che ci interessa è però il comportamento dell'header
Content-Transfer-Encoding.
E qui viene il bello. Infatti se sto attento ad usare *solo* caratteri
ASCII quando vado a leggere gli headers trovo:
     Content-Transfer-Encoding: 7bit
Se invece comincio ad usare caratteri la cui posizione nel charset è
oltre l'esadecimale 7F, come ad esempio i caratteri accentati, il
simbolo dell'euro, eccetera, allora negli headers compare:
     Content-Transfer-Encoding: 8bit
Dunque a quanto pare OE di volta in volta stabilisce  da solo qual è
l'_encoding_ che "serve".
Qui però c'è di nuovo qualcosa che non capisco, legato ai dubbi che
avevo espresso nel precedente post.
Infatti, supponiamo che io mi limiti ad usare solo i caratteri ASCII,
sicché negli headers MIME troviamo:
     Content-Type: ... charset="iso-8859-15" ...
     Content-Transfer-Encoding: 7bit
Ebbene, il fatto che i caratteri siano codificati a 7 bit ci assicura
che sono stati usati solo caratteri ASCII, cioè avente esadecimale
inferiore a 7F. A questo punto però che senso ha specificare quale
charset è stato utilizzato? Tutti i charset in uso sono estensioni del
vecchio US-ASCII, sicché la codifica del post è indipendente dal
valore contenuto nel campo charset. Per ogni byte verranno trasmessi
solo i 7 byte meno significativi, il testo verrà trattato come ASCII, e
basta.
Ma il problema vero è un altro.
Prima di aggiungere gli headers MIME ho inviato per anni dei post in
usenet usando l'opzione ""Uuencode" anziché "MIME". Ora, la Webopedia
alla voce "Uuencode" scrive:
«A set of algorithms for converting files into a series of 7-bit ASCII
characters that can be transmitted over the Internet. Originally,
uuencode stood for Unix-to-Unix encode, but it has since become a
universal protocol used to transfer files between different platforms
such as Unix, Windows, and Macintosh. Uuencoding is especially popular
for sending e-mail attachments. Nearly all e-mail applications support
uuencoding for sending attachments and uudecoding for receiving
attachments.»
Leggendo questa definizione si ha l'impressione che chi sceglie
"Uuencode" non possa fare altro che inviare dei post usando solo dei
caratteri ASCII. Invece non era così, perché ho sempre usato tutti i
caratteri accentati ed altre diavolerie senza che nessuno mi abbia mai
detto di aver eavuto difficoltà a leggere i miei post. E io stesso
potevo leggerli tranquillamente una volta arrivati al ng.
D'altra parte, però, se vado a vedere gli headers di quei post non trovo
nessuna indicazione circa l'_encoding_, cioè se sia a 7 o 8 bit. Tutto
ciò che trovo in quelli più recenti è questo:
     X-Rfc2646: Format=Flowed; Original
Mi sono andato a leggere lo standard RFC 2646:
http://www.faqs.org/rfcs/rfc2646.html
ed ho scoperto che il parametro _Format_ impostato uguale a "Flowed"
indica che le linee del post non eccedono gli 80 caratteri, che il
carattere per il quoting è ">" e altre cose del genere. Insomma, si
tratta appunto del formato del testo, non dell'_encoding_.
Quanto a quell'"Orginal" non ce l'ho fatta a capire cosa significa: è
forse quello il parametro che definisce l'_encoding_?
A prescindere da quale sia la risposta a questa domanda, c'è un altro
elemento da considerare. Quel header X-Rfc2646 è comparso solo da
qualche tempo, da quando ho riformattato il disco rigido installando
WindowsXP col SP2 e la versione più recente di OE. Se vado a vedere i
miei post più vecchi non trovo nessuna indicazione che riguardi la
codifica del testo. Se uno si limita a leggere gli headers non sa quale
charset è stato adottato, se si tratti solo ed esclusivamente di testo
ASCII, se sia codificato a 7 o 8 bit, eccetera.
Come fanno, allora, i vari server che devono trasmettersi il post
attraverso i vari gateway, a "sapere" se il testo è a 7 bit o 8 bit? E,
nel secondo caso, come fanno a sapere se il charset è, che so, uno della
famiglia ISO-8859 (e poi, quale?) o un Unicode UTF-8?
-- 
Ciao.
D. 

famiglia ISO-8859 (e poi, quale?) o un Unicode UTF-8?
Se non diversamente specificato attraverso gli header MIME si assume 7 bit.
Poi nella realtà la maggioranza dei server supportano tranquillamente 8 bit.
-- 
-antonio-
www.geminisoft.com
(email valida sul mio sito)

 In effetti è così. UUENCODE non prevede l'indicazione del charset.
Aspe', ché forse comincio a capire.
Prima però ho bisogno di fare il punto su un'altra questione, legata al
fatto che alcuni charset possono essere inviati usando delle "unità di
codice" (_code unit_) che se prese ad una ad una non sono sufficienti a
codificare tutto il charset.
Ad esempio se stiamo usando Unicode e optiamo per un encoding UTF-7
siamo usando delle code units di 7 bit per codificare un charset che
nelle sue ultime versioni è costituito da centinaia di migliaia di
caratteri, tant'è che andrebbe codificato a 32 bit.
Come si compie questo "miracolo"?
Da quello che ho capito la "furbata" consiste nell'usare un numero
*variabile* di code units. Se uno, ad esempio, si limita ad usare i
primi 256 caratteri Unicode, che coincidono con US-ASCII, verrà inviata
una sola code unit di 7 bit. Quando invece si faccia uso di caratteri
aventi una posizione più "alta" si dovranno utilizzare due o più code
units.
Ho detto che è una "furbata" perché i caratteri che si usano più
frequentemente sono quelli sotto l'esadecimale 7F, per cui la stragrande
maggioranza dei caratteri verrà inviata con soli 7 bit. Per gli altri
caratteri dei vari alfabeti nazionali saranno necessari 14 bit, ma
questi saranno una minoranza. Infine qualcuno potrà decidere, che so, di
inserire nel proprio testo qualche geroglifico egizio, ed in tal caso
saranno forse necessarie diverse code units. Ma si tratterà comunque di
casi particolari che in percentuale non peseranno più di tanto sulle
dimensioni complessive del testo.
Ho capito fino a qui?
Sperando di aver capito, provo ad andare avanti.
A questo punto bisogna sottolineare che la codifica dei caratteri
avviene in due "passi":
1) prima bisogna mappare un insieme di caratteri su un insieme di
numeri interi, ottenendo così un _charset_, nel quale ad ogni carattere
viene fatta corrispondere una "posizione" (_code position_);
2) poi bisogna decidere come rappresentare questi numeri interi per
mezzo di sequenze binarie, e questa è la questione dell'_encoding_.
Ovviamente il modo più banale di fare l'encoding è quello di
rappresentare in base 2 il numero associato ad un carattere, e se il
charset è di dimensioni ridotte solitamente si procede in questo modo.
In particolare si usa l'"encoding banale" con l'ASCII, visto che può
essere tutto codificato usando soli 7 bit.
Già però quando si passa ai charset della famiglia ISO-8859-X si può
avere il dubbio se sia il caso di codificarli a 7 bit oppure ad 8 bit,
visto che - come abbiamo detto - la maggior parte dei caratteri che
compaiono in un testo possono essere codificati a 7 bit, e per di più ci
sono dei gateway che fanno passare solo codifiche a 7 bit (anche se
ancora non ho capito come e perché).
Che le due mappature siano in gran parte "indipendenti" ce lo dimostra
il caso estremo dell'Unicode, che ho illustrato poco fa.
Ebbene, se ho capito ciò che cercavi di spiegarmi, lo standard UUENCODE
rigurda *solo* l'*encoding* (cioè la rappresentazione per mezzo di
sequenze binarie dell'intero associato ad un carattere) e *non* fornisce
alcuna informazione circa il *charset*.
Ho capito?
Se ho capito mi resta comunque il dubbio che avevo espresso nel post
precedente: come fanno i server a sapere qual è il charset usato per la
codifica di un certo post?
Se un post usa il protocollo MIME il charset è dichiarato negli header.
Ma cosa accade quando non è dichiarato? Perché alla fine (di solito)
tutto "funziona", anche se si usano caratteri accentati eccetera?
Grazie per l'aiuto!
-- 
Ciao.
D. 

 mezzo di sequenze binarie, e questa è la questione dell'_encoding_.
Accidenti, adesso non sono più sicuro nemmeno di questo.
Ho scoperto infatti che alcuni escono con queste specifiche MIME:
     Content-Type: ... charset=UTF-8
     Content-Transfer-Encoding: 8bit
Ora, l'Unicode assegna una certa "posizione" (= numero intero) univoca
ad ogni carattere esistente, mentre l'UTF-8, da quello che so, è un modo
per rappresentare i numeri unicode con delle sequenze di code units
costituite ognuna da 8 bit.
Se le cose stessero come avevo scritto nel post precedente, dovremmo
dire che la standard *Unicode* definisce il *charset*, mentre il
protocollo *UTF-8* definisce l'*encoding*.
Dovremmo avere, pertanto, qualcosa del genere:
     Content-Type: ... charset=Unicode
     Content-Transfer-Encoding: UTF-8
Ma a quanto pare così non è.
Ma che bisogno c'è di specificare che l'encoding avviene ad 8 bit,
quando già si è dichiarato che il charset è UTF-8?
-- 
Ciao.
D. 

sono sicuro che a voi siano utili dei beta tester così "incasinati" :-)
Grazie dell'offerta :-)
Tra non troppo (entro l'anno si spera) uscirà una prima versione beta di
Pimmy 4. Ma non ritenerti obbligato, ci mancherebbe altro. Rispondo
volentieri se posso e le tue argomentazioni sono interessanti.


 sequenze di ottetti da 7 o 8 bit
ma che senso ha parlare di "ottetti da 7 bit"?
Più in generale, se vengono trasmessi comunque degli ottetti, che senso
ha parlare di codifica a 7 bit? Avrebbe senso se ci permettesse di
"risparmiare" 1 bit ogni 8, ma se invece l'ottetto viene trasmesso tutto
allora viene trasmesso anche il bit più significativo, ed i gateway non
devono fare altro che trasmettere "stupidamente" bit per bit,
"impacchettandoli" in sequenze di ottetti.
Per esempio, se io invio un post con scritto solo «ciao», OE "vede" che
non ci sono caratteri codificati oltre l'esadecimale 7F, "decide" che
bastano 7 bit per codificarli e scrive negli header:
     Content-Transfer-Encoding: 7bit
Però quando è il momento di inviare il post OE non invia soli 7 bit per
ogni carattere, ma invia 4 ottetti nei quali il primo bit è sempre
nullo:
01100011 = "c"
01101001 = "i"
01100001 = "a"
01101111 = "o"
Questi ottetti vengono smistati dai vari gateway, finiscono sul server
delle news e poi vengono scaricati da qualche newsreader.
A questo punto il newsreader ricevente si ritrova con i seguenti 4
ottetti dei quali a priori ignora il "significato":
01100011
01101001
01100001
01101111
Per sapere cosa "significano" il newsreader ha bisogno di specifiche
sulla codifica, e per prima cosa va a leggere il charset negli headers.
Se trova una dichiarazione del charset la usa, altrimenti ne userà uno
di default.
Ora, qualunque sia il charset utilizzato, quei quattro ottetti stanno
sempre per "c"  + "i" + "a" + "o", sicché il fatto di specificare se
l'encoding è avvenuto a 7 bit o 8 bit è irrilevante.
Lo stesso, direi, sarebbe accaduto se uno di quei quattro ottetti avesse
avuto 1 nel bit più significativo. Anche in questo caso il newsreader
avrebbe usato tutto l'ottetto per andare a "cercare" il carattere
corrispondente nel charset dichiarato, indipendentemente dal fatto che
nell'header Content-Transfer-Encoding ci sia scritto "7bit" o "8bit".
Cos'è che mi sfugge?
Grazie tante: sei veramente gentile. Per ricambiare almeno in parte
sarei tentato di offrirmi di fare da "beta tester" per Pimmy, ma non
sono sicuro che a voi siano utili dei beta tester così "incasinati" :-)
-- 
Ciao.
D. 

quando già si è dichiarato che il charset è UTF-8?
Ovviamente utf-8 è solo un nome e non indica precisamente che la codifica
avviene su 8 bit ma in effetti c'è un po' di confusione. Cosa succede ad
esempio se uso utf-8 su 7 bit? Ovviamente non ha senso.
La separazione è giusta perchè uno indica il charset e l'altro come vengono
tramessi i dati. Solo che con utf-7 e utf-8 si sono mischiate un po' le
cose ma credo che sia successso perchè qualcuno ha cercato di creare una
codifica che permettesse di usare UNICODE attraverso sequenze di caratteri
di 8 bit a prescindere dall'uso nelle email per venire incontro alle
applicazioni che hanno da sempre caratteri di 8 bit.


tutto "funziona", anche se si usano caratteri accentati eccetera?
Se non c'è scritto nulla si dovrebbe assumere us-ascii e 7 bit. Ma siccome
la stragrande maggioranza dei server non ha problemi con gli 8 bit e li
lasciano passare capita che se tu spedisci in UUENCODE delle lettere
accentate queste arrivano tranquillamente a destinazione.
Ma il ricevente non sa che charset usare e vede le accentate solo se usa lo
stesso charset che tu hai usato per spedire. Quindi in linea di massima se
scrivi a italiani o europei (ovest) non hai di fatto particolari problemi.


 famiglia ISO-8859 (e poi, quale?) o un Unicode UTF-8?
Molto probabilmente un utente di Helsinky avrebbe visto dei caratteri un
tantino diversi da quelli cui tu avevi pensato, da cui nascono i consigli
per cui sono stati creati i documenti riepilogativi riassunti nelle faq 

mi fa pensare che sia una idea di zio bil
Infatti è giustamente inserito in un header X-...


 Infatti è giustamente inserito in un header X-...
No, gli header di Davide, quelli più recenti, da quando cioè usa il
metodo MIME sono:
| Content-Type: text/plain;
| 	format=flowed;
| 	charset="iso-8859-15";
| 	reply-type=original
| 	reply-type=original
Io la "X-" non ce la vedo
Quello che dici tu (con la x-) era solo quando usava il /non-mime/

| 	reply-type=original
Passo.



di Davide Pioggia del 07 Dec 2004 13:27:01 GMT

di Davide Pioggia del 07 Dec 2004 13:27:01 GMT
Idem.
