Mysql + utf-8 probleem

[Droned]

Ik ben momenteel bezig met een migratie van een Ruby On Rails applicatie van één server naar de andere. Nu ben ik op een vervelend probleem gebotst dat ik niet kan oplossen.

Het is een franse website en bijvoorbeeld het woord "Précieux" wordt op de oude server correct weergegeven maar op de nieuwe server wordt het weergeven als "Pr?cieux".

Ik ben eens in de database gaan kijken op de oude server en daar staat dit record ook als volgt in de database "Pr?cieux", dus het wordt wel goed weergegeven op de oude server maar staat wel fout in de database. De database is een mysql database.

Ik gebruik net dezelfde code en database op de nieuwe server.

Hier vind je een bewijs van mysql rijen + de instellingen :

http://pastie.org/1687438

Hier ook de antwoordheaders :

http://pastie.org/1687517

Iemand die mij kan helpen?

[Kees]

Wat doe je precies? Vervang je alleen de RoR server, of vervang je ook de databaseserver?

En welke charset gebruikt de 'oude' RoR server dan?

[CodeCaster]

dus het wordt wel goed weergegeven op de oude server maar staat wel fout in de database.

Ja, want je server weet natuurlijk vanzelf dat de ? in 'pr?cieux' een é moet worden, en in 'l?ve' een è.

Lijkt mij niet aan je database te liggen, maar aan je http-headers en/of html-tags. Standaardlinkje in deze gevallen: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

[ Voor 52% gewijzigd door CodeCaster op 19-03-2011 10:09 ]

[Droned]

OK, ik heb het probleem beter kunnen situeren. Het probleem is het volgende:

1. Op de oude server wanneer ik naar records ga kijken zie ik een ? ipv é
2. Als ik een mysql dump doe op de oude server dan staan in de dump de é ook als é
3. Als ik import op de nieuwe server dan staat é terug als ?, maar wordt deze op applicatieniveau niet geconverteerd

Hoe kan ik dit gewoon als é in de database importen?

Dit is hoe een create_table eruitziet in de dump :

http://pastie.org/1689163
en bovenaan
http://pastie.org/1689191

Daarnaast gebruik ik dezelfde code en database ( ik wil ze beide op de nieuwe server plaatsen ). In firebug lijken ook de headers allebei UTF-8 door te sturen als encoding die moet worden gebruikt.

Wanneer ik op de nieuwe server mijn record wijzig via de applicatie, dus bijvoorbeeld pr?cieux in précieux dan is het na het updaten wel correct weergegeven.

Ik heb ook eens gekeken naar de HEX waarden van een record, aan de hand van volgend query:

code:

select HEX(description),description from advantages where id = 7;

Ik heb dit resultaat terug ge-encodeerd met een tool op internet en daar wordt het wel degelijk als een é geïnterpreteerd.

[ Voor 14% gewijzigd door Droned op 19-03-2011 13:04 ]

[CyBeR]

Is dit ook een nieuwe database? Dan staat je character set info gewoon verkeerd.

code:

ALTER DATABASE <dbnaam> DEFAULT CHARACTER SET 'utf8'

[Droned]

CyBeR schreef op zaterdag 19 maart 2011 @ 13:24:
Is dit ook een nieuwe database? Dan staat je character set info gewoon verkeerd.

code:

ALTER DATABASE <dbnaam> DEFAULT CHARACTER SET 'utf8'

Dat is niet het probleem want de oude database is exact een kopie van de nieuwe en deze characters zijn ook goed geïmporteerd in de nieuwe database. Ik heb je query voor elke zekerheid maar eens uitgevoerd maar geen verandering. Ik denk dat het iets is met de http-headers van de servers. Sommige zeggen dat deze te laat worden geïnitialiseerd, klopt dit?

http://pastie.org/1689291

En wanneer ik gewoon in mijn Rails applicatie in de views é schrijf wordt deze wel correct weergegeven, het is enkel en alleen records uit de database die niet juist worden weergegeven, terwijl deze wel degelijk juist in de database geëncrypteerd zijn voor utf8

[ Voor 16% gewijzigd door Droned op 19-03-2011 13:40 ]

[CyBeR]

Droned schreef op zaterdag 19 maart 2011 @ 13:37:
[...]


Dat is niet het probleem want de oude database is exact een kopie van de nieuwe en deze characters zijn ook goed geïmporteerd in de nieuwe database.

Dat maakt niet zo heel veel uit, maar ligt aan de manier waarop 'ie gemaakt is.

Ik heb je query voor elke zekerheid maar eens uitgevoerd maar geen verandering.

Het kan ook nog zijn dat we dit verhaal nu als UTF-8 zitten te behandelen terwijl 't eigenlijk juist als Latin-1 in de DB gezet is. Dat zou ook mis gaan namelijk.

[Droned]

CyBeR schreef op zaterdag 19 maart 2011 @ 13:39:
[...]


Dat maakt niet zo heel veel uit, maar ligt aan de manier waarop 'ie gemaakt is.


[...]


Het kan ook nog zijn dat we dit verhaal nu als UTF-8 zitten te behandelen terwijl 't eigenlijk juist als Latin-1 in de DB gezet is. Dat zou ook mis gaan namelijk.

Het is wel degelijk UTF-8 want ervoor is niets anders gebruikt, je ziet dit ook bij de create tables van de tabellen :

http://pastie.org/1689352

[Kees]

Droned schreef op zaterdag 19 maart 2011 @ 13:44:
[...]


Het is wel degelijk UTF-8 want ervoor is niets anders gebruikt, je ziet dit ook bij de create tables van de tabellen :

http://pastie.org/1689352

En als je daar zelf latin1 van maakt? Ik kan me herinneren dat wij hier ook problemen mee hadden, en als ik nu in de database loer waarin deze posts opgeslagen staan, dan zie ik alleen maar latin1_swedish_ci.

[Deikke]

Heb je de verbinding ook op utf8 gezet? Dit wordt vaak vergeten, zodra je met utf-8 gaat werken, moet ook alles utf-8 zijn. In mysql kan dit simpel via:

SET NAMES utf8

na het inloggen.

[Droned]

Kees schreef op zaterdag 19 maart 2011 @ 13:46:
[...]

En als je daar zelf latin1 van maakt? Ik kan me herinneren dat wij hier ook problemen mee hadden, en als ik nu in de database loer waarin deze posts opgeslagen staan, dan zie ik alleen maar latin1_swedish_ci.

Ik heb alle utf8 in de dump naar latin1 gewijzigd en utf8_unicode_ci naar latin1_swedish_ci en dit loste het probleem op, nu weet ik niet of dit het ideale is, dit is momenteel geen probleem maar wanneer wij overschakelen naar de nieuwe server voor productie dan zal dit downtime brengen omdat we eerst nog alle utf8 naar latin1 moeten wijzigen in de dump.

Is hier een andere oplossing voor?