[MySQL] Vreemde tekens na backuppen / exporten database

[VincentG]

Al lange tijd zit ik met een vreemd euvel, het goed backuppen van een database.
Van onze eigen server hebben we nog geen SSH toegang, wat er wel aan zit te komen.
Nu ben ik bezig met het overzetten van een site van een andere server en heb ik daar dus ook geen SSH access toe.

Normaal gesproken maakte ik backups via phpMyAdmin of backup functie in DirectAdmin hostpanel.
Probleem is dan, dat je vreemde tekens in je .sql file krijgt.
Standaard MySQL instellingen op de servers:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_unicode_ci

In de database zelf staan vreemde tekens wel goed, maar bij een backup wordt:
één > @©@©n
et cetera.

Nou heb ik via PhpED NuSphere de backup ingeladen en als UTF-8 laten herkennen, maar de vreemde tekens blijven behouden.
Overigens heeft het geen zin om teksten door een php functie te halen die @© omzet in é, dat negeert ie gewoon.

Hoe krijg ik nou weer een goede backup (nog zonder SSH), of hoe convert ik deze naar een goede sql file zonder vreemde tekens, zodat ik die zonder problemen in een andere database kan importeren?

[Juup]

De editor waar je de file in bekijkt kan blijkbaar de multi-byte characters niet als zodanig herkennen.
Staat de .sql file wel als utf-8 op je filesysteem?

[BCC]

Inderdaad, met welke editor loop je te werken. Wanneer 1 character naar 2 gesplitst worden zit er ergens iets in je ketting dat UTF8 niet begrijpt (aangezien dat 2 bytes per character kan zijn). Aangezien MySQL daaar zeker geen problemen mee heeft, verdenk ik je editor. Hoe ziet het eruit in vi?

En Jaaap: er is niet zoiets als een utf-8 file, een file is altijd een bytestream. Het gaat puur om het feit of het programma dat de file leest de goede encoding gebruikt.

[ Voor 30% gewijzigd door BCC op 17-08-2008 15:18 ]

[Creepy]

BCC: Tekstfiles kunnen een Byte Order Mark (BOM) bevatten. Een UTF-8 file heet normaal gesproken een BOM staan die aangeeft dat het om UTFf-8 gaat. Als dit mist en je file bevat toch UTF-8 dan kan het zijn dat je tekst file toch als plain ascii wordt getoond.

[VincentG]

Normaal gesproken zou je verwachten dat je een database backup kan maken zonder die vreemde tekens erin, zodat je die ook weer normaal kan importeren in je database.
Kreeg als tip om de file eens in NuSphere PhpED in te laden en dan UTF-8 te kiezen, maar dat veranderd verder niets aan de file. Ook kladblok/wordpad ed helpt niet. Moet de sql file op een andere manier goed zien te converteren, zodat de vreemde tekens die er bij de export in zijn gekomen, verdwijnen, waarna ik de juiste sql data weer in de database kan zetten.

[BCC]

Kun je niet proberen om opnieuw een export te maken? Of gaat het nu mis omdat je een backup probeert terug te zetten?

[VincentG]

Bij alle exports krijg ik altijd die vreemde tekens.
In de database zelf staat het nog wel goed, maar op een of andere manier rotzooid ie ermee bij de export.

[SPee]

Zoals eerder gezegd; In welke editor open je het bestand en kan die UTF-8 aan?

In b.v. Notepad++ kun je onder 'Format' de optie UTF-8 kiezen. Deze zal het bestand dan als zodanig lezen.
Notepad/Wordpad kunnen dat bijvoorbeeld niet.

[BCC]

Wat zegt je hoster hiervan? En hoe doe je het nu exact? Ik weet zeker dat dit icm phpmyadmin zonder problemen werkt.

En wat is PhpED NuSphere?! Een PHP editor?

[ Voor 78% gewijzigd door BCC op 17-08-2008 16:54 ]

[Soultaker]

Kun je eens een hexadecimale dump maken van je backup en daarin kijken wat voor bytes er gebruikt worden om b.v. een é te coderen? (Als je met Windows moet werken, b.v. met de hex editor van PSpad ofzo.)

Een ISO-8559-1 codering van @© die je geeft zouden bytes 0x40, 0xA9 zijn (64, 169), terwijl een UTF-8 codering van é juist 0xC3, 0xA9 had moeten zijn, oftewel é in ISO-8559-1. Ik heb geen idee welke codering die @ zou moeten opleveren.

[VincentG]

SPee schreef op zondag 17 augustus 2008 @ 16:49:
Zoals eerder gezegd; In welke editor open je het bestand en kan die UTF-8 aan?

In b.v. Notepad++ kun je onder 'Format' de optie UTF-8 kiezen. Deze zal het bestand dan als zodanig lezen.
Notepad/Wordpad kunnen dat bijvoorbeeld niet.

NuSphere PhpED is een PHP editor (gebruik die normaal gesproken nooit) en moet UTF-8 aankunnen.
Ik ga het eens proberen met Notepad++ of de hexadecimale converter.

[BCC]

Bevat de backup ook de table definities? Zo ja: klopt daar de enconding wel van?

[Remus]

Creepy schreef op zondag 17 augustus 2008 @ 15:22:
BCC: Tekstfiles kunnen een Byte Order Mark (BOM) bevatten. Een UTF-8 file heet normaal gesproken een BOM staan die aangeeft dat het om UTFf-8 gaat. Als dit mist en je file bevat toch UTF-8 dan kan het zijn dat je tekst file toch als plain ascii wordt getoond.

UTF-8 heeft geen BOM (al staat de standaard het wel toe), aangezien de byte order in het geval van UTF-8 onafhankelijk is van de endianness van je systeem. Zie ook http://www.unicode.org/faq/utf_bom.html#29

[BCC]

Remus schreef op zondag 17 augustus 2008 @ 20:30:
[...]
UTF-8 heeft geen BOM (al staat de standaard het wel toe), aangezien de byte order in het geval van UTF-8 onafhankelijk is van de endianness van je systeem. Zie ook http://www.unicode.org/faq/utf_bom.html#29

Theoretisch kun je die ook nooit lezen, want je weet nooit van tevoren met welke enconding je de enconding string/byte zo moeten lezen .

[Remus]

Om welke MySQL versie gaat het trouwens. Als ik wat zoek, dan zie ik namelijk diverse resultaten waarbij onder MySQL 4 de database tabellen latin-1 zijn, maar wel utf-8 bevatten, dan gaat het mis bij de dump door een soort van dubbel codering of zo. Zie ondermeer http://www.orthogonalthou...n-and-special-characters/

[ Voor 5% gewijzigd door Remus op 17-08-2008 22:30 ]

[whoami]

Dit hoort eerder thuis in DTE
-> DTE

[Creepy]

Remus schreef op zondag 17 augustus 2008 @ 20:30:
[...]

UTF-8 heeft geen BOM (al staat de standaard het wel toe), aangezien de byte order in het geval van UTF-8 onafhankelijk is van de endianness van je systeem. Zie ook http://www.unicode.org/faq/utf_bom.html#29

Zie dan ook http://unicode.org/faq/utf_bom.html#29 waar de BOM (want dat is het ) gebruikt wordt als UTF-8 signature. Een hoop editors gebruiken een tekstfile als UTF-8 alleen als deze is gevonden.

Overigens zal MySQL zonder die BOM gewoon de standaard encoding gebruiken, dus een import zal zonder de BOM gewoon goed gaan.

[VincentG]

Big edit:

Het staat dus al verkeerd in de db, bijv. "België is sterker dan Kazachstan".
Nou heb ik en een ander via meta-tag charset en phpMyAdmin charsets geprobeerd, maar we krijgen het op de nieuwe server niet goed, ook niet wanneer charset instellingen gelijk staan. Het is enerzijds al vreemd dat het zo bij hun in de DB komt.
De DB backup via Notepad++ naar UTF-8 converteren helpt ook niet.
Via MySQL Administrator backups maken en restoren als utf-8 of latin1 helpt ook niet. Zou toch een mogelijkheid moeten zijn om die vreemde tekens goed te converteren en netjes in de nieuwe DB te krijgen.

[ Voor 83% gewijzigd door VincentG op 18-08-2008 17:59 ]