Newsgroup: it.comp.software.newsreader
Titolo: scusate ma sono stato fuori citta` e mi sono perso qualche cosa.

    <-- 2 scelta
->NON ABUSARE gli "abuse desk", segnala solo lo spam e il vero netabuse<-      

post ad 8 bit  *senza* gli opportuni  header MIME   
gia` e volevo andarmi a rivedere quali fossero le impostazioni in OE
per farli comparire, ma ancora non l'ho fatto

vedevo. 
Anche tu vedi un sacco di punti interrogativi con Tin?
Se si, non c'è modo di impostare qualcosa per dare di default
l'interpretazione giusta della codifica?
Ciao.
-- 
Antonio  @=D 

 l'interpretazione giusta della codifica?
temo di no, almeno io  non sono riuscito a trovare  un modo. Se non ci
sono  gli header del mime per  tin il post e`  (molto giustamente) a 7
bit e quindi  di fronte agli  ottetti dei caratteri  a 8 bit mostra il
'?' senza neanche tentare di interpretarli.


 vedevo. 
Sono post inviati da OE con la codifica  "Uuendecode".
In tal caso non vengono mostrati gli headers del MIME.
-- 
     *_b_*
   *  _y_  * 
 *   Piero   *

 In tal caso non vengono mostrati gli headers del MIME.
e di  grazia  perche` questa ultima  novita`?   Perche rompere *anche*
questo standard causando un ulteriore disagio a tutti gli utenti degli
altri newsreader che invece si basano  sul mime (concetto che ormai e`
standard da  una decina  di anni   a questa parte)  per  decidere come
interpretare il testo? Scusa, ovviamente non sei tu il responsabile di
questo modo irresponsabile di rilasciare  i prodotti che poi vanno  ad
impattare il resto del mondo, e  non e` con te che  me la prendo, anzi
ti  ringrazio   per la  risposta,  e se    comunque  hai  una  qualche
informazione in piu` mi piacerebbe conoscerla.


 cos'e` "Uuendecode"?
man uuencode
 
Ciao.
-- 
BSD is for UNIX-lovers -- linux is for Windows-haters.

'?' senza neanche tentare di interpretarli.
Molto giustamente in un mondo perfetto, consderando che questo non lo
è (non solo per colpa di OE ma anche di gravity, FA, XNews e
probabilmente molti altri) sarebbe intelligente poter decidere un
chrset di default. Molto probabilmente un newsreader come Tin permette
di farlo, io non lo conosco assolutamemente ma con Google e con "mi
sento fortunato" ho trovato la pagina 
http://www.tin.org/tinrc.html
,
non so se questo è quello che carcavate ma sembra promettente:
|mm_charset
|charset supported locally which is also used for MIME header and 
|Content-Type header unless news and mail need to be encoded in other 
|charsets as in ISO-2022-KR encoding of EUC-KR in mail message. If not 
|set, the value of the environment variable MM_CHARSET is used. Set to 
|US-ASCII or compile time default if neither of them is defined. If 
|MIME_STRICT_CHARSET is defined at compile-time, charset other than 
|mm_charset is considered not displayable and represented as '?'.
Personalmente trovo molto fastidioso leggere messaggi pieni di '?'
anche se la colpa non è vostra ma di chia ha mandato il messaggio
originale.
-- 
Marco Barisione (ICQ 84277092)

 informazione in piu` mi piacerebbe conoscerla.
Dall'help di OE:
Specifica che in  Outlook Express verranno codificati utilizzando
Uuencode,  un formato  che viene  utilizzato per  l'invio di file
binari   come  allegati   ai  messaggi   inviati   ai  newsgroup.
Come vedi c'e' chi ha bisogno di questo formato per frequentare i
NG binari, perche' sembra che utilizzando il MIME ci siano NR che
non riescono ad interpretare gli allegati.
I caratteri  estesi dovrebbero  essere eliminati,  causano sempre
casini, ma e' fiato sprecato purtroppo, questi non ci sentono :-(


 altri newsreader 
E' esattamente quello che vogliono. E' per questo che vanno boicottati.
-- 
Luca - e-mail: p.stevens at 
libero.it

 originale.
Hai ragione, sono *molto* fastidiosi, e non c'e` nessun motivo per non
adeguarsi ad uno standard cosi` antico e cosi` largamente diffuso. Qui
parliamo di mondi imperfetti che qualche progresso pero` l'hanno fatto
nei  decenni  e che  l'unica  cosa che  si  chiede  e di  non  tornare
indietro.
+++
Quello  che non capisco e` perche`  vedo cosi` tanti  articoli a 8 bit
senza gli   header mime in  outlook, ovvero  e`  cambiato qualche cosa
oppure questa  feature c'e` sempre   stata e io non    me ne sono  mai
accorto prima.  Questa e`   la mia domanda  originale  a cui non  sono
ancora riuscito a dare una risposta.


    <-- 2 scelta


 a 7 bit).                     ^^^^^^^^^^^^^^^ 
diciamo che compare piu` raramente, dimenticavo appunto le citazioni.

 difficile al prossimo solo per una adozione "broken" dello standard.
Cito tutto e condivido completamente, anche perche' personalmente non
ho problemi di visualizzazione o di reply, pero' torno a ripetere che
se non  si utilizzassero i caratteri estesi sui  NG si eliminerebbero
anche tanti casini.


 ancora riuscito a dare una risposta.
AFAIK, Outlook non ha mai messo (per default) gli header MIME, quindi la 
situazione su quel fronte non č cambiata. Probabilmente il peggioramento 
che vedi dipende dal fatto che sempre piů persone usano le accentate nei 
ng. Il successo di Xnews (che gestisce i charset molto peggio di OE) non 
ha certo migliorato la situazione.
Bisogna anche aggiungere che la maggior parte degli utenti non considera 
tutto ciň come un problema, dato che (quasi) ogni newsreader per Windows 
assume, in mancanza di ulteriori informazioni, il cp1252 o il Latin1.
-- 
Ciao, Filo

 con i problemi gia' rilevati.
ah, ecco, non ti avevo capito. Comunque  questo non e` il caso perche`
con uuencode  si  usano tutti caratteri  a  7 bit  e quindi  vedrei la
codifica, non i '?' al posto delle accentate.
Credo che abbia ragione Marvin, questa non e`  una novita` e prima per
qualche motivo non ci ho mai fatto troppo caso.   Che due balle pero`,
ma possibile  che costi tanto adottare l'algoritmo  "se  usi gli 8 bit
metti  il mime, altrimenti fanne a  meno"?  Perche` questa deve essere
un'opzione da abilitare espressamente  e non un  meccanismo automatico
che si attiva a seconda di cosa posta l'utente?


 che si attiva a seconda di cosa posta l'utente?
Immagino che la risposta sia "non si puo'", ma lo chiedo lo stesso.
Perche' non si filtrano sui server certe cose?
R:, MIME farlocchi, HTML, quoting alla rovescia... magari alla lunga lo
capiscono.
-- 
Fact of life #15: Heads bleed, walls don't.

 ng. Il successo di Xnews (che gestisce i charset molto peggio di OE) non 
Ok, mistero risolto. Aveva ragione marco (Barisione), il problema e`
nato da un aggiornamento di tin che era stato compilato da Marco
(d'itri, l'attuale manutentore debian di tin) coll'opzione 
--disable-mime-strict-charset
commentata, quindi di default  viene abilitato il MIME_STRICT,  cha ha
il    risultato di  mostrare  i    punti  interrogativi  se il charset
dell'articolo non e` lo stesso di  quello locale. Questo credo ha come
conseguenza che un articolo senza il mime venga di default considerato
diverso dal charset locale, o qualche cosa del genere.
Ho ricompilato il  pacchetto disabilitando  il MIME_STRICT, e   adesso
finalmente rivedo tutti gli accenti.
E` stata pero`  un'esperienza  estremamente frustrante   vedere quanti
articoli su usenet non sono formattati in accordo col mime.


anche tanti casini.
Per l'italiano è ancora abbastanza facile ma molte altre lingue (anche
europee) usano caratteri ancora "più strani" delle accentate, non mi
sembra poi così difficile fare in modo che un newsreader gestisca
correttamente i caratteri estesi, o almeno potrebbe offrire degli
strumenti per convertire i caratteri accentati in caratteri normali
più "`" o "'", cioè se scrivo "à" lui dovrebbe trasformarla in "a`",
"é" in "e'" e così via.


diverso dal charset locale, o qualche cosa del genere.
E fare in modo che non mostri i punti interrogativi di default? So che
non è la scelta più corretta ma in fondo è quella migliore
considerando che pochi nr mettono gli header mime.


quoting alla rovescia...
Questo mi sembra impossibile, un programma non può essere in grado di
distinguere un buon quoting.


 considerando che pochi nr mettono gli header mime.
marco (d'itri) avra` sicuramente avuto  i  suoi buoni motivi per  fare
una scelta del genere.
-- 
ciao | Antispam in pillole: (LART 2 )  Segnalare  correttamente lo  spam;
cf   | Nel subject  vanno delle parole chiave, nella prima riga [web site
-----+ spam advertised][spam from your net][open relay, proxy, formmail],
[DNS support to spammer], e di seguito lo spam completo, incluso l'header 

 codifica, non i '?' al posto delle accentate.
Scusa,  ma ora sono io  che non capisco;  perche' questo non e' il caso?
Intendi che  con la codifica  uuencode non si  *possono*  usare ottetti?
Perche' e' gia' stato dimostrato il contrario; al loro posto vedevi '?'.
Oppure intendi  che con uuencode si  *devono*  usare caratteri  a 7 bit?
Ma in tal caso anche senza gli header del mime non ci sarebbero problemi
O forse  vuoi dire che  i caratteri a 7 bit,  se usati  *correttamente*,
sarebbero ovviamente letti dal tuo NR con la codifica  charset=us-ascii?
Come vedi non ho capito.   Mi piacerebbe che  spiegassi la frase citata.


 Content-Type: text/plain; charset=UTF-8
In mezzo a tutti questi bei discorsi?
-- 
     __         ____           | Eì 'Aanììgòò 'Ahoot'é
 __ / /__  ___ / __/__ __ __   |
/ // / _ \/ -_) _// _ \\ \ /   |
\___/\___/\__/_/  \___/_\_\    | ICQ UIN: 61571298

 Come vedi non ho capito.   Mi piacerebbe che  spiegassi la frase citata.
se fosse uuencode sarebbero *solo*  caratteri a sette bit. I caratteri
a sette bit sarebbero pertanto  visti tal quale senza problemi, ovvero
non vedrei i punti interrogativi, che invece sostituiscono i caratteri
a otto bit non visualizzabili per incompatibilta` col set di caratteri
(qualsiasi sia la ragione di tale incompatibilita`).
-- 
ciao | Antispam in pillole: (LART 1)  Luser  Attitude Readjustment Tool;
cf   | La  segnalazione  al  provider  dello  spammer, l'unico mezzo che 
-----+ abbiamo a disposizione per combattere attivamente lo spammer. Nel 
numero l'efficacia del  LART  e`  devastante, fai anche tu la tua parte!

 In mezzo a tutti questi bei discorsi?
perche`,  che c'e` che non   va con l'UTF-8   ?  E` il  modo giusto di
risolvere il problema dei  caratteri ad otto  bit, non per nienete  e`
stato scelto della Usefor anche per gli header.
-- 


 stato scelto della Usefor anche per gli header.
Il problema e' sempre quello... molti non riescono a leggere l'UTF-8 ...


 Il problema e' sempre quello... molti non riescono a leggere l'UTF-8 ...
Fino a   due giorni fa` avevo l'ISO-8859-1.    Poi dato che  il casino
successo mi  ha costretto a metter mano  alla configurazione di tin ho
provato a sperimentare la cosa.  Adesso comunque lo rimetto come stava
prima.
Che palle pero`,  io devo rinunciare  ad uno standard acquisito la cui
diffusione non puo` far altro che  portare benefici a Usenet, e questo
per non danneggiare  chi non e` al passo  coi tempi,  mentre un numero
impressionante di   newsreader,  e in   certi  casi di utenti,   se ne
strafrega di un numero di situazioni  analoghe dove pero` si parte dal
*non* rispetto degli standard per proseguire verso il *danneggiamento*
di Usenet.


 di Usenet.
Considera che il vero unico standard che dovrebbe esistere sulla rete e' 
la retrocompatibilita'... non sarebbe giusto costringere un utente a non 
poter usufruire piu' di determinati servizi di cui ha sempre usufruito 
solo perche'  a qualcuno non piace fare le lettere accentate come una 
lettera seguita dall'apostrofo... come si e' sempre fatto. Se mi trovi una 
qualsiasi codifica che sia retro compatibile, ma che al contempo non 
appensantisca i messaggi...
In fondo, se ci pensi bene, l'html risolve in ugual modo il problema... 
con uno standard probabilmente ancor piu' acquisito....


 ancor piu' acquisito....
L'html non va bene solo perché aumenta notevolmente (ed
inutilmente) le dimensioni dei messaggi da spedire. Altrimenti
potrebbe essere una buona alternativa.


Scusa,  ma ora sono io  che non capisco;  perche' questo non e' il caso?
Un  articolo,  dopo  esser  stato  codificato  con  uuencode, non può
contenere caratteri a 8 bit: viene  infatti  completamente  rimappato
su  caratteri  a  6 bit, cioè ogni gruppetto di 3 byte (24 bit) viene
rappresentato con 4 caratteri appartenenti ad un set  predefinito  di
64  caratteri  (cosa  che  avviene  anche col base64, la fondamentale
differenza è il set di caratteri di arrivo). Ad  ognuno  dei  quattro
caratteri  corrisponderà  quindi  un  numero  (da 0 a 63), in fase di
decodifica.
Ovviamente ognuno dei 4  caratteri  è  comunque  fatto  di  8bit  (il
primo,   ovvero   l'High  Order  bit,  è  sempre  0,  per  assicurare
trasmissibilità anche in caso di server "a 7 bit"), di qui  l'aumento
dimensionale che la codifica comporta.
Se    t'interessa    approfondire:    
http://internetu.org/uuenc.html
In sintesi: se pigli un file di testo,  e  lo  uuencodi,  non  è  più
leggibile. Altro che punti di domanda sparsi qua e là.
-- 
Informazioni su it.*: 
www.news.nic.it/news-it/
Archivio news: 
http://groups.google.com/advanced_group_search?hl=it
Un motore di ricerca: 
www.alltheweb.com/advanced
Computazione diffusa: 
www.aspenleaf.com/distributed/

 con uno standard probabilmente ancor piu' acquisito....
no, non risolve affatto il  problema, l'html non  e` mai stato pensato
come soluzione al problema della comunicazione uno a uno o uno a molti
in un contesto  universale  multilingua, altrimenti non sarebbe  stato
necessario  tirare fuori il mime.  L'html  e` tutt'altra cosa rispetto
alla  posta elettronica e a  Usenet e risponde ad esigenze altrettanto
diverse, ma  nelle diversita`  delle  soluzioni che offre ad  un certo
punto   ha  dovuto affrontare  e risolvere    parallelamente la stessa
questione per conto  suo,  giungendo BTW  alla stessa soluzione,  MIME
(sort of) e unicode (UTF-8).
E anche ammesso che l'html portasse la soluzione con  se, cosa ceh non
e`, l'algoritmo di propagazione    degli  articoli su usenet  non   si
accorda certo con la struttura  ipertrofica  dll'uso massiccio di  tag
delle soluzioni XML,  che inevitabilmente  introducono un problema  di
efficienza.
La soluzione giusta  e`  molto piu` semplice  ed e`  a disposizione da
parecchi  anni, l'adozione da   parte   dei  newsreader del mime    e,
nell'ambito   del mime,  dell'unicode.   Alternativamente si  potrebbe
costringere  i  costruttori di    hardware a  produrre solo   tastiere
americane e costringere  tutto il mondo,  incluso  l'oriente, ad usare
l'inglese. Forse e` piu`  semplice che convincere alcuni programmatori
di newsreader a leggersi  quelle 7-8 rfc prima  di scrivere del crappy
code che poi va in giro a far danni.


 (qualsiasi sia la ragione di tale incompatibilita`).
OK ora ho capito cosa intendevi, ma dovro' ringraziare anche Ghost.  :-)


 contenere caratteri a 8 bit: viene  infatti  completamente  rimappato
Ti ringrazio  molto dell'esauriente  spiegazione e  del link segnalato.
Mi è sempre piaciuto apprendere,  quindi cercherò di approfondire.  :-)





Ghost ha una cultura tecnica  e una capacita` di sintesi assolutamente
fuori dal comune. E` da tempo che l'ho messo nel mio watch file.


 con uno standard probabilmente ancor piu' acquisito....
Mappernientaffatto. Vade retro.
-- 
Luca - e-mail: p.stevens at 
libero.it

 Mappernientaffatto. Vade retro.
Non dico di usarlo, per carita'. Ma tutti abbiamo un decoder di html nel 
pc, o no?


man uuencode
Fidati, _sa_ cose'è l'uuencode....
..e probabilmente "man" è un comando che non ha più bisogno di usare da
parecchio.  :-)
Ciao.
-- 
Antonio

'?' senza neanche tentare di interpretarli.
Ma noi che siamo più f{urb,oll}i non possiamo fare qualcosa, non sarebbe
possibile fare uno script che prende i nuovi messaggi in /var/spool... e
se trova le righe 
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
aggiunge le righe
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
e soprattutto, sarebbe sufficiente?
N.B. Potrei aver detto anche una grossa fesseria, non mi sono messo a
controllare come effettivamente stanno i messaggi nello spool di
Leafnode.
Ciao.
-- 
Antonio

 potrebbe essere una buona alternativa.
Controlla un codice html, elimini tutto quello che non ti serve
(formattazione del testo) e tieni solo la codifica dei caratteri. Che
cosa ti rimane? Una codifica... semplice e che non porta via molto
spazio in piu' di un messaggio codificato in iso. 
In definitiva... perche' essere razzisti (come hai definito tu) verso
chi non vuole o non puo' supportare l'UTF-8 ? 


 appesantisce proprio nulla, almeno nei limiti dell'universo reale.
Non e' retrocompatibile. Tant'e' che io me ne sono accorto dalla 
assurdita' dei caratteri inseriti nel messaggio /incriminato/ ...
-- 
     __         ____         | We don't need no education.
 __ / /__  ___ / __/__ __ __ | We don't need no thought control.
/ // / _ \/ -_) _// _ \\ \ / | All we need is another brick in the wall


 tu) verso chi non vuole o non puo' supportare l'UTF-8 ?
Ho mai parlato di UTF-8 io?


 leggibile. Altro che punti di domanda sparsi qua e là.
E la presunta retrocompatibilita' ? :-PPP
-- 
     __         ____           | Eì 'Aanììgòò 'Ahoot'é
 __ / /__  ___ / __/__ __ __   |
/ // / _ \/ -_) _// _ \\ \ /   |


 assurdita' dei caratteri inseriti nel messaggio /incriminato/ ...
No, e` *totalmente* retrocompatibile  con l'ascii, certo, non  con gli
ISO-8859-X,   ma  in  questo  caso  il  processo    di conversione  e`
assolutamente banale da realizzare, e  comunque il trade off e` quello
di permettere l'utilizzo di qualsiasi lettera di qualsiasi alfabeto in
un sistema coerente e  universale senza rompere la  compatibilita` con
l'ascii, cosa  che  garantisce una transizione   accettabile (e questo
vale tanto per le news quanto per il web). Per maggiori informazioni:
http://www.cl.cam.ac.uk/~mgk25/unicode.html
-- 
ciao | Antispam in pillole: (LART 2 )  Segnalare  correttamente lo  spam;
cf   | Nel subject indicare delle parole chiave, nel corpo una tag come: 
-----+ "web spam advertised""spam from your net""open relay""open proxy" 
"open formmail""DNS support", e di seguito lo spam completo di header .

 stato scelto della Usefor anche per gli header.
Non so, io la tua parte dell'articolo la leggevo bene, ma le accentate
nel quote erano tutte sballate. Avrei una curiosita': l'articolo a cui
rispondevi (quello di Marco) era in latin1 e tu hai risposto in UTF-8.
Le accentate sono state ricodificate o hanno mantenuto i codici
originali? Non riesco a capire se sono in grado o meno di leggere
l'UTF-8.
-- 
Fact of life #15: Heads bleed, walls don't.

 distinguere un buon quoting.
Come no? se trovi 5 righe che iniziano con caratteri alfanumerici e 70
in coda che iniziano con ">" mi pare evidente che e' cattivo quoting ed
e' un criterio abbastanza oggettivo.
Certo per quegli autlucchi che mettono il segno di quote anche davanti
a quello che scrivono loro e per quelli che non lo mettono e basta non
puoi fare molto, ma quello alla rovescia lo becchi facilmente.


 l'UTF-8.
Sono state ricodificate.
-- 
ciao | Antispam in pillole: (WHOIS) Indica a  quale  provider  appartiene
cf   | l'IP dal quale e` partito lo spam, e quindi  a  chi  rivolgere  il 
-----+ LART. Per chi sa come ricompilare questo e` il miglior  WHOIS  per 
Linux e Win: '
http://www.linux.it/~md/software/whois_4.5.25.tar.gz
'

 l'UTF-8.
MT-NewsWatcher ha l'UTF-8, cosi`  come anche thoth, l'erede  di YA-NW,
scritto dallo stesso autore.
-- 


 scritto dallo stesso autore.
Si, MT-NW lo conosco, lo uso su altri NG. Conosco anche Thoth, ma ho
una qualche ragione per non usarlo.
Effettivamente leggendo bene i caratteri "strani" in UTF-8 sono sempre
doppi, anche se a una prima occhiata mi sembravano singoli.
Ancora una cosa: non si era detto tempo fa' di usare Latin1 (o Latin9)?
Mi riferisco ai thread "e allora vuoi usare le accentate?" o qualcosa
di simile. Non capisco il vantaggio di usare UTF-8 al posto di Latin1.


 di simile. Non capisco il vantaggio di usare UTF-8 al posto di Latin1.
Supponi, ad esempio, di voler scrivere un articolo in italiano corretto e 
con alcune citazioni in greco. Ti accorgi subito che non puoi usare né il 
charset Latin1 (iso-8859-1), poiché non ha le lettere greche, né il Greek 
(iso-8859-7), che non ha le nostre vocali accentate. Ciò perché ognuno di 
questi charset contiene solo pochi caratteri (meno di 256), specifici per 
una ben determinata famiglia di lingue. Invece, Unicode comprende tutti i 
segni alfabetici di ogni lingua, e quindi un messaggio con charset=UTF-8, 
da questo punto di vista, non soffre di alcuna limitazione.
Rimane comunque il fatto che, imho, usare UTF-8 per scrivere in italiano,
è come ammazzare le mosche col fucile. Agent, per esempio, si comporta in 
modo egregio: usa Unicode solo quando non riesce a codificare in Latin1 o 
Latin9.
-- 
Ciao, Filo

 di simile. Non capisco il vantaggio di usare UTF-8 al posto di Latin1.
Infatti  *attualmente*  e` preferibile  il Latin1,  ma  l'UTF-8  e` il
futuro prossimo di usenet e del web.   Ha una serie di caratteristiche
tecniche per cui pur mantenendo la compatibilita` con l'ascii permette
facilmente e compatibilmente col passato, nei limiti del possibile, la
codifica  di tutti  i caratteri dell'Unicode.  Di  fatto con  UTF-8 si
potra` scrivere  in qualsiasi lingua. E` chiaro  che  il supporto alle
varie  lingue sara` aggiunto   un po' per  volta,  ma ad ogni passo in
avanti comunque verra`  mantenuta la compatibilita`  con le precedenti
codifiche gia` acquisite.
Inoltre i caratteri nell'header sono stati standardizzati dalla USEFOR
proprio con  l'UTF-8.  Per ora e`  meglio non usare ancora gli accenti
nel subject, ma con l'approvazione del  nuovo standard per Usenet (del
quale finalmente si  incomincia a vedere la luce  alla fine del tunnel
(*) ), l'adozione dello standard da parte delle softwre house dovrebbe
finalmente   raggiungere  la massa  critica    (se outlook  e  le  sue
"innovazioni" ovviamente lo permetteranno).
(*) presto verra` pubblicato l'ultimo draft  uffciale, per poi passare
    al "last call" prima di sottoporre *finalmente* il lavoro di quasi
    6 anni all'aprovazione dell'IETF


 leggono. 
[cut]
XOVER non c'entra, il MIME  e` solo per  il corpo del testo, cioe` che
scarichi o  meno  gli header del MIME  agli  altri header   non cambia
proprio nulla.
C'erano fondamentalmente due  soluzioni al problema: una infrastuttura
MIME  in  linea, che alla   fine e`  stata  scartata, oppure  mettersi
daccordo su   che codifica usare. Si  e`  scelta questa ultima strada:
cioe` negli header si usa l'UTF-8, punto.
E  cosi` quando ci sara`  una  massa critica  sufficiente a supportare
l'UTF-8  ci saremo  liberati   dalla schiavitu`  dei segni  alfabetici
castrati. Fino ad allora e` meglio limitare l'header all'ascii 7 bit.
-- 


 "innovazioni" ovviamente lo permetteranno).
Proposta scherzosa ma non troppo. E tutti gli altri iniziassero a 
fregarsene di Outlook esattamente come Outlook se ne strafrega degli 
altri?
-- 
     __         ____           | We don't need no education.
 __ / /__  ___ / __/__ __ __   | We don't need no thought control.
/ // / _ \/ -_) _// _ \\ \ /   | All we need is another brick in the wall


 Ho mai parlato di UTF-8 io?
Intendevi allora l'uuencode?
-- 
     __         ____           | We don't need no education.
 __ / /__  ___ / __/__ __ __   | We don't need no thought control.
/ // / _ \/ -_) _// _ \\ \ /   | All we need is another brick in the wall


 Fino ad allora e` meglio limitare l'header all'ascii 7 bit.
Appunto.
-- 
     __         ____           | We don't need no education.
 __ / /__  ___ / __/__ __ __   | We don't need no thought control.
/ // / _ \/ -_) _// _ \\ \ /   | All we need is another brick in the wall


xxx xxxx xxxx xxx xxx xxx xxx xxx
Ciao
 -- 
Topolino
--------------------------------------------------------
Il messaggio di esempio che ti ho scritto mi sembra perfettamente
conforme alla netiquette, eppure ci sono numerose righe di apparente
quoting alla fine. Un programma non sarebbe in grado di capirlo e
quindi non sarebbe giusto censurarlo.
Un problema analogo si può avere anche con il "R: " infatti "R: " in
alcuni contesti potrebbe anche aver senso. Il problema sarebbe cmq
molto limitato, soprattutto se si controllassero il newsreader usato e
il campo "References".
-- 
Marco Barisione (ICQ 84277092)

Ghost[...]
Ti  ringrazio, davvero mi confondi.
O, più semplicemente, c'è in giro un mio omonimo in gamba. ;)
Diciamo che a volte riesco a trovare un po' di tempo  per  soddisfare
qualche mia curiosità, e sfoglio qualche carta...
Nulla  a  che vedere (purtroppo) con chi le cose importanti le sa sul
serio: senza tanti misteri, per esempio tu.
Perciò  colgo  l'occasione  per  ripetere  pubblicamente  la   solita
avvertenza:  tutto  quello  che  scrivo  va  preso  con  un  generoso
beneficio d'inventario. 
f/up a me.
-- 
Informazioni su it.*: 
www.news.nic.it/news-it/
Archivio news: 
http://groups.google.com/advanced_group_search?hl=it
Un motore di ricerca: 
www.alltheweb.com/advanced
Computazione diffusa: 
www.aspenleaf.com/distributed/

Non capisco il vantaggio di usare UTF-8 al posto di Latin1.
UTF-8  è un set di caratteri molto ampio. A parte questo vantaggio di
completezza, che a volte può non essere importante, dobbiamo  pensare
soprattutto  al  caso  degli header: visto che fra gli header inviati
dai newsserver in risposta al comando XOVER non compare  Content-Type
(e  quindi  non  posso  avvisare  gli  altri del set di caratteri che
intendo usare nei miei header),  la  conseguenza  è  che,  per  esser
certi   che   gli  header  vengano  letti  correttamente  (e  qui  la
correttezza è funzionale al protocollo, non solo  fine  a  sé  stessa
come  nel  corpo  degli  articoli di testo) bisogna che *tutti* usino
negli header il medesimo set di caratteri.
Una  scelta  accettabile  può   essere   usare   il   massimo   comun
denominatore  di (quasi) tutti i set, ed è proprio ciò che si è fatto
coll'us-ascii. Ma, storicamente, si è  usato  l'us-ascii  perché  era
quello  che  serviva  agli  USA:  i  pochi altri, qualora ne avessero
davvero  bisogno,  dovevano  dunque  codificare  i  caratteri  estesi
dichiarando  al  volo,  nell'header  stesso, tipo di codifica (per le
lingue occidentali "Q", sostanzialmente quoted printable)  e  set  di
caratteri usato: cose del tipo
=?ISO-8859-1?Q?Accento_l=EC,_accento_l=E0:_del_subject_che_ne_sar=E0=3F?=
Ma  ecco  che  sorgono  i  problemi:  NR  che non decodificano questi
header, magari  perché  incapaci,  magari  perché  non  conoscono  lo
specifico set di caratteri usato...
Che fare, quindi?
Un'altra  scelta,  certamente  migliore - a patto che diventi un vero
*standard* - è accordarsi su di un  qualsiasi  set  di  caratteri  (a
questo  punto  meglio scegliere il più ampio, perché possa soddisfare
tutte le esigenze), e  rendere  tutto  il  software  compatibile  con
quell'unico  set  di caratteri[*] (invece che con tutti i possibili).
Quel set è l'UTF-8.
[*] In realtà andranno bene anche solo "compatibilità parziali".
Due  parole  sull'UTF-8,  che  è  un   set   di   caratteri   (basato
sull'UCS)   codificato   (contando   più  di  256  caratteri,  ciò  è
inevitabile).  Ha  il  vantaggio  di  essere   retrocompatibile   col
precedente  standard  us-ascii  (ogni  carattere dell'us-ascii rimane
tal quale in UTF-8),  ma  non  è  retrocompatibile  cogli  altri  set
estesi.  Rispetto  all'uso  di  un  normale  set  esteso, UTF-8 ha lo
svantaggio che, dovendo poter rappresentare molti più caratteri,  usa
più   d'un   ottetto   per   ogni   carattere   UCS_non_us-ascii   (e
l'articolo aumenta di dimensioni). Ecco perché, se la superiorità  di
tale  soluzione  è  palese  per i brevi header[**], usare il content-
type ed un set esteso "normale" sarà ancora utile  per  il  corpo  (e
penso  soprattutto  alle connessioni dialup 56K cui, in Italia, siamo
così... forzatamente affezionati).
[**] Alcune cose resteranno comunque in  us-ascii  puro  (nomi  degli
header, msg-id...).


E la presunta retrocompatibilita' ? :-PPP
Occhio  a non confondere uuencode con unicode, UCS, UTF-8 e compagnia
bella.


chi non vuole o non puo' supportare l'UTF-8 ? 
Ehm... chi non vuole, pianga sé stesso. No?  :-)
E chi è che non potrebbe, se volesse?


 Intendevi allora l'uuencode?
Io ho solo detto che è necessario che gli standard si adeguino
al fatto che esistono altre lingue oltre all'inglese. Poi,
quale sarà la soluzione non mi interessa, basta che la si
trovi.


 bella.
Infatti... non per nulla avevo messo le pernacchietta.
-- 
     __         ____         | We don't need no education.
 __ / /__  ___ / __/__ __ __ | We don't need no thought control.
/ // / _ \/ -_) _// _ \\ \ / | All we need is another brick in the wall


 alcuni contesti potrebbe anche aver senso.
Secondo me no. Spiegami quando il /subject/ di un messaggio avrebbe
senso che iniziasse per 
   R: subject_originale
anziche con
   Re: subject_originale


 trovi.
Questo e' vero... ma senza neanche stravolgere la compatibilita'. Per 
curiosita' oggi ho fatto un paio di telefonate a clienti non italiani. 
Risultato... il giapponese, il cinese, il coreano, l'indiano, l'arabo, se 
scritti in caratteri /latini/ usano il set di caratteri che noi definiamo 
/non estesi/. So che non e' una soluzione, ma non bisogna negare che, 
visto che devono comunque imparare due alfabeti differenti, hanno scelto 
il male minore. Un peccato la perdita di una cultura /alfabetica/ cosi' 
vasta, ma qualcuno deve pur sostenere qualche disagio. In fondo, noi 
italiani, siamo ancora tra i piu' fortunati. Pensare ad esempio ai 
francesi che di accenti ne hanno un sacco anche in messo alle parole... 
usando un carattere /a parte/ per l'accento, le parole diventano di piu' 
difficile lettura.



Bah!
Ciao.
-- 
Antonio

 pc, o no?
Mmh ... veramente ce ne abbiamo almeno tre diversi: IE, Netscape, e
quelli W3C compatibili.
-- 
Luca - e-mail: p.stevens at 
libero.it

 quelli W3C compatibili.
Uhm... io nel mio PC ad esempio quello di Netscape non ce l'ho.
Cmq... forse intendevi di tre tipi di html differenti? Non sono d'accordo. 
Explorer e' un decoder di "html+altra roba". Stesso discorso per Nescape, 
credo. QUello che importa, secondo me' e' la codifica dei caratteri. Ad 
ogni carattere viene dato un nome, e solo per quel carattere viene 
definito un tag. Il resto del codice html, nel nostro caso sarebbe 
perfettamente inutile e controproducente.


 l'articolo aumenta di dimensioni). Ecco perché, se la superiorità  di
vero, pero` per il  Latin sono tutti caratteri  a due ottetti, che non
e` certo un gran aumento. E poi quante  sono le vocali accentate in un
articolo in italiano, piu` o meno del 10 % ? Per me sono meno, e anche
se queste raddoppieranno, di quanto vuoi che aumenti l'articolo?


   Re: subject_originale
Non con "R: subject_originale" ma come "R: " parte proprio del
subject, cioè non come prefisso di risposta. È per questo che secondo
me è un caso più unico che raro.


 In fondo, noi italiani, siamo ancora tra i piu' fortunati.
Non lo metto in dubbio, ma ti assicuro che può essere molto
problematico anche per noi.


e` certo un gran aumento.
Effettivamente... :-)


 perfettamente inutile e controproducente.
E che cosa impedirebbe a chi spedisce di includere ugualmente altro
codice a parte la codifica dei caratteri, rendendo l'email per
nient'affatto standard, visto che proprio l'html è un campo di
battaglia?


 battaglia?
E che cosa impedisce a chi spedisce, ora, di includere ugualmente, altro 
codice UTF-8, Unicode, o quel cavolo che vuoi, a parte la codifica dei 
caratteri, rendendo l'email per niente affatto standard?
Sei arrivato al punto dove volevo. Si tratta non tanto di trovare una 
codifica che vada bene per quasi tutti e che non faccia troppo male agli 
altri. Ma di impedire che qualcuno si inventi delle proprie estensioni. 
Basta vedere che cosa e' successo quando MS ha infilato il simbolo 
dell'euro in una codifica pre-esistente senza dire niente a nessuno...


Name:       Marco Barisione
Date:       Tue 30 Apr 02 19:33

Beh, se fosse l'inizio del subject originale, il messaggio non sarebbe una 
risposta, quindi avrebbe il campo <references> vuoto. E per i casi piu' 
unici che rari, per essere sicuro che non ci sia un /errore/ del 
newsreader che ha tolto tuttti i references, basterebbe semplicemente, in 
quel caso piu' unico che raro, controllare il Newsreader, e se 
e' Outlook Express, controllare anche il body del messaggio che non 
comprenda simboli di quote.
Ora. Un messaggio che inizi per R: non essendo una risposta, che non abbia 
references e che abbia pero' un simbolo di quote all'inizio di qualche 
riga di messaggio e che sia stato spedito da un Microsoft Outlook Express, 
penso che sia altro che unico, altro che raro... 
Sarebbe da incorniciare.
Peccato non poter accedere agli archivi di Google in modo classico. 
Sarebbe certo interessante rovistare in tutto l'archivio di un messaggi 
siffatto.
BTW... noi ci lamentiamo tanto del R:, ma non dimentichiamo che la cazzata 
e' stata fatta in moltissime lingue.


 dell'euro in una codifica pre-esistente senza dire niente a nessuno...
Appunto. Per poter sfruttare l'html come dici tu e senza i pericoli
derivanti dalle attitudini di MS e compagnia, bisognerebbe costringerli
a fare programmi che scrivono sě in html, ma incapaci di inserire altri
tag che non siano <html> <body> </body> </html>. E quando mai?


 quando mai? 
Tu vedi il problema all'incontrario. Non devi scrivere un "coder" html
che non metta i tag che hai indicato, ma il contrario. Un editor
plain-text che quanto incontra una e accentata inserisca il tag
corretto. Il concetto non e' molto differente dal punto di vista del
risutato, ma alquanto differente dal punto di vista della
implementazione. 
Cmq, credo che dopo aver compreso a fondo l'unicode tutto questo
discorso perda il suo valore, perche': 
a. si dovrebbe fare da quasi zero un nuovo semi-standard
b. l'unicode lo fa meglio
c. l'unicode e' gia' esistente
