[PHP/MySQL] Rare tekens in database

[Verwijderd]

Ik ben met stomheid geslagen...

Ik heb een lokale database en een online database. Beide MySQL v4.1.9. Wanneer ik de site lokaal gebruik (met lokale DB) en vreemde tekens in de database slinger, gaat alles prima. De é blijft een é etc.

Als ik op de online versie van de site hetzelfde doe, komen de tekens als "ë" in de database. In snap er geen hol van. De collatie (whatever that is) van beide databases staat op "latin1_swedish_ci" en de online versie is geladen met een dump van de locale versie.

Hebben jullie ideeën wat dit kan veroorzaken en misschien een oplossing?

[SvEn]

de charset instelling is dan anders..

mijn voorkeur is ISO .. waarschijnlijk staat hij nu op UTF

dit moet je op je webserver instellen

[ Voor 16% gewijzigd door SvEn op 23-03-2005 14:23 ]

[NMe]

Misschien als je ze beiden in Unicode opslaat?

SvEn schreef op woensdag 23 maart 2005 @ 14:23:
dan charset instelling is dan anders..

Hij zegt net dat die hetzelfde zijn.

[ Voor 68% gewijzigd door NMe op 23-03-2005 14:23 ]

[Verwijderd]

Dat heb ik ook eens gehad, inderdaad heel erg vreemd. Volgens mij heb ik het opgelost door (bv. via phpMyAdmin) de collation opnieuw op latin1_swedish_ci te zetten. Als dat het niet is, moet ik weer even nadenken

[SvEn]

-NMe- schreef op woensdag 23 maart 2005 @ 14:23:
Misschien als je ze beiden in Unicode opslaat?


[...]

Hij zegt net dat die hetzelfde zijn.

hij zei een collatie geen charset

[BCC]

htmlentities gebruiken? Dit soort tekens wil je echt niet in je database..

[SvEn]

BCC schreef op woensdag 23 maart 2005 @ 14:26:
htmlentities gebruiken? Dit soort tekens wil je echt niet in je database..

en als je dan toch bezig bent

htmlspecialchars();
en
addslashes();
eroverheen

[Sybr_E-N]

Je hebt een verschil in je characterset. De oplossing heb ik niet voor je, maar lees de volgende topics eens door. Misschien zit er een hint/tip/oplossing voor jou tussen.

[MySQL 4.1] Fout in query
[Java/MySQL] character set probleem
[MySQL] Characterset

Ik heb hetzelfde eens ervaring, maar ik heb toen rigoreus all mijn tabellen op utf8 zet. Nooit weer problemen mee gehad.

[ Voor 12% gewijzigd door Sybr_E-N op 23-03-2005 14:28 ]

[NMe]

BCC schreef op woensdag 23 maart 2005 @ 14:26:
htmlentities gebruiken? Dit soort tekens wil je echt niet in je database..

En waarom niet? Wat denk je dat kleiner is om op te slaan in je database? é of é? Je wil juist wèl die kleine manier van opslaan in je database, en htmlentities gooi je eroverheen als je het afdrukt naar de browser.

[Verwijderd]

BCC schreef op woensdag 23 maart 2005 @ 14:26:
htmlentities gebruiken? Dit soort tekens wil je echt niet in je database..

Ik probeer nog even een nieuwe dump te maken met database compatibiliteit op "None". Zien of dat wat uitmaakt. Die tekens laat ik wel in, omdat de headers van de site (www.amant.nl) in Flash zijn. Mocht ik het niet anders kunnen oplossen, dan gaat er een htmlentities overheen

[BCC]

-NMe- schreef op woensdag 23 maart 2005 @ 14:28:
[...]
En waarom niet? Wat denk je dat kleiner is om op te slaan in je database? é of é? Je wil juist wèl die kleine manier van opslaan in je database, en htmlentities gooi je eroverheen als je het afdrukt naar de browser.

Bij storage van text voor in internetpagina is dat verwaarloosbaar. Dan kun je ook aanvoeren dat het uitvoeren van een htmlentities bij het inserten in de database efficiënter is dan het elke keer uitvoeren van een htmlentities bij het uitlezen. Punt is dat bij een & eacute; je altijd weet wat het moet zijn en bij een "ë" (voorbeeld TS) je geen enkel idee hebt.

[ Voor 21% gewijzigd door BCC op 23-03-2005 14:31 ]

[NMe]

BCC schreef op woensdag 23 maart 2005 @ 14:30:
Bij storage van text voor in internetpagina is dat verwaarloosbaar. Dan kun je ook aanvoeren dat het uitvoeren van een htmlentities bij het inserten in de database efficiënter is dan het elke keer uitvoeren van een htmlentities bij het uitlezen. Punt is dat bij een & eacute; je altijd weet wat het moet zijn en bij een "ë" (voorbeeld TS) je geen enkel idee hebt.

Wat jij nou wil doen heet symptoombestrijding. Je erkent dat er een probleem is, maar in plaats van dat probleem te fixen, wil je eromheen werken, door je karakters aan te passen voor je ze opslaat in de database. Op die manier is het probleem er nog steeds, en kun je er op elk moment tegenaan lopen. En dat terwijl het fixen van een charset probleem veel makkelijker is.

[Verwijderd]

Wat het nog vreemder maakt is dit:

Wanneer ik via phpMyAdmin een de inhoud van een veld wijzig in bijv. éëè dan worden de tekens wél goed getoond op de site. Doe ik het via het CMS (addslashes, trim) dan krijg ik dus de vreemde tekens. Ik lees even verder, maar blijf vooral mogelijke oplossingen posten.

De tabel converteren naar utf-8 hielp ook niet, overigens.

[BCC]

-NMe- schreef op woensdag 23 maart 2005 @ 14:46:
[...]
Wat jij nou wil doen heet symptoombestrijding. Je erkent dat er een probleem is, maar in plaats van dat probleem te fixen, wil je eromheen werken, door je karakters aan te passen voor je ze opslaat in de database. Op die manier is het probleem er nog steeds, en kun je er op elk moment tegenaan lopen./

Dat is wel heel kort door de bocht. Ik zie het eerder als gebruik maken van een universele charset, waardoor je al je charset problemen voorkomt. Je pagina is dan ALTIJD van server naar server te verplaatsen zonder problemen.

En dat terwijl het fixen van een charset probleem veel makkelijker is. :

Ja, dat blijkt wel uit dit topic

[ Voor 16% gewijzigd door BCC op 23-03-2005 15:06 ]

[raptorix]

BCC schreef op woensdag 23 maart 2005 @ 14:30:
[...]


Bij storage van text voor in internetpagina is dat verwaarloosbaar. Dan kun je ook aanvoeren dat het uitvoeren van een htmlentities bij het inserten in de database efficiënter is dan het elke keer uitvoeren van een htmlentities bij het uitlezen. Punt is dat bij een & eacute; je altijd weet wat het moet zijn en bij een "ë" (voorbeeld TS) je geen enkel idee hebt.

Punt is dat als je moet gaan zoeken op bepaalde termen dat je dan hard op je bek gaat.

[BCC]

raptorix schreef op woensdag 23 maart 2005 @ 15:07:
[...]
Punt is dat als je moet gaan zoeken op bepaalde termen dat je dan hard op je bek gaat.

Ja, maar TS heeft hier toch over een simpel CMSje, geen Universiteits bibliotheek?

[Verwijderd]

Website voor de regio's grootste dienstverlener. Maar Raptorix heeft een punt. Er moet wel gezocht kunnen worden op, bijvoorbeeld: diëtetiek.

Hoewel je natuurlijk ook een htmlentities op de zoekstring kunt loslaten, voordat je de database ermee bestookt

[NMe]

BCC schreef op woensdag 23 maart 2005 @ 15:08:
Ja, maar TS heeft hier toch over een simpel CMSje, geen Universiteits bibliotheek?

Ook in een simpel CMS moet je wel eens zoeken naar woorden met "rare" karakters; het Nederlands is er vol van.

BCC schreef op woensdag 23 maart 2005 @ 14:59:
Dat is wel heel kort door de bocht. Ik zie het eerder als gebruik maken van een universele charset, waardoor je al je charset problemen voorkomt. Je pagina is dan ALTIJD van server naar server te verplaatsen zonder problemen.

Ja, inclusief alle nieuwe problemen die het meebrengt. En het kan makkelijker als je gewoon je charset goed hebt staan.[/]

Ja, dat blijkt wel uit dit topic

Dus omdat er een topic over is, is het moeilijk? Ik heb wel meer topics gezien die makkelijk op te lossen waren, maar TS gewoon niet wist waar ie kijken moest. Ooit erbij stilgestaan dat dat misschien het geval is?

[BCC]

Verwijderd schreef op woensdag 23 maart 2005 @ 15:11:
Website voor de regio's grootste dienstverlener. Maar Raptorix heeft een punt. Er moet wel gezocht kunnen worden op, bijvoorbeeld: diëtetiek.
Hoewel je natuurlijk ook een htmlentities op de zoekstring kunt loslaten, voordat je de database ermee bestookt

Juist.. andere oplossing voor hetzelfde probleem dus... maar dit is verder compleet offtopic allemaal.. sorry

[Verwijderd]

Het probleem blijkt helemaal niet in de database te zitten.

Ik heb een formulier (met of zonder enctype, probleem houdt aan) en als ik de vulling daarvan post worden ze als vreemde tekens ontvangen. Als ik vervolgens de utf8_decode over alle $_POST waardes heen haal is het opgelost, maar ik vind dit wel aardig maf

Waar ligt de oorzaak hiervan?

Edit: Het probleem is opgelost

De oorzaak zat 'm in de content-type meta tag, die stond op utf-8, i.p.v. iso-8859-1. Lokaal werd deze specificatie echter lekker genegeerd. Toch bedankt voor jullie hulp/suggesties people! Hopelijk onthouden jullie dit, mocht je er zelf een keer tegenaan lopen

[ Voor 59% gewijzigd door Verwijderd op 23-03-2005 15:39 . Reden: Opgelost ]

[BtM909]

Met welke charset serveer je je pagina's?

[Verwijderd]

BtM909 schreef op woensdag 23 maart 2005 @ 15:39:
Met welke charset serveer je je pagina's?

Nu dus met:

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

En dat werkt prima

[Superdeboer]

Let me guess, de pagina waar je form op staat, wordt zélf met de UTF-8 charset geserveerd. De input van het form wordt dus ook als UTF-8 gepost. Als jij dan via phpAdmin in je database gaat kijken, zien die UTF-8 characters er raar uit, wánt die charset staat op Latin 1.

Jij zegt:

Als ik op de online versie van de site hetzelfde doe, komen de tekens als "ë" in de database.

Daar leid ik uit af dat je lokaal als standaard charset ISO-8859-1 oid hebt ingesteld, en dat dat op de online versie UTF-8 is.
Overigens, heb je ook geprobeerd om die "ë" uit de database weer uit te poepen in een pagina met een UTF-8 charset? Dat moet normalerwijs gewoon goed gaan lijkt me.


Om meerdere redenen is het op zich verstandig om de UTF-8 charset te gebruiken, omdat deze uitbreidbaar is met alle chars van allerlei internationale talen; het is een universele charset. Mocht het echter een probleem op leveren op je online site, omdat je er niet op gerekend hebt, en omdat het teveel werk kost om bepaalde dingen te fixen, zorg dán dat je overal consequent de volgende header aan *al* je pagina's meegeeft:

PHP:

header('Content-Type: text/html; charset=utf-8');

Moraal van het verhaal: zorg dat je consequent bent. Óf bij *alle* input én output UTF-8, óf bij *alle* input en output ISO-8859-1.

---

edit:

Hmmm keertje F5'en tussendoor mag ook wel.

Oscar Alexander:
Nu dus met:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
En dat werkt prima

Als je nou die header gebruikt die ik hierboven heb staan, dan kun je dat meta-element er helemaal uitgooien. Meta-elementen worden in principe overruled door zo'n header.

[ Voor 16% gewijzigd door Superdeboer op 23-03-2005 15:48 ]

[BtM909]

Superdeboer schreef op woensdag 23 maart 2005 @ 15:44:
Als je nou die header gebruikt die ik hierboven heb staan, dan kun je dat meta-element er helemaal uitgooien. Meta-elementen worden in principe overruled door zo'n header.

Het is ook veel netter om het zo te serveren. Alhoewel als TS het echt goed doet (ik zie XHTML), dan gooit hij waarschijnlijk meteen z'n grootste doelgroep overboord