Newsgroup: it.comp.www.php
Titolo: Non SGML Character, porcazzozza...

Buongiorno a tutti,
sto ravanando da un po' dietro ad un problema di cui proprio non riesco
a trovare la soluzione...
Ho un db (MySQL) in cui vengono caricati alcuni testi, probabilmente
copiati da un documento di Word (Win) e incollati nel form che poi li
inserisce nel db.
I dati vengono poi visualizzati e, tramite htmlentities, "encodati".
Dal punto di vista visivo nessun problema, c'è tutto, lettere accentate,
apostrofi, dieresi... Il problema me lo segnala il validatore del W3C,
che mi dice che alcuni caratteri non seguono lo standard SGML (la pagina
e' in XHTML 1.0 transitional).
A giudicare dal sorgente e dagli errori segnalati, sembra che ENT_QUOTES
non funzioni, o che non traduca ' in &rsquo; ma c'è dell'altro... Mi
vengono segnalati come caratteri non SGML anche spazi, trattini,
punti... BOH!?!?!
Proprio non capisco... E' il validatore che va per farfalle o, come
temo, mi sfugge qualcosa?
Help!  : )
-- 
Mr. Fix @ home

 spazi, trattini, punti... BOH!?!?!
Se sono stati incollati da word e' probabile che NON siano caratteri
ASCII, controlla il codice carattere dei caratteri incriminati.
-- 
I am what I am, I do what I can
Sei un newbie? Leggi questo 
http://url.repository.biz/go/3C
Vuoi supportarmi? 
http://url.repository.biz/go/3E
Do. Or do not. There is not try.

 ASCII, controlla il codice carattere dei caratteri incriminati.
Uhm... Io non uso windows, e neppure word, quindi immagino che dovrei
chiedere all'utente di dirmi il codice carattere dei caratteri
incriminati... Come si recupera 'sto dato, da Mappa Caratteri?
(si nota che windows lo conosco proprio bene?  : )
Ma poi, una volta che stabiliamo che quel carattere non è ascii, come la
risolvo? Temo che gli utenti "incollatori" non siano proprio delle cime,
e già col copia e incolla siamo al limite...
La cosa che capisco ancora meno è, visto che su Mac e Linux vedo tutti i
caratteri (Safari, Firefox e Konqueror), pure nel sorgente della pagina,
perché non vadano bene...


 la risolvo?
Devi ricodificare i caratteri NON ASCII trasformandoli in unicode (es
&#145;)
-- 
I am what I am, I do what I can


 &#145;)
Argh... Tutto 'sto casino per un copia e incolla da word... o_O
Pero', scusa se abuso della tua pazienza (ti offriro' un caffe'
virtuale, oppure reale, se passi in Liguria... ; ) a questo punto dovrei
impostare l'encoding della pagina xhtml come utf-8, e qui salta fuori un
altro problema...
Creo un file in xhtml 1.0 strict, con la dichiarazione xml iniziale
(utf-8) e il meta (charset=utf-8), metto dentro un testo pieno di
caratteri "speciali", lo passo al validatore del w3c e, secondo lui, č
in formato iso-8859-1 (!).
L'encoding della pagina e' in utf-8 garantito, le interruzioni di linea
sono in formato dos/windows, altrimenti il parser si intazza e non
funziona piů niente.
Che serataccia...


 funziona più niente.
Prova ad aggiungere un header('Content-Type') che specifica MIME e charset, 
che poi è ciò che fa il <meta> che dici di aver messo, solo che viene 
analizzato prima di tutto quanto.
Ma non ho capito: hai già aggiunto il codice per sostituire i caratteri 
multibyte (per i quali serve appunto UTF) con caratteri ISO-8859-1 (&#nnn;)? 
Un testo UTF-8 senza caratteri multibyte è un testo ISO-8859-1 (nel senso 
che non ci sono differenze).
-- 
ColdShine
"L'esperienza è un'insegnante severa: prima ci esamina
 e solo dopo ci fa lezione." - legge di Vernon Sanders 

 che non ci sono differenze).
Uhm... Non sono sicuro di aver capito quello che mi scrivi... Ho tentato
di utilizzare htmlentities con utf-8 invece che iso ecc, ma niente da
fare.
A questo punto mi viene il vago sospetto che il problema sia a monte...
Nel form di inserimento dei testi e nel successivo immagazzinamento in
MySQL...


 MySQL...
Possibile... se il form è in una pagina UTF-8, e la pagina di action copia i 
dati pari pari nel db, la pagina che legge dal db dovrà essere anch'essa 
UTF-8; altrimenti devi usare utf8_decode() ogni volta che leggi la stringa 
del db (o, se possibile, memorizzare nel db la stringa già decodificata).


 del db (o, se possibile, memorizzare nel db la stringa già decodificata).
Ho programmato 'sta roba (perche' chiamarla "procedura" mi pare pure
troppo...  : ) diversi anni fa e temo di aver fatto un po' di casino...
MI puzza che i dati vengano trattati come iso-8859-1 e nei vari passaggi
si scassi qualcosa...
Vabbe', e' da tanto tempo che volevo riscrivere tutto l'ambaradan... Se
nel fine settimana piove...  : /
