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

    Che charset usa il mio database?

    Come faccio a sapere se il DB del mio forum è in formato ISO-8859-1 o UTF-8 ?


    Lo chiedo perchè nel backup del DB ci sono frasi come queste:

    "il tutto NON è stato un caso ma mi è capitato spessisimo"
    "non funziona più"
    "Mi ero giàiscritto a dicembre"

    Ecc...

    Però se controllo la tabella dei messaggi nel phpmyadmin, le stesse frasi sono riportate in questo modo:

    "il tutto NON è stato un caso ma mi è capitato spessisimo"
    "non funziona più"
    "Mi ero già iscritto a dicembre"


    Sinceramente non so perchè ciò accade... riuscite a spiegarmelo?

    Grazie.

  2. #2
    Questa è una doppia codifica in utf8, come ci sei arrivato non lo so. I due casi tipici sono:
    [list=1][*]utf8_encode() su una stringa già UTF-8[*]la doppia applicazione di utf8_encode() su una stringa Latin1[/list=1]

  3. #3
    Credo sia la seconda ipotesi. Comunque all'apertura del PHPMyAdmin compare accanto a charset la stringa UTF-8 Unicode (utf8), (che non avevo visto!), quindi a questo punto sono sicuro che il database del mio hosting (TOL.it) abbia il formato UTF-8.

    Però...

    ...controllando nel backup del db, tra le prime righe c'è scritto
    CREATE DATABASE `nomedb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

    Perchè??? Se ho constatato che il database ha come charset UTF-8, perchè poi quando lo esporto, nel file del backup mi compare latin1_swedish_ci ?

    Ecco perchè cambiano le lettere accentate tra il DB e il suo backup... vero?
    Se è così, come risolvo questo problema?

    C'è da dire anche che questo problema me lo porto dietro dall'ultimo trasferimento del dominio... forse c'entra qualcosa...

  4. #4
    Le nubi si diradano. Sì, quello è il problema, è la terza ipotesi ossia:

    3. Registrazione in UTF8 su database Latin1

    Le uniche due cose che mi vengono in mente è che accedi con phpMyAdmin ad un database diverso (può sembrare banale ma può capitare) oppure stai leggendo un backup vecchio (bè, può capitare anche questo). Se hai sempre avuto l'encoding a UTF-8, queste ipotesi sono scartabili.

    Un'altra ipotesi, anche questa plausibile, è un baco nell'esportazione di phpMyAdmin. Io uso la 2.11.1 ed esporta correttamente in UTF-8. A proposito, il backup lo fai con phpMyAdmin?

    Un'ultima avviso: visto che hai cambiato assicurati di avere una versione relativamente recente di MySql. Nei meandri della mia memoria parvemi ricordare che la versione 4.0/4.1 aveva grossi problemi di gestione encodings.

  5. #5
    Tralasciando un paio di trasferimenti di dominio che ho fatto con relative esportazioni e importazioni del backup del database, cerco di farti(vi) capire meglio la situazione:

    Ho un forum su TOL il cui database ha codifica UTF-8.
    Qualche mese fa è stato hackerato e nello stesso giorno esportai il database dal PHPMyAdmin (il db non era stato toccato dall'hacker).
    Ora lo stesso backup, dopo aver ripristinato il sito, lo importai nuovamente tramite il PHPMyAdmin.
    Risultato: forum con strani caratteri al posto delle lettere accentate!

    Però cambiando opportunamente alcune righe di codice nel sito (uso SMF per il forum e ho aggiunto UTF-8 come codifica nell'index; di default c'era ISO-8859-1) riesco a far visualizzare correttamente le lettere accentate.

    ...Però resta qualche problema di visualizzazione in alcuni messaggi, nelle email ecc...

    Ecco perchè ora vorrei capirci di più, cioè vorrei risolvere il problema a monte, senza modificare ulteriormente il codice del forum, e capire esattamente qual è il problema!

  6. #6
    L'UTF-8 che vedi all'apertura del phpMyAdmin è l'encoding della connessione (le query e le risposte), che è diverso dall'encoding usato dal tuo database.

    Entra nel file sql che devi importare e cambia manualmente in:

    codice:
    CREATE DATABASE `nomedb` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
    Questo setta il default degli encoding del database nomedb, ma devi controllare anche gli encodings dei singoli campi di testo, per esempio:

    codice:
    ... `Codice` varchar(30) CHARACTER SET latin1 COLLATE latin1_swedish_ci ...
    deve diventare:

    codice:
    ... `Codice` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin ...
    Alla fine non ci deve essere la stringa 'latin1' in tutto il file sql. Fatto questo, elimina il vecchio database e importa quello nuovo.

    Controllando SMF, inoltre:
    http://docs.simplemachines.org/index...ic=865.msg1894

    Segui scrupolosamente le loro indicazioni. Purtroppo il problema del tuo problema è che non è circoscritto...

  7. #7
    Prima di seguire le tue indicazioni... una domanda: e se volessi tutto nel formato ISO-8859-1 ?
    Voglio dire, prima dell'attacco hacker avevo SMF nel formato ISO-8859-1 e il database nel formato ISO-8859-1 e tutto andava bene.
    Ora non capisco perchè tra un import e un esport che ho fatto non posso più riportare la situazione allo stato precedente l'attacco hacker.
    Eppure l'hosting è lo stesso!

    Prima dell'attacco hacker avevo il forum installato correttamente e nessun problema con le lettere accentate. Come ritornare a quella situazione?

    Ci deve essere un modo per "convertire" il backup del database e successivamente importarlo in maniera corretta nel PHPMyAdmin, in modo da avere il forum come avevo prima.
    Ma qual è questo modo?

    Prima non usavo l'UTF-8 e da quanto ho letto in giro non conviene nemmeno usarlo...

  8. #8
    A mio parere per avere un sito "duraturo ed elastico" CONVIENE usare l'utf8: se facevi un sito in Latin1 nel 2000 dopo l'entrata dell'euro (che aggiunge un simbolo grafico abbastanza importante) il tuo sito è già vecchio.

    Nel tuo caso specifico però hai ragione: riporterei tutto in ISO-8859-1 (Latin1), anche perché non so se effettivamente SMF supporta correttamente l'utf8.

    Il tuo problema è che probabilmente hai l'encoding della connessione (quella che vedi nella prima pagina di phpMyAdmin) in UTF8, e questa opzione puoi cambiarla solo configurando il mysql, cosa che di solito i webhosting non ti lasciano fare. Puoi chiedere a TOL.it se possono cambiare questa opzione per il tuo dominio (soluzione ottimale) oppure puoi settarla tu con un comando SQL da PHP subito dopo l'apertura della connessione (soluzione schifosa):

    Codice PHP:
    mysql_query('SET CHARACTER SET latin1'); 

  9. #9
    Originariamente inviato da ntd
    Il tuo problema è che probabilmente hai l'encoding della connessione (quella che vedi nella prima pagina di phpMyAdmin) in UTF8, e questa opzione puoi cambiarla solo configurando il mysql, ...
    Questa cosa mi interessa, come si fa? Io ho un VPS...
    Ciao!

  10. #10
    Non so cos'è un VPS, però per cambiare l'encoding di default bisogna modificare "my.cnf", il file di configurazione di MySQL, aggiungendo le seguenti 2 linee di codice:

    codice:
    [client]
    ...
    default-character-set=latin1
    
    [mysqld]
    ...
    default-character-set=latin1
    e far ripartire il server. Tieni presente che questa è la configurazione di default cioè, a meno di non avere 'default-character-set=utf8' da qualche parte, il server già dovrebbe colloquiare in latin1 per default. Per controllare fisicamente la configurazione del tuo server, puoi selezionare il comando "Show MySQL system variables" (o l'equivalente in italiano) nella pagina principale di phpMyAdmin. Se hai i seguenti risultati:

    codice:
    ...
    character set client: utf8
    (Global value): latin1
    character set connection: utf8
    (Global value): latin1
    ...
    character set results: utf8
    (Global value): latin1
    ...
    il tuo server è già latin1 per default. Le impostazioni di default vengono sovrascritti da phpMyAdmin che recentemente usa una connessione utf8 per default ma se la tua applicazione non sovrascrive niente la connessione sarà Latin1.

    Per farla breve, se ottieni quanto sopra (o qualcosa di equivalente), il problema non è MySql ma la configurazione di SMF. Se, per fare un esempio, durante la ripubblicazione del forum hai anche aggiornato SMF considera l'opzione di rimettere la vecchia versione.

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.