Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You're correct, the right way is to fix your database. Trust me, I've just gone through this (to fix a solr installation, oddly enough) and the sooner you can fix it the less pain it will cause you.</p> <p>There's two ways to fix your data stored in the wrong encoding:</p> <ol> <li><p><code>mysqldump</code> all the data as latin1 (<code>--default-character-set=latin1</code>), edit the table definitions to be <code>CHARACTER SET=utf8</code> instead of <code>latin</code> and then reimport the dump.</p></li> <li><p>Run two alter statements for each mis-encoded column</p> <p><code>ALTER table MODIFY columns BINARY</code></p> <p><code>ALTER TABLE MODIFY column VARCHAR(255) CHARSET utf8</code></p> <p>by modifying to BINARY first, you can trick MySQL in to not running the latin1=>utf8 conversion which, in your case, would double-encode and break your data.</p></li> </ol> <p>If your db is large, 1 is going to be faster than 2.</p> <p>Immediately after that, just configure your PHP application to communicate with MySQL using utf8. This can be done by sending <code>SET NAMES utf8</code> as the first query of every connection. If PHP is already sending utf8 data to MySQL, that should be all you need to do.</p> <p>If, after this fantastically worded and detailed answer you're still looking for a hack... Try and configure JDBC to connect as UTF8 but see if there's a way to get it to send a pre-command before it does any work.</p> <p>If you make that command: <code>SET NAMES latin1</code> then, theoretically, Solr should connect as UTF8 and process data coming from the connection as UTF8, but MySQL will consider the connection a latin1 connection and not convert any data coming from your latin1 columns.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload