2011-10-22 35 views
21

Non sono sicuro quando questo si è verificato.Strani caratteri nel testo del database: Ã, Ã, ¢, â, €,

Ho un nuovo sito Web affiliato di drop-shipping e ricevo una copia esportata del catalogo prodotti dal grossista. Formattare e importare questo in Prestashop 1.4.4.

Il front end del sito contiene le combinazioni di caratteri strani all'interno del testo prodotto: A, A, ¢, Â, ecc Essi appaiono al posto dei caratteri comuni come, -: ecc

Questi personaggi sono presenti in circa il 40% delle tabelle del database, non solo tabelle specifiche del prodotto come ps_product_lang.

Another website thread dice questo stesso problema si verifica quando la stringa di connessione al database utilizza un tipo di codifica di carattere errato.

In /config/setting.inc, non vi è alcuna stringa di codifica dei caratteri menzionata, solo il motore MySQL, che è impostato su InnoDB, che corrisponde a quello che vedo in PHPMyAdmin.

Ho esportato ps_product_lang, sostituito tutte le istanze di questi caratteri con caratteri corretti, salvato il file CSV in formato UTF-8 e reimportato utilizzando PHPMyAdmin, specificando UTF-8 come lingua.

Tuttavia, dopo aver eseguito una nuova ricerca in PHPMyAdmin, ora ho circa 10 volte il numero di istanze di questi caratteri errati in ps_product_lang rispetto a quando ho iniziato.

Se il problema è semplice come specificare l'attributo di lingua corretto nella stringa di connessione del database, dove/come si imposta questo e cosa?

Per inciso, ho cercato di eseguire questo comando in phpMyAdmin menzionato in this thread, ma il problema rimane:

SET NAMES utf8 

UPDATE: PHPMyAdmin dice:

MySQL charset: Unicode UTF-8 (utf8)

Questo è lo stesso set di caratteri che ho usato nell'ultimo file di importazione, che ha causato più corruzioni di caratteri. UTF-8 è stato specificato come set di caratteri del file di importazione durante il processo di importazione.

UPDATE2

Ecco un esempio:

le persone vivono untetheredÃÆ'Ã, ¢ à¢ à ¢ â,¬Å¡Ã,¬Ã¯à ¢ â , € Ã,ï † acquistare e noleggiare film online, scaricare software e condividere e archiviare file sul web.

Update3

ho eseguito un comando SQL in phpMyAdmin per visualizzare i set di caratteri:

  • character_set_client utf8
  • character_set_connection utf8
  • character_set_database latin1
  • character_set_filesystem binario
  • character_set_results utf8
  • character_set_server latin1
  • character_set_system utf8

Così, forse il mio database deve essere convertito (o eliminati e ricreati) a UTF-8. Questo potrebbe rappresentare un problema se il server MySQL è latin1?

MySQL può gestire la traduzione del contenuto in UTF8 ma memorizzarlo come latin1? Non penso che possa farlo, dato che UTF8 è un superset di latin1. Il mio supporto di web hosting non ha risposto in 48 ore. Potrebbe essere troppo difficile per loro.

+0

@AurelioDeRosa Esempio aggiunto sopra. – Steve

+0

Non so molto di prestashop ma sembra che non faccia una buona codifica del char. Comunque vedo altre persone hanno lo stesso problema: http://www.prestashop.com/forums/topic/34545-problem-with-encoding-characters/ –

+0

non è questo solo un problema di FE? phpMyAdmin è impostato per visualizzare roba con codifica errata e client non impostato per utilizzare UTF-8? deve essere inserito in un meta tag. – MarianP

risposta

5

Questo è sicuramente un problema di codifica. Hai una codifica diversa nel tuo database e nel tuo sito web e questo fatto è la causa del problema. Inoltre, se hai eseguito quel comando, devi modificare i record già presenti nelle tue tabelle per convertire quei caratteri in UTF-8.

Aggiornamento: in base all'ultimo commento, il nocciolo del problema è che si dispone di un database e un'origine dati (il file CSV) che utilizzano codifica diversa. Quindi puoi convertire il tuo database in UTF-8 o, almeno, quando ottieni i dati nel CSV, devi convertirli da UTF-8 a latin1.

si può fare la conversione seguente questo articolo:

+0

Ok. Date un'occhiata a quanto segue: http://www.bluebox.net/news/2009/07/mysql_encoding – Steve

+0

si prega di consultare l'aggiornamento alla domanda originale. – Steve

15

Se il set di caratteri delle tabelle è lo stesso che si tratta di provare contenuti da utilizzare mysql_set_charset('UTF8', $link_identifier). Si noti che MySQL utilizza UTF8 per specificare la codifica UTF-8 anziché UTF-8, che è più comune.

Controllare my other answer anche su una domanda simile.

+0

Come potete vedere qui (http://en.wikipedia.org/wiki/UTF-8) il nome ** reale ** è UTF-8. Ma, naturalmente, nella dichiarazione potrebbe essere senza il trattino. –

+0

@AurelioDeRosa Lo so, ma è MySQL che ha rovinato tutto: P non io ... – AlexV

+0

So amico, non preoccuparti. È solo per chiarire. Infatti, come puoi vedere asserisco "nella dichiarazione potrebbe essere senza il trattino". I migliori saluti. –

0

L'errore di solito viene introdotto durante la creazione di CSV. Prova a usare Linux per salvare il CSV come TextCSV. Libre Office in Ubuntu può far rispettare la codifica per essere UTF-8, ha funzionato per me. Ho sprecato un sacco di tempo a provarlo su Mac OS. Linux è la chiave. Ho provato su Ubuntu.

Good Luck

2

Applicare queste due cose.

  1. è necessario impostare il set di caratteri del database per essere utf8.

  2. È necessario chiamare il mysql_set_charset('utf8') nel file in cui hai fatto il collegamento con il database e subito dopo la selezione di dati come mysql_select_db utilizzare il mysql_set_charset. Ciò ti consentirà di aggiungere e recuperare i dati correttamente in qualunque lingua.

1

Questo sembra essere un problema di codifica UTF-8 che potrebbe essere stato causato da un doppio UTF8-codifica del contenuto del file di database.

Questa situazione potrebbe verificarsi a causa di fattori come il set di caratteri che era o non è stato selezionato (ad esempio quando è stato creato un file di backup del database) e il file di formato e il file di database di codifica è stato salvato con.

ho visto questi strani caratteri UTF-8 nel seguente scenario (la descrizione non può essere del tutto accurato come ho più accesso al database in questione):

  • Se ricordo bene, c'è la il database e le tabelle avevano una collazione "uft8_general_ci".
  • Il backup è fatto del database.
  • Il file di backup viene aperto su Windows in formato file UNIX e con codifica ANSI.
  • Il database viene ripristinato su un nuovo server MySQL copiando il contenuto dal file di backup del database in phpMyAdmin.

Guardando il contenuto del file:

  • L'apertura del file di backup di SQL in un editor di testo mostra che il file di backup di SQL ha caratteri strani come ad esempio "sà¥". In una nota a margine, potresti ottenere risultati diversi se apri lo stesso file in un altro editor. Io uso TextPad qui ma aprendo lo stesso file in SublimeText ho detto "sÃ" perché SublimeText ha correttamente codificato UTF8 - comunque, questo è un po 'confuso quando si inizia a provare a risolvere il problema in PHP perché non si vede il dati giusti in SublimeText all'inizio. Ad ogni modo, ciò può essere risolto prendendo nota di quale codifica viene utilizzata dall'editor di testo durante la presentazione del contenuto del file.
  • Gli strani caratteri sono caratteri UTF-8 a doppia codifica, quindi nel mio caso la prima parte "Ã" equivale a "Ã" e " ¥" = "¥" (questa è la mia prima "codifica"). I caratteri "à ¥" sono uguali al carattere UTF-8 per "å" (questa è la mia seconda codifica).

Così, il problema è che "false" (UTF8-encoded due volte) utf-8 deve essere riconvertito in utf-8 "corretto" (solo UTF8-encoded volta).

Cercando di risolvere questo problema in PHP si rivela essere un po 'impegnativo:

utf8_decode() non è in grado di elaborare i caratteri.

// Fails silently (as in - nothing is output) 
$str = "så"; 

$str = utf8_decode($str); 
printf("\n%s", $str); 

$str = utf8_decode($str); 
printf("\n%s", $str); 

iconv() non riesce con "Avviso: iconv(): Rilevato un carattere non valido nella stringa di input".

echo iconv("UTF-8", "ISO-8859-1", "så"); 

Un'altra fine and possible solution fallisce silenziosamente anche in questo scenario

$str = "så"; 
echo html_entity_decode(htmlentities($str, ENT_QUOTES, 'UTF-8'), ENT_QUOTES , 'ISO-8859-15'); 

mb_convert_encoding() in silenzio: #

$str = "så"; 
echo mb_convert_encoding($str, 'ISO-8859-15', 'UTF-8'); 
// (No output) 

Cercando di risolvere la codifica in MySQL da converting the MySQL database characterset and collation to UTF-8 era senza successo:

ALTER DATABASE myDatabase CHARACTER SET utf8 COLLATE utf8_unicode_ci; 
ALTER TABLE myTable CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; 

Vedo un paio di modi per risolvere questo problema.

Il primo è eseguire un backup con la codifica corretta (la codifica deve corrispondere al database effettivo e alla codifica della tabella). È possibile verificare la codifica semplicemente aprendo il file SQL risultante in un editor di testo.

L'altro è per sostituire caratteri con codifica UTF8 doppia con caratteri con codifica UTF8 singola. Questo può essere fatto manualmente in un editor di testo. Per aiutare in questo processo, è possibile selezionare manualmente caratteri errati da Prova UTF-8 Encoding Debugging Chart (potrebbe essere una questione di sostituire 5-10 errori).

Infine, uno script può aiutare nel processo:

$str = "så"; 
    // The two arrays can also be generated by double-encoding values in the first array and single-encoding values in the second array. 
    $str = str_replace(["Ã","Â¥"], ["Ã","¥"], $str); 
    $str = utf8_decode($str); 
    echo $str; 
    // Output: "så" (correct) 
0

ho incontrato oggi un bel problema simile: mysqldump scaricato le mie codifica UTF-8 base di caratteri UTF-8 diacritici come due caratteri latin1, anche se il file è di per sé regolare utf8.

Ad esempio: "é" è stato codificato come due caratteri "Ã ©". Questi due caratteri corrispondono alla codifica utf8 a due byte della lettera, ma dovrebbe essere interpretata come un singolo carattere.

Per risolvere il problema e importare correttamente il database su un altro server, ho dovuto convertire il file usando ftfy (acronimo di "Correzioni testo per te)." (https://github.com/LuminosoInsight/python-ftfy) libreria python La libreria fa esattamente quello che mi aspetto: trasformare male codificato UTF-8 per codificare correttamente utf-8

ad esempio:. Questa combinazione latin1 "Ã ©" si trasforma in una "e"

ftfy viene fornito con uno script da riga di comando, ma trasforma il. file in modo che non possa essere importato di nuovo in mysql.

Ho scritto uno script python3 per fare il trucco:

#!/usr/bin/python3 
# coding: utf-8 

import ftfy 

# Set input_file 
input_file = open('mysql.utf8.bad.dump', 'r', encoding="utf-8") 
# Set output file 
output_file = open ('mysql.utf8.good.dump', 'w') 

# Create fixed output stream 
stream = ftfy.fix_file(
    input_file, 
    encoding=None, 
    fix_entities='auto', 
    remove_terminal_escapes=False, 
    fix_encoding=True, 
    fix_latin_ligatures=False, 
    fix_character_width=False, 
    uncurl_quotes=False, 
    fix_line_breaks=False, 
    fix_surrogates=False, 
    remove_control_chars=False, 
    remove_bom=False, 
    normalization='NFC' 
) 

# Save stream to output file 
stream_iterator = iter(stream) 
while stream_iterator: 
    try: 
     line = next(stream_iterator) 
     output_file.write(line) 
    except StopIteration: 
     break 
Problemi correlati