Forum libero

> > > > àèéìòùÀÈç etc.
> > >
> > > Prova quotatura.
> >
> > Bene, adesso potreste spiegarmi come avete fatto?
> > Così se mi dovesse servire avrei la soluzione.
>
> Gli interventi sono stati tre:
> - abbiamo migrato il db da latin1 a utf8 seguento questa guida:
> http://en.gentoo-wiki.com/wiki/Convert_latin1_to_U...

Più che giusto.
alex.tg direbbe che non ci dev'essere altro che lower ASCII e io preciserei un sottinsieme dei lower ASCII, i caratteri del base 64 o poco più, però le versioni recenti dei database sono UTF-8 compatibili.

> - nel tipo di connessione a mysql abbiamo cambiato l'url del db aggiungendo useUnicode=yes e characterEncoding=UTF8:
> http://ravanator.acmetoy.com/src/FdtDueZero.git/Fd...

Idem, aggiungo però che è roba del database e quindi non di aiuto al caso di mio interesse, in cui salverei i record come file di testo.

Nel problema che avevo avuto io, sembrava che i caratteri non-sicuri fossero alterati durante la trasmissione del form, a monte dell'uso che poi se ne sarebbe fatto. Alla luce di come è stato risolto qui il problema, mi chiederei se fosse il browser a trasmetterli male (come ho pensato allora) o il server a riceverli male, magari in base a qualche stringa inviata dal browser.

Sarei curioso di vedere che succede, con vari browser anche vecchiotti, trasmettendo del testo con un semplice form che chiama uno script che si limita a scrivere il testo ricevuto a) in una pagina web b) in un file di testo.

> - per fixare chrome che manda un content-type senza charset in fdt.js abbiamo aggiunto l'header giusto in beforeSend sul post del messaggio ajax:
> http://ravanator.acmetoy.com/src/FdtDueZero.git/Fd...