Newsgroup: it.comp.software.newsreader
Titolo: Re: BAT!! Chi ha capito/Usa le novità


X/post F/to

 codifica degli header dentro al menù di impostazione
Esatto. La cosa è descritta nei dettagli nel readme.txt incluso in Agent 1.93
italiano, leggibile in parte anche sul nostro sito:
http://web.tiscali.it/agentit/pub/Note.193.txt
(nel paragrafo "Agent in italiano e il simbolo dell'euro")
-- 
Agent in italiano, faq e documentazione in italiano:
http://web.tiscali.it/agentit/
Luca - e-mail: p.stevens at 
libero.it


La codifica di Mackley è sbagliata! :-( Anch'io leggo "novit?" [1]
« Re: BAT!! Chi ha capito/Usa le novità? »
Se ha dichiarato "utf-8", nel messaggio originale ci doveva scrivere una
cosa come questa:
=?utf-8?Q?Re:_BAT!!_Chi_ha_capito/Usa_le_novit=C3=A0=3F?=
allora si sarebbe letto correttamente la "à". ;-) [2]
Invece ha scritto la codifica usata per "iso-8859-1".
La codifica di Alan _è corretta_ (e si legge chiaramente "à"), perchè ha
dichiarato "iso-8859-1" a cui corrisponde:
Re: BAT!! Chi ha capito/Usa le =?iso-8859-1?Q?novit=E0=3F?=
In sintesi: "à" in utf-8 = [=C3=A0] - "à" in iso-8859-1 = [=E0], mentre,
indipendentemente dal charset dichiarato, "?" = [3F], perchè a 7 bit.
[1] - però non posso sapere se dovuta a Pimmy o a Mackley. :-?
[2] - a conferma seguirà un messaggio in utf-8. :-D
-- 
     * b *
   *   y   *
 *   Piero   *
[/in medio stat virtus/]


La codifica di Mackley è sbagliata! :-( Anch'io leggo "novit?" [1]
« Re: BAT!! Chi ha capito/Usa le novità? »
Se ha dichiarato "utf-8", nel messaggio originale ci doveva scrivere una
cosa come questa:
=?utf-8?Q?Re:_BAT!!_Chi_ha_capito/Usa_le_novit=C3=A0=3F?=
allora si sarebbe letto correttamente la "à". ;-) [2]
Invece ha scritto la codifica usata per "iso-8859-1".
La codifica di Alan _è corretta_ (e si legge chiaramente "à"), perchè ha
dichiarato "iso-8859-1" a cui corrisponde:
Re: BAT!! Chi ha capito/Usa le =?iso-8859-1?Q?novit=E0=3F?=
In sintesi: "à" in utf-8 = [=C3=A0] - "à" in iso-8859-1 = [=E0], mentre,
indipendentemente dal charset dichiarato, "?" = [3F], perchè a 7 bit.
[1] - però non posso sapere se dovuta a Pimmy o a Mackley. :-?
[2] - vedi questo in utf-8. :-D
-- 
     * b *
   *   y   *
 *   Piero   *
[/deus ex machina/]

 [2] - vedi questo in utf-8. :-D
Però in questo tuo è rimasto nel dimenticatoio il puntointerrogativo
lo hai dimenticato tu, oppure qualche strano evento è occorso???

 lo hai dimenticato tu, oppure qualche strano evento è occorso???
Beh ho risposto al _tuo_ messaggio, e lì non c'è il "?". Comunque eccoti
accontentato. :-D
-- 
     * b *
   *   y   *
 *   Piero   *
[/audaces fortuna iuvat/]


Quando si risponde ad un messaggio Pimmy NON usa il charset del messaggio
al quale si risponde ma usa il charset impostato nelle opzioni per i
messaggi inviati. Però, già all'apertura fa un controllo e nel caso il
testo contenga caratteri non validi per il charset chiede se si vuole
spedire il messaggio in unicode. E' sempre possibile però cambiare il
charset con uno qualsiasi. Se il subject contiene caratteri estesi questi
vengono codificati con il charset utilizzato per il testo del messaggio.
Non so se Mackley ha impostato unicode come charset standard per l'invio
dei messaggi o se invece ha cambiato il charset durante la risposta al
messaggio.
-- 
-antonio-
www.geminisoft.com
(email valida sul mio sito)

 il charset utilizzato per il testo del messaggio.
La domanda verteva sulla correttezza della codifica fatta da Pimmy nel
messaggio di Mackley 
| Subject: =?utf-8?Q?Re:_BAT!!_Chi_ha_capito/Usa_le_novit=E0=3F?=
alla luce non solo degli errori di visualizzazione di altri programmi, ed
anche della analisi fatta da P/ero


Chiedo scusa, non ho seguito bene il thread.
Pimmy ha codificato il subject perchè ha trovato caratteri estesi e nel
farlo ha utilizzato il charset impostato per i messaggi da inviare oppure
il charset scelto da Mackley per il messaggio. Solo che c'è un problema in
Pimmy nella codifica del charset del subject quando viene utilizzato un
charset differente da quello di sistema. E' una cosa che era stata già
evidenziata e sulla quale dovremo fare una correzione.


 accontentato. :-D
C'è un piccolo errore in alcuni degli header Subject di questo thread.
L'header Subject di alcuni messaggi è il seguente:
   Subject: =?utf-8?Q?Re:_BAT!!_Chi_ha_capito/Usa_le_n?=
	=?utf-8?Q?ovit=C3=A0=3F?=
mentre avrebbe dovuto invece essere il seguente:
   Subject: Re: =?utf-8?Q?Re:BAT!!_Chi_ha_capito/Usa_le_n?=
	=?utf-8?Q?ovit=C3=A0=3F?=
Ciò perché un messaggio di reply dovrebbe sempre avere un header Subject
che comincia con i 4 caratteri ASCII "Re: ".
A buon intenditor...
- Dario

 A buon intenditor...
Cambia NR? No, ho le mie buone ragioni per continuare ad usarlo. ;-)
-- 
     * b *
   *   y   *
 *   Piero   *
[/errare humanum est/]

     Re: Re:BAT!! Chi ha capito/Usa le novità?
Hai ragione... che palle!
Avete capito cosa volevo dire?
Volevo dire (e lo riaffermo!) che un Subject di reply DEVE SEMPRE
cominciare con "Re: " (ovvero il "Re: " NON DEVE MAI essere codificato!)
Poi facendo l'esempio ho editato (male!) a mano...
L'header corretto è ovviamente:
      Subject: Re: =?utf-8?Q?BAT!!_Chi_ha_capito/Usa_le_n?=
        =?utf-8?Q?ovit=C3=A0=3F?=
che si legge:
      Subject: Re: BAT!! Chi ha capito/Usa le novità?
- Dario (che Alan Ford c'aveva ragione!)

 problemi a gestire i Re: nelle risposte (anche se codificati).
C'è un RFC (non ricordo il numero e non ho tempo di ricercarlo in 
rete...) che richiede il "Re: ".
La motivazione (IMO) penso che sia legata la fatto che possano esistere
alcuni news-reader obsoleti che semplicemente cercano un "Re: " ad 
inizio riga per fare il threading e non si mettono cercto a decodificare 
le encoded-words prima di farlo. Questa è (ancora IMO!) la mia possibile 
spiegazione.
In ogni caso un subject di un reply DEVE sempre cominciare con "Re: " 
(ad esempio una recente versione di Opera ha riconosciuto il bug 
impegnandosi a correggerlo al più presto).
Inoltre, ma dovrei rileggermi con attenzione il corrispondente RFC,
mi sembra anche di ricordare che le encoded-word possano essere 
utilizzate SOLO per codificare le singole parole di un header che 
contengano caratteri non ASCII.
Così ad esempio, una codifica corretta di:
   Subject: Re: BAT!! Chi ha capito/Usa le novità?
dovrebbe essere solo questa:
   Subject: Re: BAT!! Chi ha capito/Usa le =?UTF-8?B?bm92aXTDoD8=?=
dove si codfica la sola parola (o token) "novità?"
e non questa:
   Subject: Re: =?utf-8?Q?BAT!!_Chi_ha_capito/Usa_le_n?=
       =?utf-8?Q?ovit=C3=A0=3F?=
dove invece si codifica l'intero subject (a parte il "Re: " iniziale).
Sotto questo punto di vista ThunderBird è gia RFC-compliant
mentre Opera non lo è ancora.
- Dario (going to lunch...)

mentre Opera non lo è ancora.
Dalle mie prove direi che Thundebird codifica il subject dalla prima parola
con caratteri non ASCII in avanti.
Ad esempio il subject "Questa è una bella cosa" è diventato
Subject: questa =?ISO-8859-1?Q?=E8_una_bella_cosa?=


Antonio Donatiello wrote:

C'hai ragione, c'hai!
Quindi anche ThunderBird non rispetta la RFC!
- Dario

 Quindi anche ThunderBird non rispetta la RFC!
Prima di affermare che una RFC [non] viene rispettata si dovrebbe
riportarne il contenuto.
Personalmente troverei molto giusto, dal mio punto di vista, che venisse
codificata soltanto la parte /estesa/ lasciando pienamente leggibile ed
intellegibile ad un lettore umano la maggior parte possibile di quel
testo. Con analoga motivazione sarei piů propenso ad adottare il metodo
del QuotedPrintable piuttosto che il Base64 dato che quest'ultimo non č
affatto intellegibile da un lettore umano, anche se probabilmenyte piů
sicuro da errori tecnici nell'operazione di [de]codifica
Purtroppo, dalle mie scarne e saltuarie letture della RFC2047 (stiamo
parlando di quella o di quale altra?) non ho trovato traccia su
quanta|quale parte del testo vada o no codificata (salvo la lunghezza
massima di 75),  
Inoltre, se stiamo parlando di News, dovremmo riferirci alle draft, ma
non mi sembrano piů dettagliate nelle loro spiegazioni, semmai ancor meno

 non mi sembrano piů dettagliate nelle loro spiegazioni, semmai ancor meno
- Dario

Il documento che codifica le encoded-words è RFC1522.
Che è stato /obsoletato/ per l'appunto, dalla RFC2047


     Re: Re:BAT!! Chi ha capito/Usa le novitą?
Talmente chiaro che Dario ha digitato in fretta, che non ho sottolineato
l'errore. Mi sono limitato a correggere il subject a mano come suggerito
nel suo messaggio. ^_^
Tu invece, come l'hai /tirato fuori/ 'Dario caffčinomane'? :O)
-- 
     * b *
   *   y   *
 *   Piero   *
[/rebus sic stantibus/]

 Che è stato /obsoletato/ per l'appunto, dalla RFC2047
Per quanto riguarda le encoded-word la RFC2047 è una copia
(oserei dire verbatim!) della RFC1522.
Quindi continuo a dire che NON c'è obbligo di codificare
solo i token che contengono caratteri non-ASCII,
anche se è suggerito farlo.
- Dario

> anche usando mime proxy
Nel messaggio di Josef il subject è rimasto in 8bit non codificato,
mentre quelli tuoi precedente e successivo, sono codificati
come mai? sì lo so dovrei domandarlo a Josef, ma io so che tu lo sai

 come mai? sě lo so dovrei domandarlo a Josef, ma io so che tu lo sai
 
:DD
L'ho visto solo dopo con Pimmy (altrimenti l'avrei avvisato subito), 
visto che cmq con M-P in ingresso io li vedo tutti 1252 a 8 bit...
Basta mettere nel file .INI di configurazione del M-P:
    [default]
    ; use encoded_word ( RFC 2047 )
    encoded_word = 1
Oppure se lo si vuole telecomandare dal client solo alla bisogna, 
aggiungere l'header "X-Mp-Encoded-Word: yes" nel messaggio in uscita 
(che poi il M-P capisce che č per lui, lo toglie prima di spedire il 
msg e agisce di conseguenza).
Ciao.
-- 
 /   _ _ | Xnews e la documentazione in italiano
( (/( (/ | 
http://web.lacasadialice.it/alanford/

 no? :OŢ
Touché, e non aggiungo altro! :-P
-- 
     * b *
   *   y   *
 *   Piero   *
[/memento mori/]