Problema lettere accentate

**dampyr** · 22-07-2019, 13.04.36

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?

**dreadnaut** · 22-07-2019, 14.05.25

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.

**dampyr** · 22-07-2019, 14.41.04

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.

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">?

**dreadnaut** · 22-07-2019, 14.52.18

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.

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.

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.

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

Colpa mia, ho corretto il post sopra!

[edit] suggerisco anche FileZilla per caricare pagine e file!

**dampyr** · 22-07-2019, 16.40.58

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.

**dreadnaut** · 22-07-2019, 17.48.28

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.

**dampyr** · 22-07-2019, 19.42.31

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

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.

**alemoppo** · 23-07-2019, 09.21.14

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

Ciao!

**dreadnaut** · 23-07-2019, 10.23.34

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
);

**alemoppo** · 23-07-2019, 18.57.16

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!

Discussione: Problema lettere accentate

LinkBack

Strumenti discussione

Display

Problema lettere accentate

Regole di scrittura