Home › Forum › Amministrazione WP › sql e decodifica caratteri
-
AutorePost
-
-
2 Ottobre 2006 alle 12:43 #2217uziPartecipante
ho pasticciato parecchio con il mio blog e solo ora mi sono accorto che dopo vari trasferimenti alcuni post con caratteri accentati sono andati a ramengo.
ho da sempre impostato la codifica iso-8859-15, ma probabilmente in qualche frangente ho incasinato un po’ le cose. ora mi ritrovo con un database con alcuni post incasinati, siccome cambiare la codifica mi sembra inopportuno, ho pensato che sarebbe più semplice e rapido sostituire i caratteri incriminati. Ho solo un problema: la mia totale ignoranza in campo mysql (non solo quello, vabbè).
cosi vi chiedo: c’è qualche anima pia che mi passa la query sql per sostituire i caratteri incriminati con l’equivalente html?
-
3 Ottobre 2006 alle 16:32 #40384SteveAglAmministratore del forum
Premesso che ti consiglio di fare una copia della tabella dei Post nel caso qualcosa andasse storto, qualche volta ho risolto con queste query.
Queste potebbero funzionare nel convertire da UTF-8 a ISO-8859-15.
UPDATE wp_posts SET post_content = REPLACE(post_content,'àƒÂ©','é');
UPDATE wp_posts SET post_content = REPLACE(post_content,'àƒÂ¨','è');
UPDATE wp_posts SET post_content = REPLACE(post_content,'àƒÂ¬','à¬');
UPDATE wp_posts SET post_content = REPLACE(post_content,'àƒÂ²','ò');
UPDATE wp_posts SET post_content = REPLACE(post_content,'àƒÂ¹','ù');
ma ti avviso che i caratteri potrebbero non essere gli stessi e si potrebbe incasinare tutto ancora di più.
Manca la
à
che convertita in UTF-8 si trasforma inàƒ
.Dopo
àƒ
sembra esserci uno spazio vuoto, ma non ho capito perché la queryUPDATE wp_posts SET post_content = REPLACE(post_content,'àƒ ','à ');
`non funziona. Forse non è uno spazio, ma un altro carattere sconosciuto
In ogni caso quest’ultima query eseguila dopo tutte le altre.
-
3 Ottobre 2006 alle 21:00 #40393uziPartecipante
Grazie!!!
faccio un backup e provo (appena ho un minuto)
-
25 Maggio 2008 alle 12:36 #53924andryonlinePartecipante
Funziona?
-
26 Maggio 2008 alle 13:29 #53956ondapiPartecipante
ottimo andryonline per aver riesumato questa vecchia discussione
lo ho provato oggi in locale con un vecchio backup di almeno un anno fa
e vedo che in locale funziona a meraviglia
ma da quando sono passato a wp25 non ho più avuto di questi problemi
che sia di migliore integrazione con le codifiche
vedo che funziona pure l’ultima query
UPDATE wp_posts SET post_content = REPLACE(post_content,’àƒ ‘,’à ‘);
sempre grande mrbrown
mi continuo a chidere come mai il tinymce non sostituisca i caratteri accentati con il relativo codice html
-
27 Maggio 2008 alle 16:56 #54009andryonlinePartecipante
Se questi sono meriti… grazie, troppo buono.
Dunque, andiamo con ordine…
Cosa sono le query (credo qualcosa che faccia parte del database)?
Dove e come le eseguo (in phpMyAdmin?)?
Quelle da voi indicate (grazie mrbrown!), riparano i caratteri “sfasati”?
Perchè si sono rovinati i caratteri se ho aggiornato WP come da istruzioni?
Ho sbagliato qualcosa?
Mi succederà ancora al prossimo aggiornamento?
Perdonate le troppe domande, ma voglio fare chiarezza…
-
27 Maggio 2008 alle 18:14 #54011ondapiPartecipante
Cosa sono le query?
Query, in informatica viene utilizzato per indicare l’interrogazione di un database in modo da ottenere dei dati contenuti in uno o più database. ancora
Dove e come le eseguo (in phpMyAdmin?)?
si in phpmyadmin scegli l’etichetta SQL e li inserisci la query del caso
se fai una ricerca ti restituisce i risultati della ricerca se fai un
UPDATE wp_posts SET post_content = REPLACE(post_content,’àƒÂ©’,’é’);
ti dovrebbe cambiare nel campo post_content della tabella wp-post quelle àƒÂ© in é ecc…
Perchè si sono rovinati i caratteri se ho aggiornato WP come da istruzioni?
? non saprei dirti
Mi succederà ancora al prossimo aggiornamento?
personalmente non ho avuto mai problemi durante gli aggiornamenti ma di solito da recuperi di backup forse da differenti impostazioni di phpmyadmin, nel forum ci sono varie discussioni in merito ma non ho mai trovato una vera soluzione, è probabile che molti disguidi siano da imputare al lato server più che a wp
ti consiglio di fare prove in locale prima di testare sul server
-
27 Maggio 2008 alle 18:21 #54012SteveAglAmministratore del forum
Non è che in wp-config vecchio si sono aggiunte le righe
define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);
nel qual caso.. si spiega l’incasinamento!
-
27 Maggio 2008 alle 18:36 #54014ondapiPartecipante
è possibile SteveAgl…
il wp-config era uno di quei file da lasciare immodificato durante gli aggiornamenti
assieme alla directory wp-content…
ma dalle versione 2.2 (mi sembra) nel wp-config è stato aggiunta questa stringa define(‘DB_CHARSET’, ‘utf8’);
e nel 2.5 quellaltra relativa alla sicurezza
che fare dunque cambiare anche il config…
-
27 Maggio 2008 alle 18:40 #54016SteveAglAmministratore del forum
Si è stata aggiunta la stringa di codifica ma i blog precedenti avevano la codifica nativa del server sql quindi spesso iso-qualchecosa… se si aggiunge quella riga Wp userà quella codifica che se non è corrispondente sul DB darà problemi di visualizzazione. Stessa cosa accade trasferendo blog con backup da un server ad un altro con codifiche diverse.
-
27 Maggio 2008 alle 21:05 #54022andryonlinePartecipante
Grazie ondapi per la tua esauriente ed utilissima spiegazione.
SteveAgl credo tu abbia centrato il punto. Effettivamente ho aggiunto quelle due righe nel wp-config, ma l’ho fatto perchè l’ho letto qui: http://www.wpitaly.it/wordpress-in-italiano
ATTENZIONE: con questa versione è stato introdotto un nuovo parametro per il file wp-config.php che definisce una SECRET KEY, confrontate il vostro file wp-config.php con il file wp-config-sample.php distribuito col pacchetto e aggiungete le righe mancanti copiandole dal file di esempio ed impostate la secret key come indicato nei commenti presenti nel file.
Sono io che ho capito male?
In ogni caso, oramai è fatta! Ora come mi consigliate di sistemare le cose? Tenete presente che ho ancora il backup del database e dei file della versione 2.3.1.
-
28 Maggio 2008 alle 5:59 #54034SteveAglAmministratore del forum
Essi… capito male.. O meglio diciamo che facciamo un concorso di colpa, noi segnalavamo di aggiungere le righe (commento e riga di definizione effettiva) della secret key tu hai aggiuto tutte le righe mancanti. Sul come fare MrBrown e Ondapi ti ha detto come…
-
28 Maggio 2008 alle 11:31 #54039andryonlinePartecipante
Ok, bene!
Grazie SteveAgl, ora procedo come spiegato. Ma siamo sicuri che si sistema tutto per benino? Altrimenti ripristino e faccio da capo (anche se ci vuole di più).
Ma le righe che ho aggiunto nel wp-config le devo togliere o le lascio? Daranno problemi al prossimo aggiornamento?
-
28 Maggio 2008 alle 15:33 #54047andryonlinePartecipante
Ho provato con le query, ma è un casino. Rimangono diversi caratteri non correti. La “à ” e gli accenti per esempio…
Che faccio? Ripristino tutto (database e file) e aggiorno nuovamente WP?
-
29 Maggio 2008 alle 14:13 #54086andryonlinePartecipante
Essendo una cosa urgente (il blog era chiuso da giorni), ho deciso di tagliare la testa al toro: sono tornato “indietro nel tempo” ripristinando i vecchi file e la copia del database.
Poi ho aggiornato il tutto senza aggiungere le “righe incriminate” nel wp-config ed è andato tutto per il verso giusto.
-
23 Giugno 2008 alle 20:40 #55114Creepy-EyesPartecipante
Anchio ho lo stesso problema, ho caricato direttamente da zero l’ultima versione di WP impostato il vecchio database e cosଠtutti i vecchi post e comment hanno i caratteri accentati, virgolette ed apici incasinati mentre quelli nuovi non hanno alcun problema. Ho eseguito le query che avete proposto sopra e sono stati corretti tutti i caratteri (come posso vedere direttamente da phpMyAdmin) ma di fatto nel blog si vedono ancora tutti!
Qualche info in più: l’attuale database ha una codifica utf8_general e nel file wp-config ci sono le righe:
define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);
Non credo a questo punto che si tratti di come i miei browser sentano questi caratteri. Ma soprattutto perchè i caratteri dei nuovi post, che nel db sono del tutto uguali a quelli dei vecchi, poi nel blog non danno problemi?
Help me!
-
23 Giugno 2008 alle 20:42 #55115wollyAmministratore del forum
prova a mettere utf8_general anche nel wp-config.
Prima ovviamente come sempre un backup del database è consigliato
-
24 Giugno 2008 alle 8:31 #55126Creepy-EyesPartecipante
prova a mettere utf8_general anche nel wp-config.
Prima ovviamente come sempre un backup del database è consigliato
ok il risultato è stato che ora sui vecchi post tutti i caratteri speciali sono stati sostituiti da un punto di domanda (visualizzazione su FireFox)
altre proposte?
-
24 Giugno 2008 alle 9:08 #55128wollyAmministratore del forum
le righe nel wp-config di quel blog con la codifica ci sono sempre state o sono state aggiunte in seguito?
Ricordo di aver scritto un articolo sul blog dove si sconsigliava di aggiungerle su un blog già attivo perchè avrebbero fatto casino.
ciao
prova a toglierle.
-
24 Giugno 2008 alle 11:35 #55134Creepy-EyesPartecipante
Niente da fare quindi ricapitolando la situazione è:
wp-config ripristinata le due righe di cui sopra e define(‘DB_CHARSET’, ‘utf8 ‘);
su phpMyAdmin
collation del database utf8_general_ci
collation della tabella wp-post utf8_general_ci
-
24 Giugno 2008 alle 12:31 #55135wollyAmministratore del forum
allora prova nel config a mettere utf8_general_ci non utf8_general come avevamo fatto prima.
-
24 Giugno 2008 alle 13:30 #55139SteveAglAmministratore del forum
provato con
define('DB_CHARSET', 'latin1 ');
? -
30 Giugno 2008 alle 19:27 #55349conlafotografiaPartecipante
anche io ho lo stesso problema, sono passato da tophost ad aruba e nel passaggio i caratteri accentati sono diventati strani, ho provato di tutto cambiando l’importazione o modificando il config ma rimangono sempre cosi’ …. nell’estrazione del sql originale i caratteri accentati sono àƒÂ … ho provato a fare l’update ma nella lettera à rimane lo spazio dopo l’accento, oltretutto anche gli apici e il carattere dell’euro… si potrebbe fare un import direttamente dal xml? oppure c’è qualche plug in ?
-
30 Giugno 2008 alle 22:13 #55361SteveAglAmministratore del forum
ti spiego come faccio io:
premesso che a volte funziona e a volte bisogna risolvere con qualche query supplementare (come descritto nei primi post di questo thread)
con le vecchie versioni di WP di solito importo il file sql tramite phpmyadmin impostando come codifica la
latin1
.Il file sql importato è esportato sempre da phpmyadmin.
Con la nuova versione di WP, che permette di impostare nel wp-config la codifica e il charset del database, dopo l’upgrade mi erano saltate tutte le lettere accentate. Mi è bastato impostare nel wp-config la riga
define('DB_CHARSET', 'latin1 ');
per risolvere il problema.Forse Tophost e Aruba usano codifiche diverse del database, oppure dipende dall’importazione che hai fatto per spostare il database.
Magari i dati sono stati codificati in UTF-8 due volte.
Ti ricordi che codifica hai usato nell’importare il file?
Se era
UTF-8
riprova conlatin1
, se eralatin1
riprova conUTF-8
.E prova anche a cambiare il DB_CHARSET nel wp-config switchando tra UTF-8 (valore di default) e latin1, insomma dovresti poter trovare la combinazione giusta.
Punto 10 euro che mettendo nel wp-config la voce
define('DB_CHARSET', 'latin1 ');
risolvi.
-
1 Luglio 2008 alle 13:14 #55385conlafotografiaPartecipante
sono passato alla 2.5.1 e su th tutto bene, ho esportato il file e questa è la parte iniziale del sql
— phpMyAdmin SQL Dump
— version 2.8.0.2
—
— Versione MySQL: 5.0.20
— Versione PHP: 4.3.10-22
—
#CREATE DATABASE
m
DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
se guardo su mysql di aruba c’è questo ….
# Versione MySQL: 5.0.58-log
# Set di caratteri MySQL: UTF-8 Unicode (utf8)
#
collazione della connessione di MySQL: utf8_general_ci
quando importo seleziono
# Set di caratteri del file utf8
per ultimo se guardo l sql del file esportato ci sono già li i caratteri strani…esempio
“la tua creativitàƒÂ . rnStruttura e copertina in lino.rnrnPrezzi da 59.95à¢â€šÂ¬ “
cmq mrbrown stasera provo con il latin1…..
p.s. stavo pensando di usare le update con le codifiche html tipo per il carattere dell’euro con il codice € e cosi’ per le lettere accentate, cosi’ si risolve il problema per sempre… che dici
-
1 Luglio 2008 alle 19:20 #55412conlafotografiaPartecipante
non funziona ho provato ma non cambia niente…..
ho provate a ricreare il db mettendo DEFAULT CHARSET=UTF8 nelle tabelle ma non cambia niente……. ho trovato pero’ questa risorsa……. http://codex.wordpress.org/Converting_Database_Character_Sets qualcuno l’ha provata?
-
1 Luglio 2008 alle 20:50 #55420SteveAglAmministratore del forum
quando importo seleziono
# Set di caratteri del file utf8
No, prova a mettere latin1! Il file esportato da tophost è codificato latin1.
UTF-8 non metterlo da nessuna parte, soprattutto nel wp-config, metti
define('DB_CHARSET', 'latin1 ');
per quanto riguarda le prove descritte nel codex, puoi farle, ma tieni sempre a portata di mano un backup del database.
-
1 Luglio 2008 alle 21:22 #55421conlafotografiaPartecipante
niente da fare ….
ho importato l’originale tophost con latin1, poi ho inserito la define ma niente….i caratteri àƒÂ¨ si vedono ancora …… che nervoso……adesso ho provato un altra strada, ho esportato in xml da wordpress e poi ho importato creando un nuovo db di la, qui funziona ma va in errore il feed
(Errore interpretazione XML: la dichiarazione XML o testuale non è all’inizio di un’entità
Indirizzo: http://www.conlafotografia.com/wordpress/feed
Linea numero 6, colonna 1:<?xml version=”1.0″ encoding=”UTF-8″?>
)
-
1 Luglio 2008 alle 22:39 #55425SteveAglAmministratore del forum
Forse nel file xml hai una riga vuota all’inizio.
Apri il file con un editor di testo (il blocco note va benissimo)
Se all’inizio c’è la riga vuota cancellala.
-
2 Luglio 2008 alle 22:25 #55472conlafotografiaPartecipante
non riesco a capire cosa cambia nei 2 db, le lettere in quelle che non funzionano gli accenti (ad esempio per lo o accentata) sono àƒÆ’à‚² mentre nel db corretto àƒÂ² , provando a mettere lo stesso carattere )nel db sbagliato cmq non lo legge correttamente e rimane il carattere strano…..
diciamo che se riesco a risolvere il problema del feed uso il db nuovo importato e non l’altro ma non capisco ho guardato ma nell’xml non c’è lo spazio, solo nel html della pagina http://www.conlafotografia.com/wordpress/feed appaiono gli spazi, chi è che crea i feed ?
-
2 Luglio 2008 alle 23:16 #55475SteveAglAmministratore del forum
sono àƒÆ’à‚² mentre nel db corretto àƒÂ² ,
la prima stringa mi sa che è stata codificata UTF-8 due volte. Perciò non funziona, credo.
Resta da capire perché viene codificata due volte.
il feed non è corretto, se vedi il codice ci sono ben 5 righe vuote all’inizio del file. Infatti Fireofox mi da’ errore, quindi lo darà anche nello script di importazione.
Prova a riesportare il feed dopo aver disattivato tutti i plugin.
-
3 Luglio 2008 alle 7:23 #55477conlafotografiaPartecipante
infatti ci sono queste righe vuote, ho disattivato tutti i plug in e poi o richiamato la pagina ma appare lo stesso errore
come faccio a riesportare il feed?
-
3 Luglio 2008 alle 9:00 #55480SteveAglAmministratore del forum
esporta il file normalmente, aprilo con un editor di testo (notepad, ultraedit, pspad, o quel che è), elimina le righe vuote all’inizio e salva il file.
per quanto riguarda la codifica, fai un’ultima prova come scritto qui:
http://www.wpitaly.it/forum/topic/7611?replies=11#post-31393
define('DB_CHARSET', 'UTF8_general_ci');
-
3 Luglio 2008 alle 18:43 #55511conlafotografiaPartecipante
Non funziona……
Per il feed cosi’ funziona ma tutte le volte che creo un altro articolo nuovo il feed va in errore…… boh….
La cosa strana è che anche nel wordpress le traduzioni hanno i caratteri strani …. come la frase
“Dopo che un file àƒÂ¨ stato caricato, saràƒ possibile aggiungere titoli e descrizioni.” …. quindi sembra che ci sia qualche impostazione degli utf errata anche per il wordpress….?
-
3 Luglio 2008 alle 20:12 #55514SteveAglAmministratore del forum
quindi sembra che ci sia qualche impostazione degli utf errata anche per il wordpress.
a questo punto penso proprio che c’è qualcosa nel tuo hosting che non va.
Cosa può essere non lo so…. chi è il tuo fornitore di hosting?
-
3 Luglio 2008 alle 20:14 #55515SteveAglAmministratore del forum
se il blog è quello nella tua firma, nell’head della pagina questa riga
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
deve diventare
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
prova ‘mpò
-
4 Luglio 2008 alle 7:14 #55526conlafotografiaPartecipante
niente…….. mi scoccia far vincere mysql pero’ ho già iniziato a modificare tutti gli articoli con la versione ok …..
-
7 Settembre 2009 alle 12:36 #68165DukessaPartecipante
Ciao a tutti
Ho un piccolo problema.
Trattasi di blog con caratteri italiani, ma anche sloveni (quindi Ä Å¡ ć Ä‘ ..ecc).
WP è settato su UTF-8 di default, niente Collate.
PHPMyAdmin è settato su Set di caratteri MySQL: UTF-8 Unicode (utf8) e Collazione utf8_unicode_ci
Le varie tabelle di WP, nel DB (da phpmyadmin), dicono Collate latin1_swedish_ci.
Guardando nel DB esportato, le varie tabelle sono DEFAULT CHARSET=latin1.
Il mio problema è:
– Capire qual è il charset adatto per visualizzare correttamente i caratteri sloveni (ISO-8859-1, ISO-8859-2, ISO-8859-15, ISO-8859-16 ????)
– Trovare il modo di convertire il DB (trattasi di 16MB….) da UTF-8 al charset adatto
in alternativa alla conversione
– Fare in modo che almeno i nuovi post visualizzino correttamente i caratteri sloveni suddetti (che al momento appaiono come “?” a parte la Å¡)
Ringrazio chi vorrà darmi una mano
-
-
AutorePost
- Devi essere connesso per rispondere a questo topic.