Ik heb vanuit php een RSS pagina aangemaakt die wordt gevuld met gegevens uit mijn database. Maar wanneer er in een bericht een & teken stond dan werkte mijn RSS pagina niet meer doordat dit een teken is dat xml zelf gebruikt.

Ik heb vervolgens htmlentities toegepast en hierdoor wordt & veranderd in & en toen werkte het ineens wel. Maar wanneer iemand nu een ë teken gebruikt wordt dat vertaald naar ë en werkt mijn RSS pagina weer niet.

Nou snap ik niet waarom & wel wordt toegestaan maar ë niet. Wanneer ik het teken ë zelf intyp dan werkt het wel. In allebei de htmlcodes zit een & en een ; maar het een werkt wel en de ander niet.

Weet iemand een oplossing?
Volgens mij dekt dit de lading wel.

Bepaalde karakters dienen ge-escaped te worden binnen XML, ofwel door de HTML-entiteit te gebruiken, ofwel door het data-deel binnen een tag te omvatten door <![CDATA[ ... ]]>.
had je niet htmlspecialchars() moeten hebben in plaats van htmlentities() ?
Ivo P op 13/11/2015 17:41:12

had je niet htmlspecialchars() moeten hebben in plaats van htmlentities() ?

Voor de karakters waar het in XML voor uit maakt (', ", &, <, >) doet dat er niet toe, htmlspecialchars() en htmlentities() werken in beide gevallen hetzelfde voor deze karakters.

Wat wèl uitmaakt is welke flags (en, hoe kon het ook anders, character encoding) je gebruikt.

Dit zou(den respectievelijk) ENT_QUOTES (en UTF-8) moeten zijn.
Bedankt voor die link ik ga hem ff gebruiken. Maar toch vind ik het raar dat de ene het wel doet en de ander een probleem geeft
Thomas van den Heuvel op 13/11/2015 20:10:38

Voor de karakters waar het in XML voor uit maakt (', ", &, <, >) doet dat er niet toe, htmlspecialchars() en htmlentities() werken in beide gevallen hetzelfde voor deze karakters.

Klopt, maar het probleem gaat hier over het gebruik van ë en &euml;
Danny von Gaal op 13/11/2015 22:31:11

Bedankt voor die link ik ga hem ff gebruiken. Maar toch vind ik het raar dat de ene het wel doet en de ander een probleem geeft

Het escapen van ë is helemaal niet nodig, dus ik snap eigenlijk niet waarom je die wilt escapen.
Martin - op 14/11/2015 19:51:16
Klopt, maar het probleem gaat hier over het gebruik van ë en &euml;

Klopt, maar er bestaat verwarring rondom het precieze gebruik.

Waarschijnlijk had 'ie in de XML feed &euml; staan, dus de HTML entity van ë, en dat mag niet, alle voorkomens (of ze nu zelf onderdeel uitmaken van een entiteit of niet) van ', ", >, < en & moeten of ge-escaped worden of in een CDATA blok staan. In de feed zou dus letterlijk &amp;euml; moeten staan, maar niet &euml;. Omdat &amp; vervolgens op je scherm getoond wordt als simpelweg "&" (je zult dus de bron moeten inzien om dit na te gaan), ontstond hier mogelijk (mede) verwarring door.

Niet toegestaan ("niet ge-escapete entiteiten"):
<description>H&euml;llo!</description>


Wel toegestaan ("ge-escapete entiteiten") met of zonder <![CDATA[ ... ]]> blok:
<description>H&amp;euml;llo!</description>


Wel toegestaan (al je data in CDATA):
<description><![CDATA[H&euml;llo!]]></description>


Wel toegestaan (geen entiteiten maar gewoon de exotische symbolen) met of zonder <![CDATA[ ... ]]> blok mits de character encoding van je data klopt:
<description>Hëllo!</description>

edit, pvd gaan we weer, weer dezelfde bug.

<description>Hëllo!</description> mag wel dus.
Martin - op 14/11/2015 19:51:16

Het escapen van ë is helemaal niet nodig, dus ik snap eigenlijk niet waarom je die wilt escapen.


Van mij hoeft er helemaals omgezet te worden maar ik heb htmlentities toegepast doordat ik eerder een probleem had omdat een "&" teken er voor zorgde dat mijn RSS niet meer werkte. En wanneer ik &amp; had staan het wel werkte.

Htmlentities wordt meteen op alles toegepast dus zodoende ook die ë
en daarom dus niet htmlentities() gebruiken maar htmlspecialchars().

want die laatste laat je ë en á etc. met rust.
Om precies de reden die Ivo aangeeft is htmlspecialchars() in het algemeen "beter", je loopt dan (o.a. in XML) minder snel tegen problemen aan.
Okee ik gebruik eigenlijk altijd htmlentities uit gewoonte wist dat verschil niet maar bedankt.
Dan ga ik die toepassen en kijken of het dan wel werkt :)

Reageren