ë wordt verkeerd weergegeven uit MySQL

[Verwijderd]

Hi all,

Ik zit met een probleempje, volgens mij erg simpel maar ik kom er niet uit.
Ik heb in een database text staan met daarin tekens zoals de e in "Jordanië".
Op de site staat er "Jordani?". Ik heb de db en de tables omgegooid naar UTF8 alleen geen resultaat...

Iemand een idee?

Thnx already

[supakeen]

Ja. Je moet je connection type ook nog op UTF-8 zetten.

code:

SET NAMES 'utf8';
SET CHARACTER_SET 'utf8';

En voor je script (zoals hieronder gezegd) een header sturen die (waarschijnlijkt) het volgende moet bevatten:

code:

Content-Type: text/html; charset=utf-8

[ Voor 76% gewijzigd door supakeen op 02-09-2008 16:31 ]

[Megamind]

Dan nog moet je de output van je script goed zetten naar het goede encoding type.

En dan moet je weer de data opnieuw opslaan met alle ë é á enz, want effe je tabel omgooien werkt niet zo.

[Verwijderd]

Charlie Murphy schreef op dinsdag 02 september 2008 @ 16:28:
Ja. Je moet je connection type ook nog op UTF-8 zetten.

code:

SET NAMES 'utf8';
SET CHARACTER_SET 'utf8';

En voor je script (zoals hieronder gezegd) een header sturen die (waarschijnlijkt) het volgende moet bevatten:

code:

Content-Type: text/html; charset=utf-8

heb ik gedaan, no result
ik ga trachten alle data om te zetten.

[Megamind]

Ja dat klopt wel, maar dat moet je doen vóórdat je data in je DB gaat zetten. Hoe moet MySQL anders weten wat die ? betekent.

[Verwijderd]

Megamind schreef op dinsdag 02 september 2008 @ 16:35:
Ja dat klopt wel, maar dat moet je doen vóórdat je data in je DB gaat zetten. Hoe moet MySQL anders weten wat die ? betekent.

ik ga de huidige db aanpassen zodat de data die vanaf nu ingevoerd wordt goed weergegeven wordt. Zie het niet echt zitten om alle items in de db aan te passen.

Thnx

[ToolkiT]

Verwijderd schreef op dinsdag 02 september 2008 @ 16:38:
[...]

ik ga de huidige db aanpassen zodat de data die vanaf nu ingevoerd wordt goed weergegeven wordt. Zie het niet echt zitten om alle items in de db aan te passen.

Thnx

succes, dat zou nog wel eens lastig kunnen zijn want er zijn niet echt identifiers waarvan je kan zeggen wat die ? nou moest zijn...

[ Voor 39% gewijzigd door ToolkiT op 02-09-2008 16:44 ]

[.oisyn]

Ik snap niet waarom mensen altijd zo zitten te kutten met de encoding van de database. Feitelijk doet die encoding er niet toe, zolang je geen string operaties in queries gaat zitten doen (die je meestal ook niet nodig hebt). Waar je gewoon voor moet zorgen is dat de invoer encoding van je (web)applicatie gelijk is aan die van de uitvoer.

Verwijderd schreef op dinsdag 02 september 2008 @ 16:26:
Ik heb in een database text staan met daarin tekens zoals de e in "Jordanië".

Waarmee heb je gecontroleerd dat dat ook zo in je database staat? Via de CLI van MySQL, of een tool als phpmyadmin?

[ Voor 40% gewijzigd door .oisyn op 02-09-2008 17:02 ]

[Verwijderd]

.oisyn schreef op dinsdag 02 september 2008 @ 16:59:
Ik snap niet waarom mensen altijd zo zitten te kutten met de encoding van de database. Feitelijk doet die encoding er niet toe, zolang je geen string operaties in queries gaat zitten doen (die je meestal ook niet nodig hebt). Waar je gewoon voor moet zorgen is dat de invoer encoding van je (web)applicatie gelijk is aan die van de uitvoer.


[...]

Waarmee heb je gecontroleerd dat dat ook zo in je database staat? Via de CLI van MySQL, of een tool als phpmyadmin?

gecontroleerd/gewijzigd met phpmyadmin,

de db:
de karakterset is utf8-unicode
verbindingscollatie utf8_general_ci

de tabellen:
Type: MyISAM
collatie: utf8_general_ci

[ Voor 9% gewijzigd door Verwijderd op 02-09-2008 18:43 ]

[Verwijderd]

Thanks voor alle hulp guys. Hebben besloten de oude data te laten voor wat het is. De database en de tabellen staan goed zodat nieuw ingevoerde data juist wordt weergegeven.

Grtz

wes

[Johnny]

Je kan je oude inhoud nog eenvoudig omzetten naar UTF-8, het enige wat je hoeft te doen is de tabel instellen op de encoding die overeenkomt met je inhoud en dan de volgende query runnen om alles om te zetten naar UTF-8.

SQL:

ALTER TABLE table_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Let ook op dat utf8_general_ci en utf8_unicode van elkaar verschillen en problemen geven als je joins gaat maken op velden met verschillende encodings.

[.oisyn]

Verwijderd schreef op dinsdag 02 september 2008 @ 18:19:
[...]


gecontroleerd/gewijzigd met phpmyadmin,

Dat dacht ik al. En hey, draait phpmyadmin niet toevallig óók gewoon op een webserver? Op een of andere manier weet die dus wél de data correct te outputten, dus jouw script moet dat ook kunnen, zónder de db aan te passen.

Nogmaals:

Waar je gewoon voor moet zorgen is dat de invoer encoding van je (web)applicatie gelijk is aan die van de uitvoer

Ergens gaat dat bij jouw script dus fout, en het ligt niet aan je database.

[ Voor 21% gewijzigd door .oisyn op 02-09-2008 19:35 ]

[BtM909]

En neem nou even de wijze woorden van de meneer boven me aan en ga je daar even in verdiepen

Daarnaast hoort dit topic in PRG, dus verplaats ik hem even

[Confusion]

Verwijderd schreef op dinsdag 02 september 2008 @ 18:56:
De database en de tabellen staan goed zodat nieuw ingevoerde data juist wordt weergegeven.

Dat is nog maar de vraag. Het kan best zijn dat je nu een reeks bytes in je tabellen hebt staan waarvan MySql beweert dat het UTF-8 encoded is, terwijl het dat in feite helemaal niet is. Het zou kunnen dat het goed gaat omdat de applicatie waarmee je de code uitleest ook denkt dat het bijvoorbeeld ISO-8859-1 is (bijvoorbeeld omdat dat jouw locale is en je niet specifiek opgeeft wat er uit de MySql driver komt en hij daar dus op default) en je dus eigenlijk twee keer dezelfde fout maakt, waardoor ze elkaar opheffen.

De snelste manier om het zeker te weten welke bytes er eigenlijk in de database staan is om de data op de command line uit de database te trekken en de bytes zelf weer te laten geven (bijvoorbeel met hexdump).

[MSalters]

Confusion schreef op dinsdag 02 september 2008 @ 21:43:
[...]

Dat is nog maar de vraag. Het kan best zijn dat je nu een reeks bytes in je tabellen hebt staan waarvan MySql beweert dat het UTF-8 encoded is, terwijl het dat in feite helemaal niet is.
...
De snelste manier om het zeker te weten welke bytes er eigenlijk in de database staan is om de data op de command line uit de database te trekken en de bytes zelf weer te laten geven (bijvoorbeel met hexdump).

Of je bepaalt CHAR_LENGTH(country); CHAR_LENGTH('Jordanië') is 8, onafhankelijk van of het UTF-8 of ISO-8859-1 is. Maar als je per ongeluk UTF-8 bytes opgeslagen hebt in een ISO-8859-1 tabel, dan zal CHAR_LENGTH('Jordani??') 9 zijn.

[Voutloos]

.oisyn schreef op dinsdag 02 september 2008 @ 16:59:
Ik snap niet waarom mensen altijd zo zitten te kutten met de encoding van de database. Feitelijk doet die encoding er niet toe, zolang je geen string operaties in queries gaat zitten doen (die je meestal ook niet nodig hebt). Waar je gewoon voor moet zorgen is dat de invoer encoding van je (web)applicatie gelijk is aan die van de uitvoer.

Eens, maar het kan geen kwaad om alles mbt encoding op alle niveaus goed doordacht te hebben.

Het grootste probleem is gewoon dat praktisch iedereen met encoding lijkt te kutten. "Zet gewoon ff een headertje encoding X!"... "Oh, werkt dat niet? Goh dat probeer je toch een headertje Y?" etc.
Denk er eens goed overna, ben je bewust van de diverse punten waar je iets met strings doet en fix het voor eens en altijd door het gewoon te begrijpen.

[supakeen]

Ik ben het niet eens met .oisyn over dat de encoding in je database niet uit maakt. Dat maakt dus wel uit. Zeker als je gaat zoeken op je database, sorteren en dat soort gepruttel

[Confusion]

Voutloos schreef op woensdag 03 september 2008 @ 08:03:
Het grootste probleem is gewoon dat praktisch iedereen met encoding lijkt te kutten.

Er hoeft maar 1 keer 1 persoon te kutten met encoding en de komende jaren zit je met z'n allen te prutsen om er omheen te werken. Soms is 'gewoon proberen' pragmatischer dan te proberen er over na te denken. Als je een database erft waarin mensen in dezelfde tabel string met verschillende encoding hebben gestopt en dat moet blijven interacteren met bijvoorbeeld PHP applicaties, waar nergens expliciet een encoding wordt gespecificeerd, dan mag Joost weten wat er onderweg nu precies met de strings gebeurt. Bij PHP is er zelfs met de docs geen touw aan vast te knopen wat verschillende methodes met de encoding doen en als je de database niet recht kan trekken omdat die in productie staat...

Er is maar 1 oplossing: als iedereen vanaf nu zorgt dat alles altijd UTF-8 encoded is.

[.oisyn]

Charlie Murphy schreef op woensdag 03 september 2008 @ 08:06:
Ik ben het niet eens met .oisyn over dat de encoding in je database niet uit maakt. Dat maakt dus wel uit. Zeker als je gaat zoeken op je database, sorteren en dat soort gepruttel

Ik zei dan ook:

.oisyn schreef op dinsdag 02 september 2008 @ 16:59:
Ik snap niet waarom mensen altijd zo zitten te kutten met de encoding van de database. Feitelijk doet die encoding er niet toe, zolang je geen string operaties in queries gaat zitten doen (die je meestal ook niet nodig hebt).

Sorteren of zoeken met LIKE of full text searches vallen imho ook onder string operaties. Indices op strings werken dan weer wel onafhankelijk van de encoding.

Confusion schreef op woensdag 03 september 2008 @ 08:13:
Er is maar 1 oplossing: als iedereen vanaf nu zorgt dat alles altijd UTF-8 encoded is.

Inclusief je PHP scripts en templates zelf . Zijn we ook meteen van het probleem af van al die mensen die addslashes() gebruiken ipv mysql_real_escape_string(), wat onveilig is in bepaalde multibyte encodings.

[ Voor 30% gewijzigd door .oisyn op 03-09-2008 11:19 ]

[Voutloos]

Helaas, die laatstgenoemde mensen zijn gewoon te dom om escaping te begrijpen en die blijf je hoe dan ook houden.

[.oisyn]

Very true idd.

[redfox314]

zelfs als de encoding van je database goed staat moet je dan nog steeds niet html entities en(de)coden als je een text/html mimetype teruggeeft?

[.oisyn]

Natuurlijk, maar dat staat hier echt compleet los van.

[Confusion]

Sowieso moet je geen HTML entities in je database hebben staan. Dat is het in je database stoppen van iets dat niets met inhoud van de data te maken heeft, maar enkel met de presentatie.

[redfox314]

Confusion schreef op donderdag 04 september 2008 @ 11:14:
Sowieso moet je geen HTML entities in je database hebben staan. Dat is het in je database stoppen van iets dat niets met inhoud van de data te maken heeft, maar enkel met de presentatie.

Dat je dat niet in je database moet stoppen spreekt vanzelf je wil ze nog kunnen hergebruiken maar voor zover ik begreep gaf de presentatie laag het verkeerd weer en dat los je bij mijn weten niet op door de bron aan te passen.