Met de handen in het haar schrijf ik nu uiteindelijk dit bericht.
Voor een website waar ik momenteel mee bezig ben heb ik de eis opgekregen om alles te laten valideren, dus ook de “gekke tekens” moeten de juiste entities in de broncode hebben.
Maar hier gaat het zo ongeveer constant mis, de tekst wordt namelijk onverandert uit de database gehaald en daarna dus geparsed (de urls omzetten naar links, de rommel omzetten naar entities), maar bij dat laatste gaat het dus steeds mis.
Vrijwel constant krijg ik de verkeerde entities terug en ik heb wel al gemerkt dat het afhankelijk is van het document-type wat je de site meegeeft.
De entities worden aangemaakt via de htmlentities() functie in PHP, maar deze geeft dus de gekste uitvoer, op een gegeven moment luktte het prima met een î bijvoorbeeld, maar inmiddels werkt dat ook al niet meer. “î” is wat ik terugkrijg.
Kan iemand mij misschien wat meer inzicht verschaffen over hoe ik dit aan zou moeten pakken, want dat gedoe met charsets e.d. maakt me stapelgek.
Bij voorbaat hartelijk dank,
edit:
[quote:ca219a6f21]<?php print ‘<?xml version=“1.0” encoding=“utf-8” ?>’ . “n”; ?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN”
“http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>
Het belangrijkste bij dit soort "problemen" is ervoor te zorgen dat er niet alleen staat welke tekenset het is maar dat de tekens ook echt op die manier gecodeerd zijn. Zowel in de database (de data in de database moet gecodeerd zijn in de tekenset waarmee je de database geconfigureerd hebt) als in de bestanden (de data in de bestanden moet gecodeerd zijn (zie je editor) in de tekenset waarmee je de webserver geconfigureerd hebt en die je in je HTML noemt).
In dit geval is dat allerlaatste blijkbaar UTF-8 de rest kunnen we van hieruit niet zien.
Als je dat goed doet, dan heb je de HTML-entities helemaal niet nodig. Dan komt namelijk alles vanzelf goed.
HTML-entities kun je gebruiken in een situatie waarin je over een of meer van deze zaken geen controle hebt. (Je hebt dan namelijk alleen een gemeenschappelijke subset van de tekens nodig.) Maar dan moet je ook echt HTML-entities al gebruiken vanuit het deel van de situatie waar je nog wel voldoende controle over de tekenset van je data hebt. Als je begint met een verschil tussen de tekenset waarin de data gecodeerd is en wat er geconfigureerd is dan kun je ook niet meer correct converteren naar HTML-entities. Je zult dan eerst de tekenset codering moeten converteren.
Het is een beetje alsof je een gif-bestand een naam met .jpg geeft. Daar wordt het ook geen jpeg-bestand van…
[quote:9ee71b944d="Yaris"][quote:9ee71b944d="dirksierd"]Met de handen in het haar schrijf ik nu uiteindelijk dit bericht.[/quote:9ee71b944d]
Hoe heb je dat gedaan? :D[/quote:9ee71b944d]
hehe, nice
@iJoost
Bedankt, je uitleg is redelijk verhelderend, hier kan ik wel wat mee
het is me tot op heden toch nog niet gelukt dit op te lossen.
overal waar je maar charset in kunt vullen staat 'ie bij mij op UTF-8, mijn editor (textmate) staat ingesteld op UTF-8, mijn mysql database heb ik ingesteld op collation: utf8_unicode_ci en ik gebruik geen htmlentities…
MAMP PRO wordt hier gebruikt om de sites op te testen, maar ik kan niet vinden wat het karakterset daarvan is.
iemand nog een aanvulling op iJoost die de doorslag kan geven?
ik denk dat er ook bij textmate het een en ander gezocht kan worden. teksten die ik verplaatst heb van de ene server naar de andere door te knippen en plakken in textmate hebben allemaal fouten wat betreft de special characters.
maar in principe zit textmate ook gewoon op utf-8 ingesteld, dus het is geschreven in utf-8, het formulier verstuurd utf-8, de database is utf-8 en de website heeft utf-8 headers mee. persoonlijk denk ik dat 't door mamp komt.. maar om alles nu weer te gaan veranderen naar iso-8859-1 heb ik weinig trek in als het niet nodig is.
