Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 19
  1. #1

    gestione caratteri accentati

    sto impazzendo..

    in una tabella di un db mysql ho la parola "caffè".

    recupero la variabile che mi contiene tutte i record che mi interessano (tra cui caffè):
    codice:
    $variabile = htmlentities($row[nomecampo]);
    le visualizzo tutte in questo modo:
    codice:
    <?=$variabile?>
    il problema è: se visualizzo il codice della pagina (tramite browser) vedo i caratteri accentati sostituiti con i rispettivi html (è con &egreve. Quando passo il link alla pagina successiva e recupero var

    $var = $_GET[var];

    mi torna questa parola: Caffè

    perchè non mi passa la variabile con i caratteri html?!


  2. #2
    Utente di HTML.it L'avatar di Il_Drugo
    Registrato dal
    May 2006
    Messaggi
    1,220
    prova togliendo l'htmlentities quando recuperi dal DB.

    Per il secondo errore credo sia dovuto ad un'erronea interpretazione dei caratteri nella querystring (durante il trasferimento in GET).

    In teoria risolvendo il primo problemi scompare anche il secondo.


  3. #3
    Originariamente inviato da Il_Drugo
    prova togliendo l'htmlentities quando recuperi dal DB.

    Per il secondo errore credo sia dovuto ad un'erronea interpretazione dei caratteri nella querystring (durante il trasferimento in GET).

    In teoria risolvendo il primo problemi scompare anche il secondo.

    se tolgo l'htmlentities vedo :

    in visualizzazione il carattere giusto (è)
    nel codice generato dal browser lo vedo normale (è), non più in html (&egreve
    nella pagina successiva è ancora come prima: Caffè




    EDIT:stesso identico problema con la "ì" che diventa "ì"

  4. #4
    Utente di HTML.it L'avatar di thitan
    Registrato dal
    Feb 2001
    Messaggi
    716
    io uso $var=addslashes($var) quando recupero il valore dal post/get, prima di salvarlo nel db, poi una volta salvato e recuperato $var=stripslashes($var) prima di stamparlo a video..funziona..
    se nò mi ricordo di htmlspecialchars() ma dava problemi, mi pare, con gli apici..

    www.inter-rail.it
    travellers, not tourist
    Is cuma cá mhinice a théann tú ar strae; is é is tábhachtaí gurb áil leat do bhealach a aimsiú arís.

  5. #5
    Utente di HTML.it L'avatar di Il_Drugo
    Registrato dal
    May 2006
    Messaggi
    1,220
    l'addslashes dovrebbe aiutare solo con gli apici...almeno a quanto sapevo. Se cosi fosse non risolverebbe il problema.

    prova con url_encode. In teoria è fatto apposta per evitare storpiature dei caratteri strani in GET. Ovviamente poi lo riprendi con url_decode.

  6. #6
    Utente di HTML.it L'avatar di thitan
    Registrato dal
    Feb 2001
    Messaggi
    716
    no no addslashes/stripslashes funziona anche con gli accentati ho appena provato..non sò il come però funziona

    www.inter-rail.it
    travellers, not tourist
    Is cuma cá mhinice a théann tú ar strae; is é is tábhachtaí gurb áil leat do bhealach a aimsiú arís.

  7. #7
    Originariamente inviato da thitan
    no no addslashes/stripslashes funziona anche con gli accentati ho appena provato..non sò il come però funziona
    tu dici di mettere una "/" dopo la stringa dentro il db e toglierla quando la recupero?!

    il problema me lo crea il fatto che riscrivo l'url con .htaccess e le "/" me le mangia nel passaggio pagina pagina...

  8. #8
    vorrei capire teoricamente come si fa:

    cioè devo inserire nel sb il carattere direttamente in html (&egrave

    devo recuperarlo con qualche funzione?!

    quello che poi mi mette la pulce nell'orecchio è che, nonostante la visualizzazione del carattere sia totalmente sbagliata, la query me la fa giustautilizzando la parola visualizzata male.....


  9. #9
    nessuno mi può aiutare?!

  10. #10
    uppo l'ulitma volta ... nessuno ha mai avuto questo problema?!

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.