[phpmyadmin] UTF-8 export gaat mis

[posttoast]

Ik heb hier een database met UTF-8 encoded data. Werkt allemaal prima, alleen probeer ik met PHPMyAdmin een dump te doen om die database over te zetten naar een andere server. En daar gaat het mis, het bestand dat PHPMyAdmin uitspuugt is niet UTF-8 encoded maar ANSI en bevat niet de juiste data.

Voorbeeld: Россия (Russisch voor "Rusland") wordt Россия

Iemand enig idee hoe ik dit op kan lossen?

[NMe]

Je hebt in de opties bij het exporteren gewoon staan welke encoding gebruikt moet worden in je exportbestand.

[posttoast]

Deze bedoel je?



Die staat gewoon goed dus volgens mij.

[RobIII]

En waaruit concludeer je dan dat 't mis gaat? Je opent de export toch niet in een-of-andere tool/notepad-clone/whatever die toevallig niet met UTF-8 overweg kan, wel? En bij import geef je ook UTF-8 aan?

[ Voor 10% gewijzigd door RobIII op 01-10-2012 16:30 ]

[posttoast]

Notepad++, dus die moet dat gewoon kunnen. En die geeft dus aan dat het bestand ANSI is en niet UTF-8. En ja, bij het importeren heb ik hem ook op UTF-8 staan.

[ Voor 21% gewijzigd door posttoast op 01-10-2012 16:32 ]

[RobIII]

posttoast schreef op maandag 01 oktober 2012 @ 16:31:
En die geeft dus aan dat het bestand ANSI is en niet UTF-8.

Dan is de export waarschijnlijk niet voorzien van een BOM en werkt de encoding detectie van notepad++ waarschijnlijk niet heel jofel. Als je 'm bij openen (of na openen? ik heb geen notepad++ hier) alsnog op UTF-8 zet/forceert, wat gebeurt er dan?

[ Voor 6% gewijzigd door RobIII op 01-10-2012 16:33 ]

[Janoz]

Geeft hij aan dat het bestand ANSI is? Of geeft hij het weer als ANSI. Als er geen BOM op het bestand zit is er met geen mogelijkheid automatisch op te maken welke encoding er gebruikt wordt.

[Patriot]

Tekstbestanden hebben van zichzelf geen mogelijkheid om mee te geven in welke encoding ze zijn opgeslagen. Als PHPMyAdmin de boel opslaat als UTF-8 zonder BOM, en in de eerste x tekens zit geen teken waaruit Notepad++ denkt af te kunnen leiden dat het om UTF-8 gaat (ik weet niet of Notepad++ dit op die manier doet eigenlijk) dan is er een grote kans dat hij het als ANSI interpreteert terwijl het dat niet is. Als je in Notepad++ de boel op UTF-8 zet en hij laat het dan wel goed zien is er niets aan de hand en is alles goed gegaan.

EDIT: spuit 11 12

[ Voor 3% gewijzigd door Patriot op 01-10-2012 16:34 ]

[RobIII]

Janoz schreef op maandag 01 oktober 2012 @ 16:33:
met geen mogelijkheid automatisch op te maken welke encoding er gebruikt wordt.

Met geen mogelijkheid is wat overdreven (ik ben de url even aan 't googlen nog...), maar 't is wel verdomd lastig ja en niet heul betrouwbaar

[ Voor 12% gewijzigd door RobIII op 01-10-2012 16:35 ]

[begintmeta]

Zou ik ook denken, welke fatsoenlijke editor gebruikt tegenwoordig eigenlijk ANSI als default?

[ Voor 69% gewijzigd door begintmeta op 01-10-2012 16:35 ]

[Patriot]

RobIII schreef op maandag 01 oktober 2012 @ 16:34:
[...]

Met geen mogelijkheid is wat overdreven (ik ben de url even aan 't googlen nog...), maar 't is wel verdomd lastig ja en niet heul betrouwbaar

http://blogs.msdn.com/b/m...e/2007/04/22/2239345.aspx ?

[Janoz]

Je kunt een heel eind komen, maar het is nooit sluitend te krijgen.

Maar goed, ik heb ff notepad++ open getrokken en daar dat russisch ingeplempt terwijl hij qua codering op UTF-8 (without BOM) stond en vervolgens de codering naar ANSI gezet en daar komt dan inderdaad keurig "Россия" uit. Kortom, PEBMAC .

[RobIII]

Patriot schreef op maandag 01 oktober 2012 @ 16:36:
[...]


http://blogs.msdn.com/b/m...e/2007/04/22/2239345.aspx ?

Meer http://blogs.msdn.com/b/m...ve/2005/01/30/363308.aspx
Maar uiteindelijk doelde ik op deze (lekker hoog aluhoedjes gehalte voor extra vermaak): Bush hid the facts

[Patriot]

RobIII schreef op maandag 01 oktober 2012 @ 16:39:
[...]

Meer http://blogs.msdn.com/b/m...ve/2005/01/30/363308.aspx
Maar uiteindelijk doelde ik op deze (lekker hoog aluhoedjes gehalte voor extra vermaak): Bush hid the facts

Ah, mojibake! Ik was me net aan het afvragen welke zin met bush het ook alweer was

[posttoast]

PEBMAC indeed. Maar helaas niet tussen mijn eigen monitor en stoel. Ik heb het even lokaal op mijn eigen server getest, en daar gaat het prima. Export en import naar een andere database, karakters blijven zoals ze moeten zijn.

Maar... als ik het doe op de server waar het om gaat, dan loopt het dus wel mis. Helaas doe ik die imports niet zelf (ik mag daar niet bij, alleen de sysop doet dat). Dus ik moet het probleem maar daar neer leggen. Bedankt allemaal in ieder geval

[NMe]

Bij de import kan hij ook aangeven welke encoding het ingelezen bestand zou moeten hebben. 10 tegen 1 dat het daar mis gaat.

[RobIII]

NMe schreef op maandag 01 oktober 2012 @ 17:03:
10 tegen 1 dat het daar mis gaat.

Ik acht de kans dat "aan de andere kant" de tabellen op een andere encoding staan anders ook nog aanwezig; ik ken PHPMyAdmin en MySQL niet zo intiem dat ik je uit de blote bol kan vertellen dat 't daar ook kan zitten (of dat een dergelijke situatie een foutmelding zou geven oid) maar ik zou er niet van staan kijken als dat de oorzaak zou zijn. Dus dat bij de import wel de correcte encoding wordt geselecteerd maar dat de tabellen waar de de file naar toe gelezen wordt een andere encoding hebben.

[ Voor 19% gewijzigd door RobIII op 01-10-2012 17:07 ]

[NMe]

Daar zou het in principe alleen fout kunnen zijn als posttoast's setupscript niet netjes encoding heeft aangegeven bij het CREATE TABLE-statement, maar dat is inderdaad ook een optie.

Overigens: Waar hoort mijn topic?
WEB>>PRG

[posttoast]

Ik heb netjes de encoding meegenomen in mijn setupscript, dus dat is het punt niet. Ik zal dit hele verhaal doorsturen naar de persoon die het beheert. Dat is in Rusland, dus die communicatie loopt al niet al te lekker

[pim]

Het bestand is dus gewoon met utf-8 tekens.. Zorg ervoor dat je import ook utf-8 gebruikt:

mysql -u USERNAME -h HOSTNAME -p -f --default-character-set utf8 DATABASENAAME < datafile.sql

[NMe]

Psst, kijk eens naar de 4 posts boven je.

[sky-]

Waarom maak je uberhaupt een export met PhpMyAdmin? Dat kan ook dmv mysqldump, werkt veel sneller.

[NMe]

sky- schreef op dinsdag 02 oktober 2012 @ 15:53:
Waarom maak je uberhaupt een export met PhpMyAdmin? Dat kan ook dmv mysqldump, werkt veel sneller.

Bijvoorbeeld omdat je geen shelltoegang hebt? Of omdat je een GUI wel zo prettig vindt? Of omdat je een bepaalde extra optie nodig hebt die phpMyAdmin biedt? Het snelheidsverschil is nou ook weer niet zó groot dat het echt boeit waarmee je exporteert.

[sky-]

Mwah doelde meer dat als je database redelijk groot is het aardig lang duurt. ;-)

Ik zou gewoon met PHP een exec() scriptie schrijven die je database naar een .sql dumpt. Dan laad je die url (als je geen shell hebt) en even wachten.

Simpel voorbeeld: http://davidwalsh.name/backup-mysql-database-php