[Mysql] charsets/collation discrepanties tussen versies *

[Verwijderd]

Hi,

Ik heb hier een ontzettend vervelend probleem. Ik dacht de oplossing gevonden te hebben in dit topic, maar helaas.

De situatie:
Ik heb een MySQL 4.0.15-max databaseserver draaien. De inhoud van een aantal tabellen (afkomstig uit een MySQL 4.1.8 server) zijn geimporteerd naar de 4.0.15 server. Bij de creatie van de tabellen op de 4.0.15 server heb ik geen specifieke zaken opgegeven wat charsets betreft. Een aantal velden in de tabellen op de 4.1.8 server zijn echter 'latin1_swedish_ci' (dit is geloof ik standaard sinds versie 4.1).
Wanneer ik nu data ophaal (via een script of via phpMyAdmin), krijg ik soms (je voelt hem al aankomen) rare tekens te zien. Het woord Münster wordt bijvoorbeeld Münster.

Ik heb de documentatie op Mysql.com over charsets al doorgenomen. Bij mijn weten kan ik dit probleem niet omzeilen door een query aan te passen.
Ik heb geprobeerd de charset in de meta-tag al aan te passen in bijvoorbeeld:

code:

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Heeft alleen niets geholpen...

Is er een manier waarop ik de data die ik uit de database ontvang direct goed kan ontvangen? Of anders een PHP functie die het geheel goed kan krijgen? Een serverinstelling? Een andere metatag? Of moet ik misschien de bewuste tabellen opnieuw (anders) creeëren?
Het gaat er namelijk om dat ik grote hoeveelheden data kan importeren van systeem A naar B.

[Verwijderd]

Schop!

Niemand? Het lijkt me dat toch meer mensen tegen dit probleem zijn aangelopen bij de conversie naar 4.1?

[MSalters]

De charset in de metatag aanpassen is natuurlijjk niet al te nuttig, als je feitelijke charset niet overeenkomt. Ik kan niet 1-2-3 zien wat er mis is; je ü expandeert blijkbaar tot 4 karakters. Dat is geen UTF-8. ASCII chars zijn 1 byte in UTF-, Latin-1 = ISO-8859-1 chars zijn 2 bytes in UTF-8.

[Verwijderd]

Wij hebben hier hetzelfde probleem, we kunnen wel € tekens invoeren in de database maar hij komt er mooi niet uit na conversie

[Verwijderd]

Ik heb nog even wat waarden uit de database zitten bekijken... Het zijn (ter informatie) teksten uit het Espéranto. Nu ken ik geen woord Esperanto dus is het bij enkele woorden even gissen wat er nu eigenlijk hoort te staan. Maar onderstaande drie kan ik dan thuisbrengen:



Ik heb hier maar even een screenshot gemaakt van de stukjes teksten, aangezien de forum software hier ook weer een vertaalslagje gaat doen

Nu is dus te zien dat bij de woorden Münster en Isbrükaj de ü allebei net iets anders is omgezet. Het 1/4-teken is bij het woord Münster omgezet in een htmlspecialchar zeg maar... Zou de vorige maker van de site dit hebben zitten op fucken ofzo?

Het is wel duidelijk dat er een bepaalde 'vertaalslag' gemaakt moet kunnen worden ergens, aangezien die ü bij de eerste twee woorden naar dezelfde tekenreeks wordt vertaald...

[ Voor 20% gewijzigd door Verwijderd op 17-06-2005 10:01 ]

[Verwijderd]

Altijd lastig dit soort problemen, maar ik heb het opgelost!

Ten eerste heb ik als characterset gekozen voor UTF-8. Je kunt deze natuurlijk opgeven in je HTML META tags, maar ook via PHP aan je headers meegeven (die overrulen dan die uit je HTML code als ik het goed heb).
Ten tweede heb ik de gegevens die uit de database komen met de PHP functie 'utf8_decode()' omgezet. Nu komt alles netjes uit de database rollen.

Mijn plan is om met deze PHP functie een soort conversie scriptje te schrijven zodat ik nu verder kan gaan met mijn 'nieuwe' database met de standaard charset die gebruikt wordt in MySQL 4.0.15.

[jochemd]

Verwijderd schreef op vrijdag 17 juni 2005 @ 10:47:
Mijn plan is om met deze PHP functie een soort conversie scriptje te schrijven zodat ik nu verder kan gaan met mijn 'nieuwe' database met de standaard charset die gebruikt wordt in MySQL 4.0.15.

Waarom denk je dat de standaard charset een goede keuze is?

[Verwijderd]

jochemd schreef op vrijdag 17 juni 2005 @ 11:49:
[...]

Waarom denk je dat de standaard charset een goede keuze is?

Omdat ik nooit anders heb gebruikt en deze altijd heeft voldaan. Maar mocht je andere goede voorstellen hebben, dan zijn die uiteraard van harte welkom!

[Verwijderd]

Ik heb nu mijn 'conversie' scriptje gebakken, maar ik kom toch weer wat raars tegen... Ik ga gewoon heel rigoureus te werk en update van elke tabel elk veld. Ik doe dan de inhoud van ieder veld door de 'utf8_decode()' functie heenhalen. Je zou dan toch zeggen dat alles op de juiste manier wordt opgeslagen in de database...

Echter, wanneer ik de database uitlees, krijg ik precies wat ik zojuist al weer had! Weirde shit... Enig idee?

[jochemd]

Verwijderd schreef op vrijdag 17 juni 2005 @ 12:08:

Omdat ik nooit anders heb gebruikt en deze altijd heeft voldaan.

Totdat je een nieuwe server installeert en die toevallig een andere default heeft.

Accepteer niet zomaar de default want die kan op elke installatie anders zjin. Maak een expliciete keuze voor een bepaalde charset en zorg dat in elk DDL script die keuze staat. Wees proactief en zorg dat je niet nog een keer in de situatie komt waarin je nu zit.

Maar mocht je andere goede voorstellen hebben, dan zijn die uiteraard van harte welkom!

Hoe kan ik een ander voorstel doen als ik niet eens weet wat je nu draait? Je hebt het over "default charset" alsof daarmee voor iedereen duidelijk is welke charset dat is. En zelfs als het mogelijk was om dat af te leiden, hoe moeten wij dan suggesties doen voor een goede charset zonder dat je hebt verteld wat de requirements zijn?

[curry684]

Titelfix