punto interrogativo (?)

[lilo]

Nella stragande maggioranza dei siti in php, da qualche tempo vedo sempre frequenti "?" al posto di lettere accentate ecc.

1) Questo è dovuto alle nuove versioni di mysql installate sui servizi di hosting o cosa ? Oppure qualche errore del webmaster a livello di codice e/o script ? E' un errore generale abbastanza fastidioso presente anche nei grandi portali.

2) quale soluzione ?

[IroN@xiD]

E' un problema di encoding.
Caratteri non rappresentabili vengono sostituiti con un punto di domanda.
Il problema è senza dubbio risolvibile.
Il set di funzioni mb_string (multi-byte string) serve proprio a questo.

Se si dichiara che la pagina contiene caratteri utf8 è opportuno codificare i caratteri che si mandano in output in utf8 prima di inviarli.
Vale lo stesso se si dichiara che la pagina è iso-8859-1. Teniamo presente però che in iso-8859-1 alcuni caratteri (come il simbolo dell'euro) non esistono e saranno rappresentati (o sostituiti dalle funzioni di conversione) con dei punti di domanda.

[daniele_dll]

beh ... basta sputar fuori un bel

header('Content-Type: text/html; encoding=UTF8');

per aggirare il problema (se la pagina è in UTF8) .. oppure basta cambiare utf8 per sistemare la cosa

l'utilizzo di apposite funzioni di conversioni diviene inevitabile nel caso che i dati ricevuti siano in un modo, ad esempio, e quelli estratti da db siano in un'altro formato

[lilo]

Originariamente inviato da daniele_dll
beh ... basta sputar fuori un bel

header('Content-Type: text/html; encoding=UTF8');

per aggirare il problema (se la pagina è in UTF8) .. oppure basta cambiare utf8 per sistemare la cosa

l'utilizzo di apposite funzioni di conversioni diviene inevitabile nel caso che i dati ricevuti siano in un modo, ad esempio, e quelli estratti da db siano in un'altro formato

Nel mio caso ad esempio faccio le pagine con la sintassi :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">

in questo caso basta mettere sopra ogni pagina :
<?
header('Content-Type: text/html; encoding=UTF8');
?>
per nn vedere + quei fastidiosi "?" ?

Quindi sono dovuti dal browser che nn li codifica in pratica ?

[IroN@xiD]

Originariamente inviato da daniele_dll
beh ... basta sputar fuori un bel

header('Content-Type: text/html; encoding=UTF8');

La pagina non è mai in utf8 a meno che non sia già stata codificata.
Tutto ciò che si manda in output senza codifiche con php viene inviato nella codifica settata dalla variabile internal_encoding che si può settare sul php.ini (di default ISO-8859-15 se non sbaglio)
Ne deriva che tutto ciò che ha codifiche differenti va sempre codificato prima di andare in output.
Se non prelevi dati da altre fonti ti conviene codificare tutto con l'handler di mb_string per i buffer.
In questo modo la funzione handler applica l'header corretto al documento e codifica correttamente tutto il documento.

X lilo

I punti di domanda sono caratteri non rappresentabili nel charset impostato per il documento.
Per farti un esempio spiantato ma che rende l'idea.

Supponiamo di aver indicato il charset VOCALI (non esiste naturalmente) e mandiamo in output questa frase.

Ciao questo è un esempio

il risultato sarà

?iao ?ue??o ? u? e?s??io

Perchè il charset VOCALI non prevede le consonanti e il punto di domanda sta a significare proprio "Ma che cavolo di carattere è questo?!?"

Questo è un tipo di errore classico quando si utilizza un charset non adatto alla propria lingua.
Per esempio l'italiano ha le lettere accentate ma il charset non le prevede.
L'esempio del simbolo dell'euro è un altro caso. Il simbolo è previsto infatti in ISO-8859-15 ma non in ISO-8859-1.
Se imposti il charset in ISO-8859-1 e provi a mandare in output il simbolo dell'euro vedrai un bel punto di domanda

Se cambi charset e utilizzi ISO-8859-15 vedrai che il simbolo compare correttamente.

Un altro tipo di errore consiste nell'inviare caratteri con un encoding diverso da quello previsto nel documento. Questo può originare punti di domanda, caratteri multipli, caratteri assurdi, caratteri assurdi e multipli

L'importante è individuare il carattere giusto per la pagina. Se c'è solo contenuto in italiano l'iso-8859-15 andrà benissimo. Se invece la pagina avrà contenuti multuilingua allora la cosa migliore da fare è utilizzare utf8. Una volta individuato l'encoding devi assicurarti di inviare i caratteri correttamente codificati come hai indicato.
Se usi utf-8 devi puoi codificare tutta la pagina prima di andare in output.

N.B. Le funzioni di encoding (anche quelle mb_string) sono piuttosto stupide. Se cerchi di codificare in utf8 del testo che è già in utf8 non ottieni l'effetto che potresti attenderti (cioè lo stesso testo ancora in utf8) ma il tutto sarà nuovamente codificato con effetti imprevisti.

[daniele_dll]

Originariamente inviato da IroN@xiD
La pagina non è mai in utf8 a meno che non sia già stata codificata.
Tutto ciò che si manda in output senza codifiche con php viene inviato nella codifica settata dalla variabile internal_encoding che si può settare sul php.ini (di default ISO-8859-15 se non sbaglio)
Ne deriva che tutto ciò che ha codifiche differenti va sempre codificato prima di andare in output.
Se non prelevi dati da altre fonti ti conviene codificare tutto con l'handler di mb_string per i buffer.
In questo modo la funzione handler applica l'header corretto al documento e codifica correttamente tutto il documento.

ehm ... tu dai per scontato che ci sta l'estensione mb installata

internal_encodings è un settaggio disponibile SOLO se è presente l'estensione e questo perché php non utilizza NESSUN tipo di codifica, ma gestisce i caratteri singolarmente

per la precisione, senza le mb, per php un dato BYTE corrisponde esattamente ad un dato CHAR (carattere) perché, effettivamente, se non si usa una codifica multibyte, sono la stessa cosa

in UTF8 la cosa è diversa perché un carattere potrebbe corrispondere a 2 byte

Inoltre non è strettamente necessario utilizzare le funzioni di mb_string, basta che queste siano installate e che sia abilitato l'overload delle normali funzioni e quindi, definendo il corretto internal encodings, si ci può muovere come pare e piace

I template inviati al browser, quindi tutti i dati che il browser riceve, in buona parte sono "statici" ... questi dati dovrebberò essere predisposti per QUALSIASI codifica, ovvero dovrebberò essere inviati utilizzando la tabella dei caratteri ascii base, quindi i primi 127 caratteri, codificandoli con la convezione HTML per la codifica di caratteri speciali (vedi lettere accentate o caratteri speciali)

seguendo questa basilare regola ... tutto il resto non è importante ... puoi buttar fuori i dati come ti pare e piace perché tanto il browser, una volta che li riceve, li converte nel modo corretto nella codifica corretta.

Di conseguenza fa differenza SOLTANTO come vengono salvati nel db, e questo, soprattutto con mysql41, fa PARECCHIA differenza dato che ci sono gli hosters che utilizzano latin1, ma ci sono anche gli hosters che utilizzano l'utf8 ... di conseguenza una semplice lettura di questi dati ed un'invio causerebbe un gran papocchio se ci stanno caratteri speciali o altro

perché conviene usare UTF8? perché, senza fare ASSOLUTAMENTE NULLA, si da la possibilità di avere il proprio software utilizzato da chi non usa codifiche standard ... questo può essere utile come non potrebbe esserlo ... ma alla fin fine è una cosa in più

[IroN@xiD]

Scusa Daniele ( giusto? ),

sono d'accordo che per usare le funzioni mb_string dev'essere caricato (se sei su windows) oppure installato e caricato (se sei su linux/unix) il modulo mb_string, la ritenevo una cosa scontata (forse sbagliando ma finora non ho ancora trovato un host che non lo mette a disposizione).

Parlando di un tema molto generale (cioè non sappiamo a che lingua si riferisce lilo) ho preferito tirare in ballo direttamente utf8 che ci consente di gestire tutti i caratteri, anche quelli non rappresentabili con la tabella ASCII (normale o estesa) o per mezzo delle entità HTML.

A questo punto le considerazioni che hai fatto sui template perdono senso. Se ti basta sfruttare le entità html e carattery single-byte allora cosa te ne fai di utf8?
Non è detto che utf8 serva solo per quello che riceviamo in input dagli utenti, anche il resto potrebbe aver bisogno di essere muti-byte.
Inoltre io ritengo che se si imposta UTF-8 sia inutile codificare con le entità HTML caratteri che sono già presenti e fruibili nel set di caratteri che utilizziamo.

Infatti tu dici che

I template inviati al browser, quindi tutti i dati che il browser riceve, in buona parte sono "statici" ... questi dati dovrebberò essere predisposti per QUALSIASI codifica, ovvero dovrebberò essere inviati utilizzando la tabella dei caratteri ascii base, quindi i primi 127 caratteri, codificandoli con la convezione HTML per la codifica di caratteri speciali (vedi lettere accentate o caratteri speciali)

ma purtroppo non è vero che con ASCII e le entità HTML puoi predisporre per QUALSIASI codifica e quindi torniamo al punto di cui sopra.

Quindi come si deduce non è vero che tutto il resto non è importante e non è vero che "fa differenza SOLTANTO come vengono salvati nel db".

perché conviene usare UTF8? perché, senza fare ASSOLUTAMENTE NULLA, si da la possibilità di avere il proprio software utilizzato da chi non usa codifiche standard ... questo può essere utile come non potrebbe esserlo ... ma alla fin fine è una cosa in più

Mi pare una visione un po' riduttiva delle funzioni di utf8.
Utf-8 va utilizzato per rappresentare tutti i caratteri che diversamente non sarebbero rappresentabili e/o sarebbero rappresentati in modo differente tra differenti set di caratteri.
Inoltre non sono d'accordo sul fatto che non serve fare ASSOLUTAMENTE NULLA. E' proprio facendo ASSOLUTAMENTE NULLA (limitandosi ad impostare il content encoding) che alla fine ci si ritrova con i punti di domanda o con caratteri imprevisti.
Impostare UTF8 come encoding prevede che si vada in output con utf8 e per essere sicuri di farlo sempre è utile utilizzare le funzioni di conversione. Chiaramente non è sempre indispensabile, tanto più quanto si ritiene che utf8 non è indispensabile ed alla fin fine è "una cosa in più".

[lilo]

Originariamente inviato da lilo
Nel mio caso ad esempio faccio le pagine con la sintassi :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">

in questo caso basta mettere sopra ogni pagina :
<?
header('Content-Type: text/html; encoding=UTF8');
?>
per nn vedere + quei fastidiosi "?" ?

Quindi sono dovuti dal browser che nn li codifica in pratica ?

Ho provato a utilizzare questo metodo ma il simbolo dell'euro rimane sempre un punto interrogativo.

In generale utilizzo questo tipo di encoding (utf-8) perchè realizzo siti multilingua con frequente utilizzo di diversi accenti in francese e umlaut in tedesco. Hosting è din tipo base, nn so se il mio provider supporta funzioni di mb_string.
Ma in pratica banalmente come potrei risolvere ?

[IroN@xiD]

Per operare correttamente con le codifiche devi definire due cose.

La codifica che ha attualmente la stringa/carattere.
La codifica con cui quella stringa/carattere deve andare in output.

Quando hai queste due informazioni puoi usare mb_string per trasformare l'enconding attuale nell'encoding con cui vuoi andare in output ed ottenere correttamente i caratteri.

Con mb_get_info(); puoi controllare se mb_string è disponibile e tutte le impostazioni che lo riguardano.

Per capire che encoding ha la stringa che vuoi mandare in output puoi usare mb_detect_encoding

[daniele_dll]

Originariamente inviato da IroN@xiD
Scusa Daniele ( giusto? ),

sono d'accordo che per usare le funzioni mb_string dev'essere caricato (se sei su windows) oppure installato e caricato (se sei su linux/unix) il modulo mb_string, la ritenevo una cosa scontata (forse sbagliando ma finora non ho ancora trovato un host che non lo mette a disposizione).

io ne ho girati parecchi e principalmente quelli windows based non la offrono, quelli *nix/*bsd è facile che la includano

Parlando di un tema molto generale (cioè non sappiamo a che lingua si riferisce lilo) ho preferito tirare in ballo direttamente utf8 che ci consente di gestire tutti i caratteri, anche quelli non rappresentabili con la tabella ASCII (normale o estesa) o per mezzo delle entità HTML.

anch'io sto consigliando di usare utf8

A questo punto le considerazioni che hai fatto sui template perdono senso. Se ti basta sfruttare le entità html e carattery single-byte allora cosa te ne fai di utf8?
Non è detto che utf8 serva solo per quello che riceviamo in input dagli utenti, anche il resto potrebbe aver bisogno di essere muti-byte.
Inoltre io ritengo che se si imposta UTF-8 sia inutile codificare con le entità HTML caratteri che sono già presenti e fruibili nel set di caratteri che utilizziamo.

UTF8 è multibyte solo per i caratteri necessari ... di conseguenza è normalissimo che il resto dei caratteri siano single-byte ^^
L'utilizzo di entità html serve per avere il codice php portabile, nel senso che se non è presente l'estensione il tutto funzioni lo stesso

ma purtroppo non è vero che con ASCII e le entità HTML puoi predisporre per QUALSIASI codifica e quindi torniamo al punto di cui sopra.

Quindi come si deduce non è vero che tutto il resto non è importante e non è vero che "fa differenza SOLTANTO come vengono salvati nel db".

non voglio parlare per teorie ipotetiche che riguardano lo 0.00000000000000000001% di possibilità ... quante volte ti è capitato di dover rappresentare caratteri non rappresentabili con le entità html? a me, sinceramente, nessuna ... o per lo meno per adesso non me ne vengono in mente

Mi pare una visione un po' riduttiva delle funzioni di utf8.
Utf-8 va utilizzato per rappresentare tutti i caratteri che diversamente non sarebbero rappresentabili e/o sarebbero rappresentati in modo differente tra differenti set di caratteri.
Inoltre non sono d'accordo sul fatto che non serve fare ASSOLUTAMENTE NULLA. E' proprio facendo ASSOLUTAMENTE NULLA (limitandosi ad impostare il content encoding) che alla fine ci si ritrova con i punti di domanda o con caratteri imprevisti.
Impostare UTF8 come encoding prevede che si vada in output con utf8 e per essere sicuri di farlo sempre è utile utilizzare le funzioni di conversione. Chiaramente non è sempre indispensabile, tanto più quanto si ritiene che utf8 non è indispensabile ed alla fin fine è "una cosa in più".

se prendi le frasi a se stanti è normale che capisci poi quello che vuoi ... io ho ben specificato che inviando i dati utilizzando le entità html nel codice html inviato le uniche parti "sensibili" alla codifica sarebberò stati quelle provenienti dal database, sempre se queste non vengono elaborate prima o dopo l'acquisizione, e che quindi la codifica interessa solo quei dati

e normale che se ho i dati in un modo, nel db li ho in un'altro e apache, di default, specifica che il content-encoding è ancora in un'altra codifica ... succede un casino