login  Naam:   Wachtwoord: 
Registreer je!
 Forum

Vreemde tekens in database

Offline Dark_Paul - 06/12/2007 13:14
Avatar van Dark_PaulPHP ver gevorderde Goedemiddag,
Ik zit met het volgende probleem. Ingevulde formulierinformatie trim ik eerst, dan haal ik er addslashes overheen, alvorens het in de database te stoppen.
Bij het ophalen worden respectievelijk stripslashes, htmlentities en nl2br er overheen gehaald.
Enig probleem, vreemde tekens als ü, ë etc worden niet goed weergegeven.
Ze worden weergegeven als ü enzo. Het probleem ligt niet bij de htmlentitities, want ü wordt in de bron keurig als ü geschreven.
Het probleem zit in de database. Als ik een dergelijk teken invoer, wordt die als ü in de database gezet.
De database gebruikt gewoon de standaard collatie, latin1_swedish_ci. Ik heb al geprobeerd om 'm op UTF8_ci te zetten, maar zonder succes.
Een mogelijkheid is om htmlentities te gebruiken voordat ik de gegevens invoer in de database, maar dat is niet erg praktisch.
Wat kan ik hier aan doen?

7 antwoorden

Gesponsorde links
Offline citroen - 06/12/2007 13:16 (laatste wijziging 06/12/2007 13:17)
Avatar van citroen Onbekend htmlentities uitvoeren alvorens je het in de database steekt. Wat is daar niet praktisch aan, dat is de enige en beste oplossing
Offline Dark_Paul - 06/12/2007 13:25
Avatar van Dark_Paul PHP ver gevorderde Als je gegevens dan uit de database haalt om bijvoorbeeld te wijzigen, dan zijn alle speciale tekens al omgeschreven.
Bijvoorbeeld de beheerder die de mededeling wil wijzigen. Hij heeft er zelf de ballen verstand van en zal dus niet snappen als er in zijn textarea ineens 'ü' staat.
Bovendien, als hij 'ü' laat staan (in de veronderstelling dat dit dan ü moet zijn), zal die '&' weer worden omgezet, wat erin resulteert dat de bezoeker letterlijk 'ü' op zijn scherm krijgt ipv. de ü.
Ik heb ook wat gezocht via Google, daarmee kwam ik uit op een topic op GoT. Wat daar iemand zei:
Citaat:
htmlentities/htmlspecialchars (de laatste is meestal voldoende) is een encoding die je gebruikt voor output naar HTML, niet om SQL-input te escapen. Slechts in speciale gevallen kan het zinvol zijn je data al HTML-encoded in de DB op te slaan, maar doorgaans kan je encoding beter doen op het moment dat je ook daadwerkelijk data output.
Offline Vincjenzo - 06/12/2007 13:33 (laatste wijziging 06/12/2007 13:35)
Avatar van Vincjenzo Nieuw lid
Citaat:
htmlentities uitvoeren alvorens je het in de database steekt. Wat is daar niet praktisch aan, dat is de enige en beste oplossing

Niet echt mee eens. Ik zou je collatie veranderen, dan kan je later misschien je data nog ergens anders voor gebruiken, bijvoorbeeld in.. access formulieren ofzo, zonder dat je daar moet uitzoeken hoe je de entities moet decoderen.
Offline citroen - 06/12/2007 13:45
Avatar van citroen Onbekend der bestaat ook nog zoiets als PHP.net: html-entity-decode
Offline Vincjenzo - 06/12/2007 14:37
Avatar van Vincjenzo Nieuw lid Ja dat bestaat inderdaad.

Stel even voor ik ga zoeken naar naam in mijn database:

table a:
id naam
1 ëwout

select * from a where naam like '%ewout%'
1 result

html entities opgeslagen:
table a:
id naam
1 ëwout

select * from a where naam like '%ewout%'
MySQL returned an empty result set (i.e. zero rows)
Offline ikkedikke - 06/12/2007 16:18
Avatar van ikkedikke PHP expert je moet eens kijken naar de charset van je mysql verbinding. als je die op utf-8 kan krijgen, zal het waarschijnlijk goed gaan.
Offline Dark_Paul - 06/12/2007 19:23
Avatar van Dark_Paul PHP ver gevorderde Ik ben toch niet voor om eerst htmlentities uit te voeren, alvorens het in de database te zetten.

@Ikkedikke
Ik bekijk het even via PHPMyAdmin, daarin staan de MySQL Karakterset en MySQL Verbindingscollatie allebei op UTF-8 Unicode.
Ook het veld in de database heb ik als tekenset utf8_unicode_ci gegeven, zonder succes. Opnieuw een bericht gepost, zonder resultaat..
Gesponsorde links
Dit onderwerp is gesloten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.195s