> CharSet

Version as of 2003-09-18 22:11:07

Clear message

• FrontPage
• RecentChanges
• FindPage
• HelpContents

• Edit
• View
• Diffs
• Info
• Subscribe
• Raw
• Print

• LikePages
• LocalSiteMap
• SpellCheck

Breve guida all'uso dei caratteri estesi su Usenet

Indice

1. Introduzione
2. Le accentate su Usenet:
3. Il problema particolare dell'header "Subject" ("Oggetto")
4. Il simbolo dell'Euro
5. Istruzioni per configurare correttamente alcuni newsreader
1. Forté (Free) Agent, MacSOUP, tin, Pan, KNode, Mozilla (Netscape 4), Knews, NewsWatcher/Thoth, XanaNews
2. GnusEmacs
3. Outlook Express
4. PINE
5. slrn
6. Xnews
7. Gravity
6. Ringraziamenti
7. Storia delle revisioni

1. Introduzione

Ho avuto il placet di Marvin per mettere qua il suo documento,
nei prossimi giorni lavorerò un po' per sistemarlo, se nel frattempo
avete suggerimenti, consigli etc... beh, questo è il wiki, no?
Tra l'altro necessita un aggiornamento, chiederò su icsn che vengano aggiunte
le cosette che mancano sui vari nr.
--Gesu`

Viene riportato di seguito un interessante articolo sul problema delle accentate su Usenet (e più in generale sull'utilizzo dei caratteri estesi), apparso un po' di tempo fa su it.comp.software.newsreader.
L'averlo reso disponibile su wiki consentirà un aggiornamento continuo che consentano di evitare l'obsolescenza precoce di parte del suo contenuto (specificatamente, la parte dedicata alle impostazioni dei vari newsreader)

Il presente documento è dunque la copia dell'articolo:

 From: Marvin <marvin_gpp*despammed.com>
 Newsgroups: {it.comp.software.newsreader}
 Subject: E allora vuoi usare le accentate nei tuoi articoli?
 Date: Sun, 06 Jan 2002 22:46:52 +0100
 Organization: Sirius Cybernetics Corporation
 Lines: 211
 Message-ID: <a1ak4s.3vue6h7.1@marvin.gpp.despammed.com>

2. Le accentate su Usenet:

E allora vuoi usare le accentate nei tuoi articoli?

Per molti anni, una delle regole d'oro di Usenet in generale, e di it.* in particolare, è stata quella di non usare caratteri accentati, e di sostituirli con apostrofi e apici: tali raccomandazioni compaiono ancora in molte FAQ e manifesti di gruppi. Le ragioni di tale divieto sono legate alle difficoltà con le quali si è arrivati a definire gli standard per la trasmissione dei messaggi (sia di posta elettronica che dei newsgroup), e alla lentezza con cui i produttori di newsreader hanno implementato tali standard.

vero, ma questa lista non è completa. Non dimentichiamo infatti che la ragione storica 
viene dal lato server piuttosto che client. 

Nei primi anni i server news non potevano trattare i caratteri non ASCII, 
un po' come adesso essi non possono ancora digerire il NULL, CR e LF (e pochi altri) 
che devono essere quindi codificati per trasmettere i binari. 

Questa era una seria ragione allora per non usare le accentate, e l'inerzia 
ai cambiamenti dal lato server è anche superiore a quella dei produttori 
di newsreader (per non parlare del fatto che Usenet si interfaccia spesso alle email 
attraverso i gateway raddoppiando di fatto il problema). 

Oggi se non si usa il mime, chi riceve l' articolo e non usa lo stesso charset 
del mittente (a proposito, questo andrebbe detto) vede degli strani caratteri, 
ma nulla si rompe durante l'intera operazione. Una volta non era così e anche se i 
cambiamenti tecnologici ci sono stati, la loro lentezza di adozione ha frenato 
per anni il passaggio verso ''i18n'' (per chi non lo sapesse, tra I e N nella parola
"Internationalization" ci sono 18 lettere, ecco perché si abbrevia così). 

-- CarloFusco

Se vuoi, posso fare un riassunto od una parafrasi di quanto hai scritto tu,
le mie scarse conoscenze non mi permettono di fare di più purtroppo; perciò
scegli tu, se hai poco tempo e preferisci questa soluzione, provo a darmi
da fare io, altrimenti puoi lavorarci tu direttamente.
Quale busta sceglie? :)

-- Gesu`

No, i news server sono 8 bit clean praticamente da sempre. Di solito anche NUL passa,
anche se è meglio non farci affidamento. Non si possono usare CR ed LF per una limitazione
del *protocollo*, non del software. Lo stesso è quasi applicabile anche alla posta.
Il problema sono quindi i client.

-- Md

ho detto una cazzata. In effetti ho trovato dei riferimenti al fatto che gia` Cnews fosse
8bit clean. Ma prima di allora, B news e A news sapevano gia` trasportare caratteri diversi
dall' ASCII? E piu` di 10 fa, sei sicuro che il trasporto via emai non incappasse per
degli "8bit eaters" in frequenza abbstanza rilevante da essere un problema?
-- CarloFusco

Boh. Ma soprattutto, a chi importa? Già è un'impresa trovare un sito che usa Cnews, B è
totalmente scomparso dalla rete ormai da moltissimi anni, e quindi non rilevante.
-- Md

Oggi (a più di trenta anni dallo sbarco sulla Luna) questi problemi sono stati in buona parte risolti, e quindi non c'è più ragione di mantenere un ostracismo completo verso i caratteri accentati. Questo però non significa che l'uso dei medesimi non richieda qualche attenzione supplementare. In sintesi, occorre:

1. Configurare correttamente il proprio programma per le news (newsreader);

2. Ricordarsi di non usare caratteri accentati negli header dei propri articoli, se possibile. In particolare, per la sua importanza, nell'header "Subject" ("oggetto").

Questo è quanto. Se non sei interessato ai dettagli tecnici, puoi anche saltare all'ultima sezione di questo documento, dove sono riportate le istruzioni per configurare correttamente alcuni newsreader. Altrimenti, quella che segue è una breve spiegazione delle regole appena esposte.

Alla base del problema-accenti sta il fatto che originariamente i messaggi Usenet erano codificati unicamente in ASCII standard a 7 bit, che come noto non comprende le vocali accentate. L'adozione di set ASCII estesi (a 8 bit) è successivo, e se da una parte ha permesso l'utilizzo di un vasto numero di caratteri alfabetici localizzati, dall'altra ha creato una notevole fonte potenziale di confusione. Infatti esistono decine di versioni differenti di set ASCII estesi, ognuno creato per scopi particolari (ad esempio, per rappresentare i numerosi segni alfabetici europei, ma non solo).
Fortunatamente, alcuni di questi sono ora degli standard ISO: per le lingue europee, hanno particolare importanza i charset della famiglia iso- 8859, ognuno dei quali è un set ASCII esteso formato da 256 caratteri. Ad esempio: Latin1 (iso-8859-1, Europa occidentale), che contiene i caratteri alfabetici comunemente usati in italiano, francese, tedesco, e altri; Latin2 (iso-8859-2, Europa centrale); Cyrillic (iso-8859-5, Europa dell'est), ecc.¹

Ovviamente è necessario specificare, in ogni articolo, quale charset si è usato per comporre il proprio messaggio. Il rischio è, altrimenti, che A usi un charset per scrivere un messaggio, e che B ne usi uno diverso per leggerlo! Il posto giusto per fornire questa informazione è ovviamente tra gli header², che comprenderanno qualcosa del tipo:

  Content-Type: text/plain; charset=iso-8859-1

O magari:

  Content-Type: text/plain; charset=iso-8859-2

Nel primo caso, se il newsreader incontrerà, ad esempio, il carattere nella posizione 0xE8 (cioè 232), farà apparire una "e" accentata; nel secondo, una specie di "c".
L'unica circostanza in cui l'indicazione del charset può essere omessa è quella in cui il messaggio contenga solo i 128 caratteri dell'ASCII standard a 7 bit (quindi le 26 lettere, i numeri, la punteggiatura, e poco altro). In quel caso, il newsreader assumerà per default che stiamo usando il buon vecchio ASCII standard, senza possibilità di equivoci.

Per l'italiano, è consigliabile usare il ben noto charset Latin1 (iso-8859-1), che comprende tutti i caratteri utili per scrivere in italiano corretto, o il più recente Latin9 (iso-8859-15), che comprende anche il simbolo dell'Euro ({si veda anche il paragrafo dedicato al problema-Euro}).
Altri tipi di charset (in particolare quelli della famiglia Windows, come il windows-1252) sono invece da evitare: non offrono nulla in più rispetto a quelli ISO, e non sono standard (quindi possono non essere supportati dai newsreader).

Questo per quanto riguarda la corretta indicazione del charset. Adesso ogni singolo carattere deve essere codificato (encoding): il metodo raccomandato è l'"8 bit". Ciò significa che, almeno per

Questa frase a mio parere confonde un po'. Intendiamoci, il testo è corretto, 
ma per un non esperto di queste cose per me rimane una frase ambigua. 
Andrebbe chiarita magari con una nota. 

Mi spiego meglio. I "charset" equivalgono già ad una codifica, 
quello di cui parla Marvin qui è l' opportunità di usare una codifica ad 8 bit 
(che appunto equivale al Latin1, Latin9, UTF ecc.) oppure di ridurre le lettere 
"over 128" ad una rappresentazione "under 128" col QP o il base64. Sono entrambi 
delle codifiche, mutualmente esclusive e questo da come viene detto non si capisce 
bene. Sembra che il "charset" sia una cosa e la "codifica" un'altra.
-- CarloFusco

Charset ed encoding sono cose diverse, è importante soprattutto quando si introduce
Unicode (un charset) che può essere codificato in vari modi (UTF-8, UTF-16, eccetera).
Un charset senza encoding è solo un'astrazione (il testo qui sotto va corretto).
Le codifiche come QP sono un ulteriore layer, per esempio è possibile avere un testo
contenente Unicode rappresentato con l'encoding UTF-8 codificato in QP.
Suggerisco la lettura di: http://www.wikipedia.org/wiki/Character_encoding e
http://www.unicode.org/unicode/reports/tr17/ .

-- Md

Scusa Marco, ma se e` vero che un charset di per se` sia una entita` astratta, in genere
si parla di *coded* character set (CCS), riferendosi a cose, come l'ASCII, ISO-8859, 
ISO-10646 (UNICODE), nelle quali ai charset vengono associati dei set di numeri interi che 
arrivano (nel caso dell'UNICODE) ad essere grandi fino a 32 bit.

Poi, quando e` necessario, viene usato il CES (Character Encoding Scheme) per rimappare 
i CSS su gruppi di parole a 8 bit (ottetti), come l'UTF-8 fa per esempio con l' ISO-10646.

Infine esiste la codifica sul trasporto (Transport Encoding Syntax), come il il Base64, che 
rimappa il CSS o il CES per il trasporto su codifica ASCII. 

Insomma, resta il fatto che il termine "codifica" e` troppo generico per essere usato 
disinvoltamente senza le opportune definizioni, che a mio parere queste andrebbero 
fornite al presente documento per *chiarire* meglio il testo, il quale pero` a me sembra 
comunque corretto nella sua presente formulazione.

Non ho capito quindi a cosa ti riferisci quando dici che il testo qui sotto
andrebbe "corretto". Vuoi dire che fornisce delle informazioni errate?

Per quanto riguarda l'uso del termine "mutualmente esclusivo" nella mia nota 
effettivamente occorreva una precisazione visto che cosi` viene fuori una frase 
certamente sbagliata. Io comunque quando ho scritto quella frase stavo pensando al 
fatto che su Usenet nel trasporto di testo (e non di binari) il CES e` una codifica 
sufficiente, essendo Usenet 8 bit clean e quindi sarebbe inutile e ridondante 
stratificarci sopra anche una codifica TES, che quindi non andrebbe usata nel 
trasporto di testo ed eventualmente e` da applicare per il trasporto di binari 
qualora lo si voglia fare nel framework del MIME e non con quegli hack come UUENCODE 
o yenc (ma qui divago e vado fuori tema).


In ogni caso una fonte autorevole da aggiungere secondo me ai tuoi link (e che a me 
personalmente ha aiutato a capire parecchie cose prima confuse) e`la RFC2130.

-- CarloFusco

Voglio dire che dovrebbe essere reso preciso, come hai indicato
-- Md

quanto riguarda il charset iso-8859-1, il carattere "è" sarà rappresentato semplicemente dal byte 0xE8.
Altri tipi di codifica, come ad esempio il Quoted-Printable (in cui i caratteri over-127 vengono rappresentati tramite una sequenza di escape a 7 bit: la "è" del caso precedente sarebbe codificata con i tre caratteri "=E8"), o il Base64, sono invece sconsigliati, perché non forniscono maggiori informazioni di una normale codifica a 8 bit, appesantiscono inutilmente il messaggio, e aumentano il rischio di errori nella decodifica. Un discorso a parte merita l'UTF-8, che è una codifica di Unicode compatibile con ASCII e usata su Usenet. Rispetto ai charset descritti precedentemente, ha il vantaggio di rendere disponibile l'intero set di caratteri Unicode, superando il limite dei 256 caratteri per volta; purtroppo però molti newsreader non lo interpretano ancora correttamente, e quindi si raccomanda di limitarne l'uso ai casi in cui non se ne può fare a meno.

Concludendo, il tipico messaggio news dovrà avere degli header che saranno di solito simili a questi:

   Mime-Version: 1.0
   Content-Type: text/plain; charset=iso-8859-1
   Content-Transfer-Encoding: 8bit

Indicati talvolta semplicemente come "header MIME"³.

3. Il problema particolare dell'header "Subject" ("Oggetto")

Con le adeguate precauzioni, quindi, il messaggio verrà letto e scritto correttamente. C'è però un problema: tutto questo riguarda il corpo (body) del messaggio; che succede quando il carattere accentato è negli header? Un certo numero di newsreader inserisce in essi informazioni supplementari su charset e codifica. Così l'oggetto di un messaggio:

   Subject: Perché non mi funziona il threading?

   Subject: =?iso-8859-1?Q?Perch=E9?= non mi funziona il threading?

L'effetto negativo è duplice: chi usa un newsreader non attrezzato a decodificare il MIME vedrà un subject incomprensibile; inoltre il thread sarà, di fatto, composto da articoli con subject differenti, che dipendono dal newsreader e dal tipo di codifica (con tutte le conseguenze che ciò può avere per la corretta gestione del thread).
Questo è il motivo per cui, fino a che non verranno adottate regole comuni sulla codifica degli header, sarebbe bene scrivere questi ultimi (e quindi anche il subject) usando solo caratteri dell'ASCII standard a 7bit.

4. Il simbolo dell'Euro

Il simbolo dell'Euro è stato recentemente introdotto nel charset Latin9 (iso-8859-15), nella posizione 164. Tuttavia un buon numero di newsreader non è ancora attrezzato per gestire tale charset, e quindi il simbolo verrà a volte mostrato come la posizione 164 del Latin1 (una specie di "o"), o con un punto interrogativo.
Per essere sicuro che chiunque possa leggere correttamente il tuo messaggio, forse è meglio continuare a scrivere "euro", "EUR", o simili. Se proprio ci tieni ad usare il simbolo, devi almeno assicurarti che il tuo newsreader lo codifichi in maniera corretta:

Con Forté Agent in inglese (v1.7 o successiva): "Options | General Preferences | Languages"
Send Usenet As = Western no unicode (US-ASCII, ISO 8859-1, ISO 8859-15)
Default Charset = Latin 9: Western with Euro (ISO 8859-15)

Con Forté Agent in italiano (v.1.93): "Opzioni | Preferenze generali | Lingue dei messaggi"
Invio messaggi Usenet = Occidentale no unicode (US-ASCII, ISO 8859-1, ISO 8859-15)
Predefinito per messaggi ricevuti = Latin 9: Occidentale con Euro (ISO 8859-15)

Con Xnews da solo non è possibile, occorre usare Mime-Proxy (vedi sotto) avendo "caricato" anche il charset "iso-8859-15".

5. Istruzioni per configurare correttamente alcuni newsreader

5.1. Forté (Free) Agent, MacSOUP, tin, Pan, KNode, Mozilla (Netscape 4), Knews, NewsWatcher/Thoth, XanaNews

Questi programmi sono configurati correttamente di default, e non occorre fare nulla.

NB: La versione gratuita di Agent (Forté Free Agent), riesce a gestire correttamente i caratteri estesi solo a partire dalla versione 1.93.

5.2. GnusEmacs

Aggiungere in .emacs la linea:

   (standard-display-european 1).

5.3. Outlook Express

Nel menu:

   Strumenti | opzioni | invio | formato news | imposta testo normale | MIME 

   metodo codifica: nessuno 
   consenti 8 bit: si 

   Strumenti | opzioni | invio | impostazioni internazionali

5.4. PINE

A partire dal menu principale, andare in (S)etup | (C)onfig, e:

- selezionare (X) l'opzione enable-8bit-NNTP-posting - nella casella "character-set", aggiungere (premendo la A), il valore ISO-8859-1.

Forse è più pratico premere W per ricercare l'opzione giusta, data la lunghezza della lista. Uscire premendo E.

5.5. slrn

Non occorre fare nulla, se il sistema operativo è configurato correttamente.
Per generare gli header MIME, aggiungere in ~/.slrnrc:

   set use_mime 1 
   set mime_charset "iso-8859-1".

5.6. Xnews

In:

   Special | Setup Xnews | Compose | Custom Headers

   *Mime-Version: 1.0 
   *Content-Type: text/plain; charset=iso-8859-1 
   *Content-Transfer-Encoding: 8bit 

5.7. Gravity

Gravity non permette l'uso di caratteri accentati (o, in generale, non compresi nell'ASCII 7bit). Chi lo adopera deve continuare ad usare apici e apostrofi, oppure scegliere un newsreader con un miglior supporto per MIME.

6. Ringraziamenti

Ringrazio tutti i partecipanti del gruppo {it.comp.software.newsreader}, senza l'aiuto dei quali non avrei potuto scrivere questo documento.

[6 gennaio 2002, Marvin]

7. Storia delle revisioni

EditText of this page (last edited 2006-12-16 14:53:36 by Sleepers)