[PHP]htmlentities , UTF-8 en het -€- teken

[MuisM4t]

Om bij uit de database gehaalde tekst of html eventuele tekens te vervangen door de juiste entities gebruik ik de volgende functie.

PHP:

function addentities($string,$tags){
                                                             //punt 1
$string=htmlentities ($string, ENT_QUOTES, 'utf-8');
                                                             //punt 2
    if ($tags=='1'){
            $ent=array('>','<');
            $tekens=array('>','<');
            $string=str_replace($ent,$tekens,$string);
    }
    else{ }

return $string;
}

Echter, als ik een string met daarin een euro (€) in deze functie invoer geeft hij niets terug (Var_Dump($string) op punt 2 geeft dan string(0) ).

Var_dump($string) bij punt 1 geeft de ingevoerde string , waarin de euro is vervangen door een onbekend karakter (de euro wordt een ruitje met een vraagteken in mijn browser).

Ik weet niet goed welke conclusie ik hieruit moet trekken: is de collatie van mijn database niet goed of kan htmlentities() gewoon niet overweg met dat euro teken i.c.m. UTF-8 ?

Ik gebruik utf8_swedish_ci in mijn database.

[RobIII]

Euh, waarom zou, als je encoding UTF-8 is, er een HTML entity van het euroteken gemaakt worden?

quote: http://nl.php.net/htmlentities

...all characters which have HTML character entity equivalents are translated into these entities.

Ah; my bad Dan zie ik alleen nog niet waarom je überhaupt die entities wil gebruiken?

Is je php bestand ook als UTF-8 opgeslagen? Dit werkt namelijk bij mij gewoon:

PHP:

<?php
$string=htmlentities ('Dit is €en test', ENT_QUOTES, 'utf-8'); 
var_dump($string);
?>

Geeft:

code:

string(20) "Dit is €en test"

en, uiteraard, in de browser:

code:

string(20) "Dit is €en test"

Maak ik ANSI van het bestand dan krijg ik inderdaad het gedrag dat jij aangeeft.

Ik lees overigens ook op php.net:

quote: http://nl.php.net/htmlentities

Note that as of 5.2.5 it appears that if the input string contains a character that is not valid for the output encoding you've specified, then this function returns null.

Ik draai 5.2.0-8+etch13 dus ik weet niet hoe 'nauwkeurig' die bepaling is.

[ Voor 202% gewijzigd door RobIII op 23-12-2008 02:09 ]

[MuisM4t]

Ik gebruik dreamweaver en heb default encoding op UTF-8 staan.

[ Voor 47% gewijzigd door MuisM4t op 23-12-2008 02:05 ]

[.oisyn]

Is de charset die je output in je content-type überhaupt wel utf-8? En je invoer ook? Want een ruitje en een vraagteken klinkt niet heel erg als een utf-8 teken.
Bovendien, eens met RobIII. Waarom wil je überhaupt entities gebruiken? Vrij nutteloos imho. Tenzij je niet UTF-8 wilt uitvoeren natuurlijk.

[ Voor 8% gewijzigd door .oisyn op 23-12-2008 02:06 ]

[MuisM4t]

PHP:

addentities('Dit is €en test','1');

geeft bij mij

code:

"Dit is <?>en test

Waarom wil je überhaupt entities gebruiken?

In mijn database staat een é , die ik wil omzetten naar

code:

é

, omdat een browser daar anders moeite mee heeft en in bepaalde gevallen (XSS)

code:

<script>

code:

<script>

moet worden.

edit:
In notepad++ UTF-8 ingesteld en geupload, maar gedrag blijft hetzelfde.

overigens draai ik hier PHP 5.2.6

[ Voor 76% gewijzigd door MuisM4t op 23-12-2008 02:31 ]

[RobIII]

MuisM4t schreef op dinsdag 23 december 2008 @ 02:09:
In mijn database staat een é , die ik wil omzetten naar

code:

é

, omdat een browser daar anders moeite mee heeft.

Dan moet je eens eerst even dit gaan doorlezen en je verdiepen in het uitspugen van HTTP headers met de juiste content-type charset en aanpassen van DB settings, opslaan van bestanden in de juiste encoding etc.

Je kunt trouwens ook gewoon &eacute typen Dat geeft al een piepklein beetje aan dat je (nog) niet goed weet hoe en wat en waarom

[ Voor 21% gewijzigd door RobIII op 23-12-2008 02:21 ]

[MuisM4t]

Ik zal dat artikel morgen eens goed doorlezen.

[.oisyn]

MuisM4t schreef op dinsdag 23 december 2008 @ 02:09:
In mijn database staat een é , die ik wil omzetten naar

code:

é

, omdat een browser daar anders moeite mee heeft en in bepaalde gevallen (XSS)

Een é is onbelangrijk voor XSS.

code:

<script>

code:

<script>

moet worden.

Dat is idd belangrijk. Het frappante is dat je juist dit nou weer niet voorkomt door de opbouw van je functie. Je zet eerst alle entities om, en daarna zet je &lt; weer terug naar < en &gt naar >. Voor je daadwerkelijke doel is je functie dus compleet nutteloos. Vandaar dat ik dacht dat je puur geïnteresseerd was in speciale entities zoals idd de é.

Maar feitelijk zijn ze dus onbelangrijk voor wat je wilt, en kun je net zo goed htmlspecialchars() gebruiken, die puur en alleen die tekens aanpakt die belangrijk zijn voor het interpreteren van HTML code (met name < en >, maar ook ", ' en &)

In notepad++ UTF-8 ingesteld en geupload, maar gedrag blijft hetzelfde.

Duh, wat ik bedoelde is dat je pagina zelf als UTF-8 moet serveren, en eventuele forms in die pagina ook. Als ik een € submit via een formulier op je website en mijn browser submit dat niet als UTF-8 maar bijv. als Latin-1 naar je webserver, dan moet m'n browser maar wat verzinnen voor het euro-teken aangezien die niet in het Latin-1 charset voorkomt.

[RobIII]

Ah; nu komt de aap uit de mouw

[MuisM4t]

Ik gebruik

PHP:

addentities($string,'1')

alleen bij content waar bepaalde tags belangrijk zijn voor de opmaak van de pagina én als deze content niet door een normale gebruiker kan worden toegevoegd.

PHP:

addentities($string,'0')

gebruik ik voor de rest.

[ Voor 6% gewijzigd door MuisM4t op 23-12-2008 11:37 ]

[RobIII]

MuisM4t schreef op dinsdag 23 december 2008 @ 11:33:
Ik gebruik

PHP:

addentities($string,'1')

alleen bij content waar bepaalde tags belangrijk zijn voor de opmaak van de pagina én als deze content niet door een normale gebruiker kan worden toegevoegd.

PHP:

addentities($string,'0')

gebruik ik voor de rest.

addentities En waarom is die tweede parameter een string

Oh wacht; zie TS

[ Voor 7% gewijzigd door RobIII op 23-12-2008 11:39 ]

[MuisM4t]

PHP:

function addentities($string,$tags){
                                                             //punt 1
$string=htmlentities ($string, ENT_QUOTES, 'utf-8');
                                                             //punt 2
    if ($tags=='1'){
            $ent=array('>','<');
            $tekens=array('>','<');
            $string=str_replace($ent,$tekens,$string);
    }
    else{ }

return $string;
}
?>

edit:
Maar even samenvattend: dit "gerommel" komt door inconsequent gebruik van de juiste doctype: consequent gebruiken van utf-8 in database, server headers en in de html zou het oplossen ?

[ Voor 19% gewijzigd door MuisM4t op 23-12-2008 11:41 ]

[TheRookie]

@RobIII: addentities

edit:
Na RobIII'sedit is m'n post helemaal overbodig

[ Voor 27% gewijzigd door TheRookie op 23-12-2008 11:52 ]

[.oisyn]

MuisM4t schreef op dinsdag 23 december 2008 @ 11:33:
Ik gebruik

PHP:

addentities($string,'1')

alleen bij content waar bepaalde tags belangrijk zijn voor de opmaak van de pagina én als deze content niet door een normale gebruiker kan worden toegevoegd.

Dus dan is het gebruik van addentities nutteloos. Het enige dat je doet is idd dingen als é omzetten, maar als je er gewoon voor zorgt dat alles UTF-8 is dan hoeft dat niet meer.

PHP:

addentities($string,'0')

gebruik ik voor de rest.

Maar die doet niets . Of ben je niet volledig geweest bij het posten van je functie?

Waarom zet je de 0 en de 1 trouwens tussen quotes?

MuisM4t schreef op dinsdag 23 december 2008 @ 11:37:
Maar even samenvattend: dit "gerommel" komt door inconsequent gebruik van de juiste doctype: consequent gebruiken van utf-8 in database, server headers en in de html zou het oplossen ?

Ja. Feitelijk doet het er niet eens toe wat je database is, dat is alleen belangrijk als je stringbewerkingen in je database gaat doen (sorteren, substrings vormen, etc.), en zelfs dan maakt het niet echt uit. Voor vergelijkingen (WHERE username = 'MuisM4t') gaat de database toch niet proberen de string te interpreteren, die gaat alleen de binaire data vergelijken. Dus als je zorgt dat wat je erin stopt altijd dezelfde charset heeft, dan maakt het eigenlijk niet eens uit wat de database denkt wat voor charset het is.

Verder moet je ervoor zorgen dat de content-type van je pagina "text/html; charset=utf-8" is. Door een header() uit te schrijven middels PHP of apache goed te configgen. Eventueel zou je ook

HTML:

<meta http-equiv="Content-type" content="text/html; charset=utf-8">

In de <head> van je document kunnen zetten. Verder is het denk ik verstandig om op <form> elementen een accept-charset="utf-8" te zetten.

[ Voor 59% gewijzigd door .oisyn op 23-12-2008 12:47 ]

[Voutloos]

.oisyn schreef op dinsdag 23 december 2008 @ 12:20:
Maar die doet niets

Jawel, dan gebeurt enkel de htmlentities().

Maar goed, addentities is gewoon een wazige, onnodige functie. Nofi, maar TS moet gewoon eerst het encoding en escaping verhaal goed tot zich nemen alvorens met deze encoding spaghetti door te gaan.

[Krooswijk.com]

Ik zou hier ook nog even graag op inhaken. Heb dit soort topic al een aantal maal voorbij zien komen. En uiteraard Joel's stuk ook al gelezen. Toch lijkt het bij mij "niet altijd" te werken.

Ik zet de juiste META tag, en geef de juiste Content-Type header mee. En stel ik heb een database met character set: utf8 en collation: utf8_unicode_ci.

Nu komt het soms toch nog voor dat tekens niet goed worden weergegeven. Ik lost het altijd op door de php functie utf8_encode() te gebruiken bij het weergeven van de tekst. Maar dit is meer een workaround dan de juiste oplossing.

Ik kan het nu niet testen, maar uit Oisyn's reactie zie ik dat ook <form accept-charset="UTF-8"> nog van belang is. Maar zou er verder nog iets kunnen zijn dat ik over het hoofd zie dan?

[.oisyn]

Voutloos schreef op dinsdag 23 december 2008 @ 12:24:
[...]
Jawel, dan gebeurt enkel de htmlentities().

Ah ja natuurlijk

Krooswijk.com schreef op dinsdag 23 december 2008 @ 12:29:
Ik kan het nu niet testen, maar uit Oisyn's reactie zie ik dat ook <form accept-charset="UTF-8"> nog van belang is. Maar zou er verder nog iets kunnen zijn dat ik over het hoofd zie dan?

Ik heb m'n post inmiddels geedit. Maar weet je zeker dat je input fout is, en niet dat een van PHP's functies roet in het eten gooit? Want als je bijv. htmlentities() doet en je geeft geen charset mee, dan verneukt ie dus nogal wat tekens. Een € wordt dan â�¬. Gewoon htmlspecialchars() aanroepen (zonder expliciete charset) doet ook wonderen, aangezien die sowieso alle niet-ascii tekens met rust laat, waardoor ie de utf-8 encoding niet verneukt

[ Voor 72% gewijzigd door .oisyn op 23-12-2008 13:08 ]

[wackmaniac]

Krooswijk.com schreef op dinsdag 23 december 2008 @ 12:29:
Ik zet de juiste META tag, en geef de juiste Content-Type header mee. En stel ik heb een database met character set: utf8 en collation: utf8_unicode_ci.

Is je databaseverbinding dan ook ingesteld op UTF-8?

[ Voor 48% gewijzigd door wackmaniac op 23-12-2008 12:59 ]

[Krooswijk.com]

Heb even kunnen checken en m'n database staat als volgt ingesteld:

MySQL Karakterset: UTF-8 Unicode (utf8)
MySQL verbindingscollatie: utf8_general_ci

Dit gaat niet over de databases, maar echt over de connectie. Zou het dus niet kunnen zijn. Ik kom er later nog op terug. Wil het voor eens en altijd in m'n hoofd hebben.

[vorlox]

Doe voor de zekerheid als eerste query in Mysql eens

SQL:

SET names utf8