Newsgroup: it.comp.os.linux.iniziare
Titolo: Mi dareste una mano con gli accenti?

Qualcosa sembra essersi guastato dopo che ho
predisposto un nuovo utente semplice che sto
utilizzando adesso sulla mia slax-6.1.2.
Ho tin com newsreader, ed sn come news server.
Poi come server remoto uso aioe/albasani.
Ora vorrei chiedervi come vedete le seguenti accentate:
a':  à
e':  è
i':  ì
o':  ò
u':  ù
Quando riscarico il messaggio ottengo un buon
risultato, nel senso che sul mio client le accentate le
visualizzo correttamente.
Controllando però da google groups riscontro un
problema: quei caratteri si sono misteriosamente
tramutati in lettere greche o giù di lì.
Il fatto è che i miei vecchi messaggi sempre spediti
dalla slax sembrano apposto, solo da pochi giorni la
situazione sembra cambiata, ma non ho cambiato nulla,
almeno volontariamente... poi c'è da registrare un
crash che avevo poi ripristinato, potrebbe aver
coinvolto qualche file attinente la codifica...
francamente mi pare strano però non si sa mai.
grazie in anticipo.

 u':  ù
sono a posto;
r
-- 
if I go insane
please don't put your wires in my brain
[Roger Waters: If]
http://digilander.libero.it/charlesbaudelaire

 
Qui le vedo sballate
-- 
Archlinux on (uname -a)
F

 
E qui le vedo giuste. Ma codifica l' OP usa per inviare i messaggi?


 tramutati in lettere greche o giù di lì.
qua (googlgroups sotto winxp) si vedono giuste.
Ciao Jack

 u':  ù
Mmmm, adesso le vedo bene anche io da google groups.
E forse ho anche mezzo capito dove può stare il problema.
Anche se non ne ho ancora cpito le cause.
La codifica che uso è la iso-eccecc-15... a livello di
sistema sembra ok anche il "locale".
Per chi non riesce a visualizzarle, potrebbe essere
necessario istruire il proprio reader ad attribuire la
codifica iso-8859-1 per esempio qualora questa non sia
specifica negli header del messaggio in questione.
In tin si imposta dal file ~/.tin/attributes con la
direttiva:
undeclared_charset=ISO-8859-15
In questo modo, se un messaggio non contiene nei propri
headers la codifica, il nostro client assume per
ipotesi che questa sia, per esempio nel mio caso,
iso-8859-15.
Frequentando gruppi italiani inglesi o comunque di lingua 
occidentale dovrebbe funzionare rendendo tutti messaggi
leggibili. O comunque in caso contrario il problema non
è il nostro.
Chiusa la parentesi per rispondere all'utente che non
riusciva a leggere le accentate. Mi pare fosse Fulvio.
Per capirci, se le accentate sono visibili da google
groups allora dovremmo vederle anche noi magari
mettendo mano alla configurazione del nostro client.
Tornando al mio problema, vi propongo il mio prossimo
messaggio che dovrebbe essere postato da albasani
invece che 
aioe.org
 e dovrebbe contenere accentate mal
visualizzabili anche da google groups.
Modificherò leggermente anche il mio nome utente, ma
non preoccupatevi, mi serve solo er non toccare questa
mia configurazione funzionante. Insomma sono sempre io.
Intanto grazie per la collaborazione.

 Intanto grazie per la collaborazione.
a':  à
e':  è
i':  ì
o':  ò
u':  ù
Ora le vedete?

 Ora le vedete?
Ovvio che le vedete è come prima, scusate ho sbagliato
dimenticando di cambiare il server...
a':  à
e':  è
i':  ì
o':  ò
u':  ù
Adesso com'è?

 Adesso com'è?
Niente, le vedo correttamente prova fallita, nel senso
che non posso postare in questo gruppo passando per il
l'altro server... è un po' complicato da spiegare.
Però posso postare su it.test.
Venite là a dare un'occhiata, poi se volete rispondete
anche qua, che è più attinente.
Ora posto in it.test un nuovo topic intitolato:
"new test accentate"

 "new test accentate"
HO provato a postare in it.test il topic di cui sopra.
PErò anche via google vedo le accentate correttamente.
Ora visto che non vorrei passare per bugiardo vi posto
il link al topic che avevo provatostamattina sempre su
it.test.
http://tinyurl.com/383lgqc
Lì si vede come le mie accentate siano state rese in
modo quanto mai strano.
Ripeto sul mio client le vedo bene, ma su google non si
vedono allo stesso modo.
Non so quale sia stata la causa, potrebbe anche
ripresentarsi, il problema, mah
Per oggi sembra scomparso.

Qui le vedo sballate
Per Johnny:
Queste son le uniche di tutto il 3d che non vedo, cioe'
vedo dei quadratini. Guarda che google stesso se di un
post passi a "mostra originale" visualizza male quel che
prima visualizza bene (e forse anche viceversa).
-- 
Saluti, Dalet


NNTP-Posting-Host: sBQ3yw2gecqG1/
MJMumM5g.user.speranza.aioe.org
X-Complaints-To: 
ab...@aioe.org
X-Notice: Filtered by postfilter v. 0.8.2
Xref: 
diesel.cu.mi.it
 it.comp.os.linux.iniziare:594568
Il Content-Type e il Charset dove sono?
Le vedi bene finché le leggi (per botta di culo) su un sistema che ha la
stessa codifica di quella usata per scriverlo (quindi sul tuo stesso PC
le vedrai sempre bene).
Viceversa devi aggiungere fra gli headers:
Content-Type: text/plain; charset=ISO-8859-15
Che "dice" a un lettore estraneo quale codifica applicare.
-- 
Massimo Bacilieri AKA Crononauta

 Content-Type: text/plain; charset=ISO-8859-16
+1

Giacomo Boffi ha scritto:

  Romeno?
  Ciao,
-- 
Alessandro Selli, 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 E qui le vedo giuste
E se si facesse come una volta che uno usa l' apostrofo al posto delle 
accentate?
Di sicuro si perde pochissimo.
-- 
Archlinux on $(uname -a) :P
F

 prima visualizza bene (e forse anche viceversa).
Si il punto è proprio quello, come avrai forse notato
ho messo un link ad alcune prove fatte oggi prima di
postare questo topic qua.
In quel tentativo su it-test dal subject "testing-acc",
guardandolo da google groups vedo le stranelettere
greche, però l'originale "show original" appunto,
mostra le lettere accentate correttamente.
Quindi è vero anche il viceversa.
Il problema sta nel mio header contentype ecc mancante
come spiega dalet.

 Che "dice" a un lettore estraneo quale codifica applicare.
Sì penso che il problema sia tutto lì, anzi no. Il
problema è che non me n'ero mai accorto prima.
O perchè nessuno ha mai rilevato il fatto o qperchè non
me lo ha mai comunicato.
La soluzione è multipla:
1- come ho già spiegato impostando il proprio client
per attribuire il charset iso-8859-15 a quei messaggi
che non hanno cContent-Type specificato si risolve
praticamente sempre a meno di non frequentare gruppi
in cui si scrive in cirillico cinese ecc.
2- la soluzione a  monte e corretta è comunque la tua,
nel senso che ovviamente si deve impostare il proprio
client in modo che comunichi il contenttype.
Domanda che mi pongo:
usando tin come newsreader, perchè mai questo non è di
default impostato per comunicare il proprio charset???
Eppure è un client piuttosto standard, che dovrebbe
includere questa impostazione...
Dico anche e devo controllare, che può essere che i
mieiheaders siano filtrati in modo errato portando
all'eliminazione dell'header in questione. 

 all'eliminazione dell'header in questione. 
Ho fatto un nuovo utente con una configurazione pulita.
Come vedete non vedo i miei accenti di prima perchè non
ho impostato come dicevo il file attributes.... va bè.
à
è
ì
Vediamo se spedisce l'header ContentType.


Ok, sta volta sembra ok...
Quindi il problema non sta in tin, ma in sn, o filtri intermedi..
Grazie ancora delle risposte.

 Grazie ancora delle risposte.
Ho fatto alcune ricerche ma senza esito. Ricapitolo.
Problema:
i miei articoli non hanno l'header "Content-Type".
Prove fatte:
1) Posting diretto tra il mio client "tin" server
   remoto presso servizio 
aioe.org
.
2) Posting indiretto dal mio server locale "sn" sempre
   verso 
aioe.org
.
La seconda modalit� � quella che uso di solito e che
voglio far funzionare bene. In pratica localmente ho il
news server installato, "sn" appunto.
I messaggi che scrivo col client tin ed inviati vengono
messi in un file:
/var/spool/news/it.test/.outgoing/$NUMEROARTICOLO
Quel file altro non � che il messaggio da inviare, in
formato testo...
Se vado a controllare quel file con cat per� non vedo
l'header Content-Type.
Ne deduco che tale header non viene aggiunto dal client
ma dal server. Mi sbaglio? Riformulo la domanda:
Chi in concreto aggiunge l'header Content-Type negli
articoli di usenet?
� un compito che spetta al server che riceve o al
client prima di spedire?
Ipotizzando che sia un compito del server si
spiegherebbe perch� la prima prova funziona (posting
diretto) e la seconda no... Non vi pare?
Cio�:
- Se header Content-Type non � aggiunto dal server
  allora ho qualche errore nella fase di posting locale
  tra client e server.
- Se viene aggiunto generalmente dal server allora ho
  un problema nel server che non aggiunge questo header
  automaticamente.
Un vostro parere mi farebbe molto comodo perch� la
ricerca non sembra portare ad alun risultato... in
effetti � un aspetto un po tecnico ed anche un po' OT
ammetto.

 diretto) e la seconda no... Non vi pare?
Il server non deve aggiungere o modificare nulla dell'encoding per il
semplice fatto che o l'encoding è già impostata correttamente con i
giusti campi MIME (e allora non c'è nulla da modificare) oppure non
è impostato nulla e allora si presume ASCII o ISO-88591-1 (e anche qui
non c'è bisogno di cambiare nulla).
Riferimenti: RFC 977 (NNTP), RFC 2045 (MIME).
Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  
www.icosaedro.it


User-Agent: slrn/pre1.0.0-18 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-ID: <slrnic337q...@e8400.casamia>
===================== fine copia =============
quindi tutti gli altri che troverai li ha messi aioe ciao.
-- 
Saluti, Dalet


Date: Fri, 22 Oct 2010 13:40:35 -0000
Bytes: 100
Lines: 5
-------------------------------fine copia----------------------------------
� un messaggio di prova postato verso il gruppo it.test.
Quando da tin premo "p" per postare il messaggio,
questo viene preso in consegna dal server locale "sn"
ed accodato per il post remoto nel file sopra.
Gi� l� manca l'header Content-Type.
Ora, tin produce un articolo comprensivo di diversi
headers tra cui dite voi dovrebbe esserci anche il
Content-Type. Per� quando viene recapitato il messaggio
nella coda d'uscita, quell'header non c'�.
Per partire col piede giusto, mi servirebbe un modo per
sostituire al comando di posting di tin un comando di
visualizzazione del messaggio comprensivo di headers
direttamente a stdout. Tipo cat per capirci.
In quel modo si vedrebbe senza dubbi com'� fatto
realmente il messaggio in partenza dal client.
Idee?

Idee?
-- stacca il cavo di rete, se cosi' resta in outgoing. Poi
te lo guardi e poi riattacchi il cavo (lo dico perche' non
lo so come funziona sn e io per inviarli do il comando a
mano a slrnpull (associato a slrn, e' tipo leafnode))
-- molla tin e passa a Slrn che e' splendido
-- leggiti /usr/doc/tin/README (o manual) perche' ricordo
che tin c'ha una barca di opzioni e figurati se non puo'
mettere quegli header.. magari saranno disabilitati di
default per gli usa.
-- 
Saluti, Dalet

 default per gli usa.
Se cos� fosse non ci sarebbero neanche nella mia prova
diretta verso aioe.org... Quindi lui gli invia ripeto
deve essere per forza sn a prendere in consegna il
messaggio e tagliare qualche headers che evidentemente
ritiene di troppo. Devo capire un po' meglio quale
pezzo di sn � il colpevole (ci sono numerosi
programmini con compiti precisi).
Il problema � che google non m'aiuta, in effetti sn �
un progetto un po' vecchio. Ma � molto versatile e
nonostante non sia cos� pulito forse, per piccoli
sistemi/reti va bene.
Di solito usavo inn + suck + tin, ma attualmente sono
su slax e non volevo mettere su tutto l'armamentario.

su slax e non volevo mettere su tutto l'armamentario.
Esagerato addirittura inn! ma scusa ho visto adesso che sn
e' simile a leafnode.. be' cosa aspetti allora a mettere
leafnode che e' famosissimo e - penso - perfetto? io lo
volevo mettere perche' slrnpull gestisce un solo news-server
ma ho fatto prima a cambiargli i file di configurazione ogni
volta che aioe va down per piu' d'un giorno.
-- 
Saluti, Dalet


Facebook: Massimo Bacilieri

MM_NETWORK_CHARSET=it_IT.iso8859-15 nel ~/.bashrc sarebbe risolutivo).
Be' mi sembrava un po' strano/improbabile anche a me di sn,
cmq mi sa che ormai conviene UTF-8 e non piu' it_IT, o no?
-- 
Saluti, Dalet



Teoricamente sï¿œ, ma siccome ancora troppa gente usa iso-8859-15 (e non a
torto, perchï¿œ ï¿œ lo standard ISO per la lingua italiana), ho sperimentalmente
visto che dopo si genera solo confusione su usenet, perchï¿œ quelli che hanno
quei *cessi* di Outlook dopo scombinano i charset, e si inizia a vedere una
sequela di quadratini e punti interrogativi...


quei *cessi* di Outlook
!! LOL quoto!
-- 
Saluti, Dalet

 Teoricamente sì, ma siccome ancora troppa gente usa iso-8859-15
Di /buona regola/ sui news groups non si usavano gli accenti. Poi arriva 
qualcuno che vuol sconfiggere la /buona regola/. E se non vado errato l' 
iso sarebbe 8859-1 e non *15*


 iso sarebbe 8859-1 e non *15*
Sono la stessa cosa mi pare che cambi solo il simbolo
dell'euro.
Al momento sto usando sul sistema iso-8859-1 pertanto
ho impostato mm-charset coerentemente, posto un
pezzetto del "~/.tin/tinrc":
---------------------------
# Charset used for MIME (Content-Type) header in
# postings.
mm_network_charset=ISO-8859-1
# If ON, use //TRANSLIT extension. This means
# that when a character cannot be represented
# in the in the target character set, it can be
# approximated through one or several similarly
# looking characters.
translit=OFF
# MIME encoding (8bit, base64, quoted-printable,
# 7bit) of the body for mails and posts, if
# necessary. QP is efficient for most European
# character sets (ISO-8859-X) with small fraction
# of non-US-ASCII chars, while Base64 is more
# efficient for most 8bit East Asian, Greek, and
# Russian charsets with a lot of 8bit characters.
post_mime_encoding=8bit
mail_mime_encoding=quoted-printable
# If ON, 8bit characters in news headers are NOT
# encoded. default is OFF. Thus 8bit characters
# are encoded by default. 8bit chars in header
# are encoded regardless of the value of this
# parameter unless post_mime_encoding is 8bit as
# well.
post_8bit_header=ON
---------------------------------------------------
Non so se avete letto alcune mie osservazioni:
se fosse tin mal impostat allora fallirebbe anche
post diretto verso aioe.
Post diretto verso aioe significa lanciare tin cos�:
~$ rtin -Qg 
nntp.aioe.org
In questo modo si bypassa completamente l'accrocchio
locale e ci si connette direttamente al server news
(inn) di aioe. � una cosa ovvia ma neanche io l'avevo
pensato, intendo se fosse tin il problema e visto che
aioe non aggiunge gli headers content type, allora il
posting fallirebbe anche col metodo sopra. Invece
lanciando tin cos� (bypassando quindi sn) il post
avviene con tutti gli headers content-type e parenti..
Pertanto il problema sta in mezzo: lanciando tin cos�:
~$ rtin -g localhost
In tal modo ci si collega al server (sn) locale. Che
dev'essere quasi certamente lui a ritoccare gli
articoli prima di accodarli.
Perch� tin comunica gli headers ad sn cos� come a aioe
(perch� dovrebbe altrimenti fare distinzioni?),
entrambi prendono il messaggio entrambi ritoccano
alcuni headers (come per esempio la data e altri
hearders fondamentali) poi aioe mette direttamente il
post nel suo spool, cio� nella sua directory che
contiene il gruppo verso cui si � postato. Invece sn
preso l'articolo lo deposita temporaneamente nella cosa
d'uscita. E gi� qui sbirciando il contenuto si notano
gli headers Content-Type ecc.. mancanti.
Chi diceva di utilizzare leafnode.
Anni f� lo utilizzavo, ma era un po' troppo lento
durante la fase di post verso remoto e scaricamento in
locale dei nuovi messaggi.
La soluzione che avevo adottato successivamente
(suck+rpost) � parcchio pi� rapida soprattutto con
connessioni ad alta latenza come la mia (mi collego con
un cellulare ad internet).
Sn non � forse rapido come suck ma poco ci manca,
meglio di leafnode da questo punto di vista.
Va b� cerchiamo un po' di aggiustare la faccenda,
magari anche facendo una prova di forzatura degli
headers mancanti attraverso il file attributes.

 ------------------------------------------------

Allora, il problema stava tutto in quell'ultimo
parametro impostatoad "ON".
Questo mi lascia un grosso dubbio. Ad ogni modo,
dal manuale:
__________________________________________________________
Use 8bit characters in news headers (post_8bit_header)
 Allows 8bit characters unencoded in the header of a news
 article, if set this also disables the generation of
 MIME-headers when they are usualy required. Default is OFF.
 Only enacted if post_mime_encoding is also set to 8bit. In
 a number of local hierarchies where 8bit characters are
 used, using unencoded (raw) 8bit characters in header is
 acceptable and sometimes even recommended so that you need
 to check the convention adopted in the local hierarchy
 of your interest to determine what to do with this and
 post_mime_encoding.
-----------------------------------------------------------
In parole povere impostando ad ON la voce (post_8bit_header)
viene disabilitata la generazione dei MIME-headers, che
particamente sono quelli di cui stiamo discutendo:
Mime version
Content-Type
E l'altro che non ricordo a memoria.
Ora, non chiedetemi perch� diavolo ho impostato ad ON quel
parametro. Per� adesso l'ho messo ad OFF e pertanto nel
persente articolo dovreste poter vedere gli header in
questione che prima non c'erano. Postando su it.test mi pare
tutto apposto, se comunuqe poteste confermarmi sarebbe utile.
Andando a vedere nella coda dei messaggi in uscita,
adesso risulta che gli header ci sono anche nel messaggio
pronto per essere spedito, quindi tin li ha aggiunti
correttamente adesso.
Pertanto "sn" non rimaneggiava quegli headers tagliandoli,
come mi sembrava ovvio supporre.
C'� un per�:
come mai postando direttamente sul server di aioe il
messaggio conteneva gli header giusti, nonostante quel
parametro fosse impostato ad "ON"???
A questo punto sta domanda �solo una curiost�, per� mi
piacerebbe capirlo.
Aspetto allora una conferma sulla correttezza dei
miei attuali headers inerenti la codifica ed eventualmente
voleste azzardare qualche ipotesi che spieghi la faccenda,
sonon tutt'orecchi.  :-)
Saluti!

 iso sarebbe 8859-1 e non *15*
L'iso standard ï¿œ 8859-15 da quando c'ï¿œ l'euro (una decina d'anni
insomma...), che ï¿œ poi quello corrispondente al locale it_IT@euro.



NNTP-Posting-Host: UlfMKKGgw3YgC+
e4owPjKw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Complaints-To: 
ab...@aioe.org
X-Notice: Filtered by postfilter v. 0.8.2
Xref: 
news.home.net.it
 it.comp.os.linux.iniziare:9487
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >