Problema lettere accentate

Printable View

22-07-2019, 13.04.36
dampyr

Problema lettere accentate

Salve, sto realizzando delle pagine PHP con Notepad++ e, non avendo ancora implementato un pannello di amministrazione per browser, sto inserendo i valori delle variabili direttamente nelle tabelle del database di Altervista.
Mi succede che su browser le lettere accentate (che continuo a vedere bene nelle celle della tabella del db) si vedano male, sostituite dal noto "carattere" di punto interrogativo dentro un rombo nero.
Le pagine hanno <!doctype html> e <meta charset="utf-8">, immagino di dover sistemare la codifica caratteri del database, ma con cosa di preciso? Attualmente è, predefinito, latin1_swedish_ci, ma di utf-8 ce ne sono svariati e vorrei assicurarmi che i testi si vedano bene sempre...

Altre tabelle di db nello stesso sito non hanno problemi con latin1_swedish_ci, ma in quel caso passo i valori delle variabili attraverso un pannello di amministrazione da browser...

C'è un modo per risolvere?
22-07-2019, 14.05.25
dreadnaut
Premetto che il mio sito usa UTF-8 ovunque, eppure phpMyAdmin (via pannello di AlterVista) mi mostra alcuni caratteri sbagliati, quindi ho ancora qualcosa impostato incorrettamente.

La faccenda encoding è complessa, e ci sono diversi punti in cui le cose possono andare storte. Per avere un sito UTF-8 da cima a fondo devi:
- configurare il tuo editor di testo per salvare UTF-8; alcuni usano ancora ISO-8859-1 / Windows-1252 come default
- caricare i file con un client FTP che rispetti l'encoding, oppure in modalità binaria (io uso PHPloy e via)
- gestire le stringhe con le necessarie funzioni per gli encoding multibyte (al contrario delle funzioni ASCII, dove un byte è sempre un carattere)
- impostare l'encoding corretto nella connessione al database, che al giorno d'oggi è utf8mb4
  
  Codice PHP:
  
  $pdo = new PDO( 'mysql:host=localhost;dbname=my_dampyr;charset=utf8mb4', 'dampyr', '' );
- se vuoi ordinare o cercare o elaborare testo nel database, usare la "collation" corretta per le tabelle o le colonne in questione; puoi usare utf8mb4_unicode_ci, o in rari casi utf8mb4_general_ci.
- assicurarti che le tue pagine e risorse vengano ritornate dal server con il corretto encoding; con uno o più di questi metodi:
  1. settare il default per tutto, via .htaccess con
    
    Codice:
    
    AddDefaultCharset utf-8
  2. nell'HEAD delle pagine html puoi usare
    
    Codice HTML:
    
    <meta charset="utf-8" />
  3. via php
    
    Codice PHP:
    
    header('Content-Type: ...; charset=utf-8');
Se ricordo bene, ottieni il � quando hai carattere utf-8 ad un certo punto viene convertito in ISO-8859-x; al contrario, ti ritrovi con delle Ã accentate, seguite da un altro simbolo.

Nota: una "collation" è una serie di regole per l'ordinamento e l'elaborazione del testo, che permettono a MySQL di elaborare i dati in quelle colonne nel modo corrispondente ad un encoding; non è l'encoding dei dati stessi, quindi modificarlo non cambia il contenuto della tabella. Questo è spesso fonte di confusione.
22-07-2019, 14.41.04
dampyr

Grazie per la ricca risposta, non credevo ci fossero tutti questi "vincoli", per anni ho usato ISO-8859-1... A volersi aggiornare/uniformare c'è sempre da perderci. :cry:

Comunque io salvo i file .php con UTF-8 senza BOM (la versione UTF-8 è sconsigliata in PHP poiché inserisce un carattere non visibile che "sballa" il file), e uso il pannello di Altervista per caricare i contenuti sul sito.
Ignoravo la necessità di impostare l'encoding all'atto di connettersi al database (semplicemente non c'erano mai stati problemi in precedenza per pormi il dubbio e scoprirlo).

Domanda: c'è differenza tra <meta charset="utf-8"> e <meta encoding="utf-8">?
22-07-2019, 14.52.18
dreadnaut

Citazione:

Originalmente inviato da dampyr

Grazie per la ricca risposta, non credevo ci fossero tutti questi "vincoli", per anni ho usato ISO-8859-1... A volersi aggiornare/uniformare c'è sempre da perderci. :cry:

No no, hai fatto benissimo! Il passaggio non è indolore, ma UTF-8 rende la vita più facile per tutti: guadagni un sacco di simboli utili, gestisci nomi stranieri senza problemi, supporti emoji, puoi interfacciarti con servizi esterni, etc.

Citazione:

Originalmente inviato da dampyr

Ignoravo la necessità di impostare l'encoding all'atto di connettersi al database (semplicemente non c'erano mai stati problemi in precedenza per pormi il dubbio e scoprirlo).

Occhio che se hai già dei dati "ISO-8859" nel database, non c'è conversione automatica ad UTF-8. Cambiare collation non ha quell'effetto. Devi esportare il database, convertire l'encoding del file .sql, assicurarti che sia tutto OK, poi ricaricare i dati così modificati. Ho giusto fatto una conversione simile un paio di mesi fa, e facendo tutto con calma ed attenzione c'è voluto quasi un pomeriggio intero. Ma si fa, mi spiace non aver preso più appunti quel giorno, o li avrei postati.

Citazione:

Originalmente inviato da dampyr

Domanda: c'è differenza tra <meta charset="utf-8"> e <meta encoding="utf-8">?

La differenza è che "charset" è quello giusto, ed "encoding" quello sbagliato :mrgreen: Colpa mia, ho corretto il post sopra!

[edit] suggerisco anche FileZilla per caricare pagine e file!
22-07-2019, 16.40.58
dampyr

Ho verificato che la collation di connessione al server è utf8mb4_general_ci, cosa suggerisci di fare?
Nel database avevo tutti dati latin1_swedish_ci, che è la codifica predefinita su Altervista, idem per i file creati con Notepad++, dove ho impostato da tempo il formato UTF-8-BOM.
22-07-2019, 17.48.28
dreadnaut

Quindi le pagine sono UTF-8, ti colleghi al database UTF-8, i dati nel database sono UTF-8 (perché le pagine che ce li mandavano erano UTF-8 dall'inizio) e tutto fila liscio a parte quando inserisci lettere accentate via phpMyAdmin?

Se siamo in questa situazione, è simmetrica alla mia. Suggerirei di lasciare le cose come stanno e lavorare sull'area amministrativa. Nel momento in cui puoi evitare phpMyAdmin, dovresti essere a posto.

Come prova per le pagine, puoi provare a cambiare il "PUBBLICITA'" in "PUBBLICITÀ" ed assicurarti che la À appaia correttamente.
22-07-2019, 19.42.31
dampyr

Citazione:

Originalmente inviato da dreadnaut

Se siamo in questa situazione, è simmetrica alla mia. Suggerirei di lasciare le cose come stanno e lavorare sull'area amministrativa. Nel momento in cui puoi evitare phpMyAdmin, dovresti essere a posto.

Sì, di solito uso phpMyAdmin solo per creare i campi delle variabili (mai avuto simpatia per i comandi da console :mrgreen: anche se preferisco creare pagine web lavorando sul codice e non in visuale), quindi allestendo le pagine amministrative, dovrei bypassare il problema senza troppi ulteriori intoppi.
23-07-2019, 09.21.14
alemoppo

Potete provare come indicato qui? Io non ho trovato problemi con phpMyAdmin.

Ciao!
23-07-2019, 10.23.34
dreadnaut

Aggiungere charset=utf8mb4 in fondo alla stringa di connessione, come in

Codice PHP:

$pdo = new PDO( 'mysql:host=localhost;dbname=my_dampyr;charset=utf8mb4', 'dampyr', '' );

dovrebbe avere lo stesso effetto, visto che equivale a:

Codice:

SET character_set_client = utf8mb4; SET character_set_connection = utf8mb4; SET character_set_results = utf8mb4;

Aggiornamento

Ecco, mistero semi-spiegato! MySQL su AlterVista sembra ignorare il parametro "charset=...", ma eseguire le tre query sopra funziona.

Nel dettaglio, questo funziona in locale (MySQL 5.7 / PHP 7.2 / mysql_nd 5.0.12) ma non su AlterVista (MySQL 5.6 / PHP 7.1 / mysql_nd 5.0.12)

Codice PHP:

$pdo = new PDO('mysql:host=127.0.0.1;db_name=my_dreadnaut;charset=utf8mb4', 'dreadnaut', '');

Così come questo:

Codice PHP:

$pdo = new PDO( 'mysql:host=127.0.0.1;db_name=my_dreadnaut;charset=utf8mb4', 'dreadnaut', '', [ PDO::MYSQL_ATTR_INIT_COMMAND => "SET character_set_results = 'utf8mb4';" ] );

L'unica soluzione sembra essere cambiare il charset in un passo separato:

Codice PHP:

$pdo = new PDO('mysql:host=127.0.0.1;db_name=my_dreadnaut'; 'dreadnaut', ''); $pdo->exec(<<<FINE SET character_set_client = 'utf8mb4'; SET character_set_connection = 'utf8mb4'; SET character_set_results = 'utf8mb4'; FINE );
23-07-2019, 18.57.16
alemoppo

Citazione:

Originalmente inviato da dreadnaut

Ecco, mistero semi-spiegato! MySQL su AlterVista sembra ignorare il parametro "charset=...", ma eseguire le tre query sopra funziona.

Sì, ne ero a conoscenza, ma la mia spiegazione ai tempi è stata questa. Se però altrove funziona, dovrei re-indagare.

Ciao!