[PHP] e trema decoden

[NederB]

Ik probeer de volgende hex te decoden met PHP: %EB. Dit moet dus een ë zijn.
Wat ik krijg te zien is een leuk vierkantje met een vraagteken erin: �.
Het decoden doe ik door middel van urldecode.

Er zitten ook andere hex codes tussen, waaronder %2C (komma), deze worden wel gewoon netjes weergegeven.
Ik heb bovenaan de pagina de charset utf-8 aangegeven.

Hoe kan ik die hex code nou netjes decoden met PHP?

[Janoz]

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

[Mr. Bondt]

Haal de output door utf8_encode().

[NederB]

Janoz schreef op woensdag 17 november 2010 @ 22:57:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Heb ik al gelezen.

Mr. Bondt schreef op woensdag 17 november 2010 @ 22:58:
Haal de output door utf8_encode().

Had ik al geprobeerd, werkt niet.
Er gebeurt dan helemaal niks.

[ Voor 16% gewijzigd door NederB op 17-11-2010 23:24 ]

[ValHallASW]

Als je het artikel van Joel goed had gelezen had je zelf deze set vragen kunnen bedenken:

Hoe kom je aan die %EB?
In welke encoding/representatie staat die %EB?
Wat retourneert urldecode?
In welke encoding/representatie is dat?
In welke encoding/representatie wil je het hebben?
Moet je converteren? Zo ja, welke functie heb je daar dan voor nodig?


Tip: de reden dat de komma wel goed gaat maar de ë niet heeft er mee te maken dat utf-8 en latin-1 de , op dezelfde manier representeren, maar de ë niet.

[ Voor 50% gewijzigd door ValHallASW op 18-11-2010 00:13 ]

[NMe]

NederB schreef op woensdag 17 november 2010 @ 23:11:
[...]

Heb ik al gelezen.

Lees het dan nog maar eens heel goed door want je antwoord staat er.

[NederB]

Dankzij de tip van ValHallASW heb ik het weten op te lossen.
Eerste de string door urldecode heen halen en daarna door utf8_encode.
Danku!

[Verwijderd]

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> en dan zijn alle leestekens okay.

[ValHallASW]

Verwijderd schreef op vrijdag 19 november 2010 @ 16:02:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> en dan zijn alle leestekens okay.

Fijn. Vervolgens ziet 'ie in plaats van

Юникод en iets met zee�n
krijg je dan
Юникод en iets met zeeën.

Inderdaad, een hele verbetering.

[Janoz]

@DeProfessor: Ook jou raad ik aan nog even het artikel in de tweede post te lezen.

[NMe]

Verwijderd schreef op vrijdag 19 november 2010 @ 16:02:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> en dan zijn alle leestekens okay.

That's wrong on so many levels.

Eerst content serveren en dan pas zeggen wat je serveert...en het dan ook nog eens presenteren als magische fix voor alles... Nog naast het feit dat ISO-8859-1 geen euroteken bevat en sowieso geen UTF-8 is...

[Verwijderd]

is dit wat?

mysql_set_charset('utf8', $database);

[Janoz]

Dat ligt er aan hoe het in de database zit.

[NMe]

Verwijderd schreef op vrijdag 19 november 2010 @ 16:40:
is dit wat?

mysql_set_charset('utf8', $database);

No offense, maar zomaar dingen roepen waar dan wel het woord utf8 in zit gaat ook niet helpen. Je Content-type header voor de pagina die je weer wil geven moet op UTF-8 staan, je editor moet op UTF-8 staan, je database moet op UTF-8 staan, je connectie naar de database moet op UTF-8 staan en eventueel kun je ook die meta-tag gebruiken die je zelf aanhaalde.

[ValHallASW]

NMe schreef op vrijdag 19 november 2010 @ 16:15:
Eerst content serveren en dan pas zeggen wat je serveert...

En tóch vind ik het niet zo'n gek systeem. Waarom zou de webserver immers kunnen vertellen in welke encoding het document is opgesteld? Het is een eigenschap van het document, dus vind ik het ook niet zo gek om in het document (of op een andere manier gelinkt aan het document) de encoding te definiëren.

[NMe]

ValHallASW schreef op vrijdag 19 november 2010 @ 18:51:
[...]

En tóch vind ik het niet zo'n gek systeem. Waarom zou de webserver immers kunnen vertellen in welke encoding het document is opgesteld? Het is een eigenschap van het document, dus vind ik het ook niet zo gek om in het document (of op een andere manier gelinkt aan het document) de encoding te definiëren.

Welke van de volgende twee opties vind jij fijner?

1. "Pas op, er komt een bus op je af!"
2. Nadat je overreden was: "Owja, ik wist dat er een bus op je af kwam, maar ik dacht: wacht nog maar even."

Jouw browser begint met renderen zodra hij data heeft die hij kan gebruiken om te renderen. Dat betekent dus meteen nadat je headers allemaal verstuurd zijn.

Sowieso, je kán gewoon headers versturen, dus dat zou ik gewoon altijd doen.

[Avalaxy]

Verwijderd schreef op vrijdag 19 november 2010 @ 16:40:
is dit wat?

mysql_set_charset('utf8', $database);

Zoals NMe al zegt moet alles op UTF8 staan, maar wij weten niet wat jij voor database (en connectie) gebruikt dus kunnen we hier moeilijk iets over zeggen..

Voor PDO heb je bijvoorbeeld:

code:

SET CHARACTER SET utf8

Maar ik vermoed dat je databaseschema sowieso al niet op UTF-8 staat...?

[Soultaker]

NMe schreef op vrijdag 19 november 2010 @ 16:15:
That's wrong on so many levels.

Eerst content serveren en dan pas zeggen wat je serveert..

Dat moet je die knuppels vertellen die verzonnen hebben dat de encoding voor XML documenten ook pas in de XML header zit.

[ValHallASW]

Soultaker schreef op zaterdag 20 november 2010 @ 13:29:
Dat moet je die knuppels vertellen die verzonnen hebben dat de encoding voor XML documenten ook pas in de XML header zit.

Dat doen we bij JPEG, GIF en AVI ook. De encoding is iets wat bij het bestand hoort, en hoort dus ook /bij/ het bestand. De XML header is daar de logische plaats voor!

(en er zit een groot verschil tussen een XML header en een HTML-meta tag; die meta-tag kan overal in het document staan en triggert, zoals NMe al opmerkt, een re-render. Daar is bij XML helemaal geen sprake van.

Overigens is de meta-header helemaal niet bedoeld om door de browser verwerkt te worden, maar om door de server verwerkt te worden zodat een zinnige header wordt weggeschreven.

[CyBeR]

Soultaker schreef op zaterdag 20 november 2010 @ 13:29:
[...]

Dat moet je die knuppels vertellen die verzonnen hebben dat de encoding voor XML documenten ook pas in de XML header zit.

Bij XML staat 't in een deel van het document waar bepaalde afspraken over bestaan. Zoals dat 't altijd bovenaan staat, altijd in een bepaalde character set (ik meen gewoon ascii in dit geval), en dat een document zonder dat geen geldig XML-document is. Voor HTML bestaat dat allemaal niet, wat dus een probleem is.

[Soultaker]

CyBeR schreef op zaterdag 20 november 2010 @ 16:31:
Zoals dat 't altijd bovenaan staat, altijd in een bepaalde character set (ik meen gewoon ascii in dit geval)

Nope, niet waar, dat is dus het idiote. Het staat in de header die onderdeel is van het document, dus om de encoding te kunnen lezen moet je eerst het begin decoderen waarvoor je de encoding moet weten waarvoor je eerst het begin moet decoderen... het is precies zo idioot als het lijkt.

In de praktijk gokken parsers op basis van de eerste paar bytes of ze te maken hebben met ASCII, EBCDIC, UCS-2 (twee varianten) of UCS-4 (vier varianten) proberen ze dan alleen de header te parsen en schakelen dan over naar de echte variant. Daarbij wordt er maar gemakshalve van uitgegaan dat 1-byte coderingen overlappen met ASCII of EBCDIC (geldt wel voor UTF-8 en de meeste regionale coderingen) en dat 2-byte coderingen (UTF-16) in ieder geval overlappen met het relevante deel van UCS-2. Geldt in de praktijk natuurlijk wel, maar het is in theorie een gebroken systeem.

ValHallASW schreef op zaterdag 20 november 2010 @ 16:24:
Dat doen we bij JPEG, GIF en AVI ook. De encoding is iets wat bij het bestand hoort, en hoort dus ook /bij/ het bestand. De XML header is daar de logische plaats voor!

Nee, want JPEG, GIF of AVI files worden maar op één manier gecodeerd, en die manier is vastgelegd in de specificatie (voor zover er van een formaat als AVI een specificatie is, natuurlijk). Welke character encodings er bestaan wordt niet in de XML specificatie genoemd, maar je moet 't als parser wel proberen uit te zoeken. Dus moet je maar wat gokken, want je kunt nooit uitsluiten dat er een encoding bestaat die "ABC-9" heet, waarin "ABC-9" toevallig op dezelfde manier gecodeerd wordt als "UTF-8" in UTF-8. Dat is fundamenteel gebroken.

en er zit een groot verschil tussen een XML header en een HTML-meta tag; die meta-tag kan overal in het document staan en triggert, zoals NMe al opmerkt, een re-render. Daar is bij XML helemaal geen sprake van.

De meta-tag moet in de HTML header staan, dus dan is er nog niets gerenderd lijkt me

[ Voor 47% gewijzigd door Soultaker op 20-11-2010 17:34 ]

[Herko_ter_Horst]

Soultaker schreef op zaterdag 20 november 2010 @ 17:25:
[...]

Nope, niet waar, dat is dus het idiote. Het staat in de header die onderdeel is van het document, dus om de encoding te kunnen lezen moet je eerst het begin decoderen waarvoor je de encoding moet weten waarvoor je eerst het begin moet decoderen... het is precies zo idioot als het lijkt.

Nope, niet waar, zo idioot is het niet.

W3C schreef in de XML spec:
In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly need an encoding declaration.

Als je dit koppelt aan het "gok-algoritme" in appendix E, dat jij ook beschrijft, is er weinig meer te gokken.

In elk geval is het handiger gewoon UTF-8 te gebruiken, aangezien dit zeker ondersteund is.

[ Voor 32% gewijzigd door Herko_ter_Horst op 20-11-2010 18:23 ]

[Soultaker]

Ik kan dit de hele dag doen hoor.

Herko_ter_Horst schreef op zaterdag 20 november 2010 @ 18:02:
Nope, niet waar, zo idioot is het niet.

Wellus.

Dus of de encoding moet vooraf bekend zijn gemaakt (bijv. in HTTP headers), of de encoding moet duidelijk zijn door de aanwezigheid van een BOM, of de prolog moet encoded zijn in UTF-8 (of een subset daarvan, zoals ASCII).

Dat staat er niet. Er staat dat als er geen externe informatie over de codering gegeven is, dan mag het document (1) niet gecodeerd zijn in een andere codering dan er gedeclareerd is (op zich logisch) en (2) het moet óf beginnen met een BOM, óf de encoding moet gedeclareerd worden óf de codering moet in UTF-8 zijn. Dat betekent dus dat als er geen declaratie en geen BOM is, de defaultcodering UTF-8 is. Ook dat is redelijk. Maar het laatste geval blijft over: als er wél een declaratie is dan moet je die gebruiken, maar om die te kunnen parsen moet je eerst weten welke codering er gebruikt wordt, en dus zit je wederom in de loop.

Volgens jouw logica zou je een XML document niet in EBCDIC kunnen coderen, of dan zou je de header in ASCII moeten coderen, maar er wordt expliciet genoemd dat dat niet het geval is.

Is dus geen 'gokken' maar gewoon het volgen van de spec.

Is dus wel 'gokken' in zoverre dat de spec geen listing van mogelijke encodings geeft en je dus niet kunt bepalen of je de codering goed ingeschat hebt. Nu jij weer.

edit:
Stiekum je post editten hè?!

Als je dit koppelt aan het "gok-algoritme" in appendix E, dat jij ook beschrijft, is er weinig meer te gokken.

Behalve dat dat een niet-normatief voorbeeld is en er ook geen uitputtende lijst met coderingen wordt gegeven. Ze geven daar bovendien toe dat het in z'n algemeenheid niet werkt:

In the general case, this is a hopeless situation.

[ Voor 13% gewijzigd door Soultaker op 20-11-2010 18:29 ]

[Herko_ter_Horst]

Ok, prima. Gewoon UTF-8 gebruiken dus. Problem solved

[NMe]

Herko_ter_Horst schreef op zaterdag 20 november 2010 @ 19:00:
Ok, prima. Gewoon UTF-8 gebruiken dus. Problem solved

Dat geldt inderdaad zo'n beetje voor alles. Helaas wordt er vaak op een stap die schakel doorbroken: je editor en uitvoer moeten goed staan, maar ook je databaseconnectie en -collatie. Daarnaast ook alle functies in (bijvoorbeeld) PHP, zoals htmlentities. Vooral dat laatste en de encoding van de databaseverbinding worden vaak vergeten door beginners op dit gebied.

[mrmartijn]

Je kan de characterset met PHP aanpassen in de header (voor het bestand wordt verstuurd)
<?php
header('Content-Type: UTF-8');
?>

[NMe]

mrmartijn schreef op zondag 21 november 2010 @ 00:45:
Je kan de characterset met PHP aanpassen in de header (voor het bestand wordt verstuurd)
<?php
header('Content-Type: UTF-8');
?>

Klopt, maar zoals ik in mijn vorige post al zei ben je er dan helaas nog niet.

[Onno]

NMe schreef op zondag 21 november 2010 @ 01:38:
Klopt

Ja? Werkt dat echt? Maakt php daar dan zelf iets als "text/html; charset=utf-8" van? (ik houd het niet voor onmogelijk met php..)

[NMe]

Onno schreef op zondag 21 november 2010 @ 11:49:
[...]

Ja? Werkt dat echt? Maakt php daar dan zelf iets als "text/html; charset=utf-8" van? (ik houd het niet voor onmogelijk met php..)

Ow nee, daar heb je gelijk in; de daadwerkelijke content-type is natuurlijk fout in die post. Het ging mij om het principe. Ook als je alleen header('Content-type: text/html; charset=utf-8') opneemt in je code ben je er nog niet om de redenen die ik in NMe in "[PHP] e trema decoden" noemde.