[PHP] Echo na escapen

[VR46]

Ik zit een tijdje al met een prangende vraag waar ik nooit echt antwoord op heb kunnen vinden, maar nu ben ik het zat

Het lukt mij maar niet om strings die ik dmv mysqli_real_escape_string ge-escaped in de database heb gezet, op een fatsoenlijke manier te echo-en.. Ik vraag me nou toch echt af wat ik verkeerd doe want ik heb nogal veel geprobeerd.. Google leverde me helaas ook weinig nuttigs op..

Inserten doe ik als volgt:
$resource->real_escape_string($string);

Parsen doe ik over het algemeen zo:
htmlentities($string, ENT_QUOTES);

Toch krijg ik telkens weer, ongeacht de manier waarop ik de string probeer te echo-en, dingen als één te zien in plaats van één.

Wat doe ik verkeerd??
Alvast ontzettend bedankt!

[Osiris]

Die "één" die je schreef heeft te maken met Unicode, hoogst waarschijnlijk UTF-8. Oftewel, de charset van je data.

[pedorus]

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

[VR46]

De charset van mijn data is inderdaad UTF-8, maar helaas heb ik er na het lezen van het artikel nog steeds niet veel van begrepen waarom de tekens anders worden geparsed
Ach 't is al laat, morgen weer een dag, misschien dat ik er dan meer van begrijp. Maar enige hints zijn uiteraard welkom Of gewoon wat ik moet doen, dan weet ik dat ook weer..

[Osiris]

""Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for a lifetime."

Het bovenstaande artikel simpelweg begrijpen is toch wel key tot het antwoord hier. Verder zou je natuurlijk ook zelf op zoek kunnen gaan wat er allemaal te vinden is over PHP+UTF-8

[NMe]

cbernardini schreef op zaterdag 17 april 2010 @ 01:52:
De charset van mijn data is inderdaad UTF-8, maar helaas heb ik er na het lezen van het artikel nog steeds niet veel van begrepen waarom de tekens anders worden geparsed

Het heeft niks met parsen te maken. Je browser begrijpt gewoon niet hoe hij die karakters weer moet geven omdat je charsets elkaar tegenspreken. Sla je php-files, als UTF-8 (is een optie in elke goede editor), geef je HTML een goede Content-Type ("text/html; charset=utf-8" voor HTML 4), geef for good measure het content-type ook mee als metatag en zorg dat je database in UTF-8 staat. En als je een keer écht geen controle over je input hebt: http://nl2.php.net/utf8_encode

[VR46]

NMe schreef op zaterdag 17 april 2010 @ 08:33:
[...]

Het heeft niks met parsen te maken. Je browser begrijpt gewoon niet hoe hij die karakters weer moet geven omdat je charsets elkaar tegenspreken. Sla je php-files, als UTF-8 (is een optie in elke goede editor), geef je HTML een goede Content-Type ("text/html; charset=utf-8" voor HTML 4), geef for good measure het content-type ook mee als metatag en zorg dat je database in UTF-8 staat. En als je een keer écht geen controle over je input hebt: http://nl2.php.net/utf8_encode

Ik vind het maar vreemd, de content types van de html-pagina's zijn als volgt en dat lijkt me gewoon in orde?

code:

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

Verder staat de data in de database ook gewoon ingesteld op utf8-unicode.. Ik zou niet echt weten wat er verder moet worden gedaan.. Beetje jammer als ik nu elke keer utf8_encode moet gebruiken in plaats van dat dat automatisch gaat

[hostname]

Is je database connectie ook utf8? php.net/mysql_set_charset. Laat phpMyAdmin de data wel goed zien?

[Voutloos]

Die meta header mag, maar de HTTP header is het belangrijkst.

Blijkbaar zit er op een bepaalde punt toch een verkeerde aanname qua encoding, dus je zal moeten debuggen tot je zeker weet waar het fout gaat.

Overigens, als utf8_encode het fixt, betekent dat juist dat je daarvoor nog geen utf8 had.

[VR46]

Voutloos schreef op zaterdag 17 april 2010 @ 12:40:
Die meta header mag, maar de HTTP header is het belangrijkst.

Blijkbaar zit er op een bepaalde punt toch een verkeerde aanname qua encoding, dus je zal moeten debuggen tot je zeker weet waar het fout gaat.

Overigens, als utf8_encode het fixt, betekent dat juist dat je daarvoor nog geen utf8 had.

Ik heb zojuist gezien dat mijn huisgenoot altijd met latin1 werkt en dat het daar een stuk beter mee gaat zonder al het gedoe wat er met utf8 bij komt kijken (voor zover ik tot nu toe heb begrepen).. Is het wellicht een wat makkelijkere oplossing om voor die charset te kiezen?

utf8_encode fixt het trouwens niet....

[ Voor 3% gewijzigd door VR46 op 17-04-2010 13:22 ]

[Verwijderd]

Het is helemaal geen gedoe. Je moet gewoon begrijpen wat je aan het doen bent.

Als er méér "tekens" worden weergegeven dan de bedoeling is, durf ik 99% zeker te zeggen dat de content UTF-8 is maar dat er in de HTTP headers wordt aangegeven dat het ISO-8859-1 is.

En in dat geval is de oplossing:

PHP:

header ( 'Content-Type: text/html; charset=utf-8' );

Het kan ook dat je nog even de query SET NAMES 'utf8' moet uitvoeren direct na het verbinden, maar ik gok dat dat het probleem hier niet is.

[ Voor 20% gewijzigd door Verwijderd op 17-04-2010 13:28 ]

[VR46]

Verwijderd schreef op zaterdag 17 april 2010 @ 13:27:
Het is helemaal geen gedoe. Je moet gewoon begrijpen wat je aan het doen bent.

Als er méér "tekens" worden weergegeven dan de bedoeling is, durf ik 99% zeker te zeggen dat de content UTF-8 is maar dat er in de HTTP headers wordt aangegeven dat het ISO-8859-1 is.

En in dat geval is de oplossing:

PHP:

header ( 'Content-Type: text/html; charset=utf-8' );

Het kan ook dat je nog even de query SET NAMES 'utf8' moet uitvoeren direct na het verbinden, maar ik gok dat dat het probleem hier niet is.

Oke ik zal even een beeld geven zoals het nu precies is:
Aan het begin van de pagina:

PHP:

session_start();
header("Content-Type: text/html; charset=UTF-8");
$link = new mysqli ($hostname, $username, $password, $database);
$link->query("SET NAMES 'utf8'");

Aan het begin van de html:

HTML:

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

Invoeren in de database doe ik zo:

PHP:

$link->real_escape_string($_POST['string']);

Ophalen en weergeven:

PHP:

htmlentities($row['string'], ENT_QUOTES);

Ik heb ook geprobeerd het volgende in de htaccess te zetten:

code:

AddDefaultCharset utf-8

...en dit alles lijkt niet te werken... Ik heb echt al heel veel documentaties doorgenomen hoe het van inserten tot weergeven zou moeten maar het werkt allemaal niet. Ik doe ergens iets fout maar ik weet echt niet waar

[NMe]

Ik noem in mijn vorige post toch echt nog twee andere dingen die ook als UTF-8 opgeslagen moeten worden.

[VR46]

NMe schreef op zaterdag 17 april 2010 @ 13:41:
Ik noem in mijn vorige post toch echt nog twee andere dingen die ook als UTF-8 opgeslagen moeten worden.

Wat dan? Alsjeblieft niet zo cryptisch, anders kunnen ze me binnenkort opnemen in de kliniek

[Verwijderd]

Probeer nou gewoon te begrijpen wat je aan het doen bent. Je maakt de klassieke fout om maar te gaan kloten met alles wat je op internet kunt vinden, om maar niet zelf te hoeven begrijpen wat een character set precies inhoudt. Als je dat namelijk begrijpt, stelt dit niets meer voor.

En ja, het kan zijn dat je data verkeerd in de database staat. Dat is niet heel ondenkbaar als je "maar wat doet".

[NMe]

cbernardini schreef op zaterdag 17 april 2010 @ 13:46:
[...]

Wat dan? Alsjeblieft niet zo cryptisch, anders kunnen ze me binnenkort opnemen in de kliniek

Ik ben niet cryptisch, ik zeg in mijn vorige post letterlijk dat ook je PHP-files opgeslagen horen te zijn als UTF-8 én je databasecollatie op UTF-8 moet staan. Ik snap best dat je geërgerd bent dat dit allemaal niet in één keer goed gaat, maar neem dan op zijn minst de moeite om te proberen de antwoorden die je krijgt te lezen en te begrijpen.

[VR46]

NMe schreef op zaterdag 17 april 2010 @ 14:11:
[...]

Ik ben niet cryptisch, ik zeg in mijn vorige post letterlijk dat ook je PHP-files opgeslagen horen te zijn als UTF-8 én je databasecollatie op UTF-8 moet staan. Ik snap best dat je geërgerd bent dat dit allemaal niet in één keer goed gaat, maar neem dan op zijn minst de moeite om te proberen de antwoorden die je krijgt te lezen en te begrijpen.

Sorry, ik doe echt mijn best maar ik heb hier helaas nog niet veel kaas van gegeten.. Of de php bestanden ook als UTF-8 worden opgeslagen, tja hoe kan ik dat nagaan? Ik gebruik Dreamweaver CS4 als editor en ik heb niet echt kunnen vinden hoe ik dat kan nagaan. De databasecollatie staat in ieder geval gewoon op UTF-8.

[ Voor 3% gewijzigd door VR46 op 17-04-2010 14:15 ]

[RobIII]

cbernardini schreef op zaterdag 17 april 2010 @ 14:15:
Ik gebruik Dreamweaver CS4 als editor en ik heb niet echt kunnen vinden hoe ik dat kan nagaan.

Dat was wel 2 hele seconden googlen. Voila.

[ Voor 24% gewijzigd door RobIII op 17-04-2010 14:25 ]

[Verwijderd]

data

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

enc-h

a

c

e

g

i

k

m

o

q

s

u

w

y

b

d

f

h

j

l

n

p

r

t

v

x

z

enc-w

a

d

g

j

m

p

s

v

y

b

e

h

k

n

q

t

w

z

c

f

i

l

o

r

u

x

Wat staat hier?

code:

17 3 19 19 8, 12 8 22 19 15!

Wat moet je hiervoor dus weten?

Wat staat hier?

code:

wgccv, hvlcq!

Wat is hier dus verkeerd gegaan?

Wat staat hier?

code:

12 4 2 2 24, 17 24 19 2 9

En wat staat hier?

code:

hjddr, wrcdy!

Het zuiver op toeval berustende feit dat uitgerekend "h" en "w" uitwisselbaar zijn, maakt dit voorbeeld misschien nog wel beter gepast dan ik vooraf dacht. De "a" wordt hier nooit verkeerd vertaald.

Hopelijk zie je zo ook in dat het "klooien met wat functies" je nergens gaat brengen als je niet weet wat er nou met welke encoding is opgeslagen. Problemen stapelen zich alleen maar op.

[VR46]

RobIII schreef op zaterdag 17 april 2010 @ 14:24:
[...]

Dat was wel 2 hele seconden googlen. Voila.

Bedankt, heb het nagekeken en ook dat staat goed...

Hopelijk zie je zo ook in dat het "klooien met wat functies" je nergens gaat brengen als je niet weet wat er nou met welke encoding is opgeslagen. Problemen stapelen zich alleen maar op.

Het wordt dus met UTF-8 opgeslagen...

[ValHallASW]

heb je niet utf8_encode(latin1_decode(utf8_encoded_string)) opgeslagen in je database?

[Verwijderd]

ValHallASW schreef op zaterdag 17 april 2010 @ 14:47:
heb je niet utf8_encode(latin1_decode(utf8_encoded_string)) opgeslagen in je database?

Dat was dus het punt van mijn vorige post, maar dat wordt afgedaan met "het is UTF-8". Blijkbaar weet hij alles vrij zeker

[VR46]

Verwijderd schreef op zaterdag 17 april 2010 @ 14:53:
[...]

Dat was dus het punt van mijn vorige post, maar dat wordt afgedaan met "het is UTF-8". Blijkbaar weet hij alles vrij zeker

In de categorie: volk dat zichzelf de hemel in prijst als ze ergens meer vanaf weten dan een ander... Typisch. Help me anders gewoon liever niet (aan jou de keuze om op reply te drukken).

[Verwijderd]

Jij hebt niet binnen 4 minuten mijn post gelezen, begrepen én uitgezocht of de content in jouw database correct is. Jij ziet alleen maar een veldje in phpMyAdmin dat zegt dat de tabel UTF-8 "is".

Ik heb iets méér moeite gedaan om die post te tikken, dan jij hebt gedaan om hem te lezen. Je hebt de vragen niet uitgewerkt, hebt nog altijd geen benul van wat je aan het doen bent, en blijft dus dom.

Dus ja, ik prijs mezelf inderdaad de hemel in omdat ik iets begrijp. Dat betekent namelijk dat ik de moeite tenminste heb genomen. Nu weet je ook meteen tot welk soort volk jij dan behoort. Tot het soort dat een grote waffel heeft als het antwoord meneer niet goed genoeg uitkomt.

[VR46]

Verwijderd schreef op zaterdag 17 april 2010 @ 15:19:
Jij hebt niet binnen 4 minuten mijn post gelezen, begrepen én uitgezocht of de content in jouw database correct is. Jij ziet alleen maar een veldje in phpMyAdmin dat zegt dat de tabel UTF-8 "is".

Ik heb iets méér moeite gedaan om die post te tikken, dan jij hebt gedaan om hem te lezen. Je hebt de vragen niet uitgewerkt, hebt nog altijd geen benul van wat je aan het doen bent, en blijft dus dom.

Dus ja, ik prijs mezelf inderdaad de hemel in omdat ik iets begrijp. Dat betekent namelijk dat ik de moeite tenminste heb genomen. Nu weet je ook meteen tot welk soort volk jij dan behoort. Tot het soort dat een grote waffel heeft als het antwoord meneer niet goed genoeg uitkomt.

Hier heb ik geen zin in en hier wil ook absoluut niet mn topic mee vervuilen. Enige wat ik erover wil zeggen is dat er mensen op deze aardkloot zijn die er toch écht minder vestand van hebben dan jij en er dus meer tijd voor nodig hebben om het te begrijpen. Als jij daar het geduld niet voor hebt, geloof ik dat er genoeg andere topics op GoT zijn waar jij je heil kan zoeken. Als jij vind dat je meer aandacht in je posts steekt dan ik er aan besteed ze te lezen, wees dan ook zo professioneel anderen niet de grond in te stampen. Au revoir, aub.

// Edit: ik heb overigens niets anders dan posts met negatieve ondertoon van je gelezen, niet alleen in dit topic. Doe me dus een lol en antwoord alsjeblieft niet meer op dit topic.

[ Voor 12% gewijzigd door VR46 op 17-04-2010 15:29 ]

[ValHallASW]

cbernardini schreef op zaterdag 17 april 2010 @ 15:24:
Enige wat ik erover wil zeggen is dat er mensen op deze aardkloot zijn die er toch écht minder vestand van hebben dan jij en er dus meer tijd voor nodig hebben om het te begrijpen.

Ja. Neem dan ook de tijd om het te begrijpen, ipv terug te komen met het bericht 'het werkt nog steeds niet!!!1111oneoneone'. Het is niet moeilijk om te begrijpen. Je moet er alleen wel het geduld voor hebben.

Joel on Code heeft een goede beschrijving. Cheetah geeft een goede beschrijving. Voor beiden geldt wel: zorgvuldig lezen, en zorgen dat je het snapt.

Encoding-problemen los je, zoals ook al eerder vermeld, niet op door te roepen 'HELP' of door maar wat aan te klooien, maar door je te beseffen waar je mee bezig bent. Wat staat waar hoe opgeslagen?

[ Voor 21% gewijzigd door ValHallASW op 17-04-2010 15:54 ]

[VR46]

Even een nieuwe reply om weer met een goeie start te beginnen. Hopelijk is dat mogelijk! Ik zal m'n best doen de dingen aandachtig door te lezen. Op dit gebied ben ik echter een beetje 'traag van begrip', toegegeven.

Ik heb dit artikel doorgelezen, en bij de sectie Valkuilen, staat dat als je mysql_client_encoding() oproept, er meestal latin1 uit komt. Ik heb dit geprobeerd met $link->client_encoding() en ik krijg inderdaad latin1 te zien. Het artikel zegt echter dat dit een bug zou zijn, maar in hoeverre is dat correct? Als dat klopt, is daar een workaround voor?

Ik heb overigens ook gekeken hoe de data in de database terecht komt, en dat ziet er goed uit, precies zoals het hoort. Dat heb ik getest met de Iñtërnâtiônàlizætiøn-string.

[ Voor 26% gewijzigd door VR46 op 17-04-2010 16:00 ]

[ValHallASW]

cbernardini schreef op zaterdag 17 april 2010 @ 15:56:
Ik heb overigens ook gekeken hoe de data in de database terecht komt, en dat ziet er goed uit, precies zoals het hoort. Dat heb ik getest met de Iñtërnâtiônàlizætiøn-string.

Hoe heb je getest of het goed in de database terechtkomt?

[VR46]

ValHallASW schreef op zaterdag 17 april 2010 @ 16:05:
[...]

Hoe heb je getest of het goed in de database terechtkomt?

In de tabellen in phpmyadmin gekeken, is dat niet de goede manier om die conclusie te kunnen trekken?

//Edit: Ik heb nu even de header("Content-Type: text/html; charset=UTF-8"); weggehaald, en ook de $link->query("SET NAMES 'utf8'"); en nu lijkt het ineens te werken.... Wou dat ik begreep waarom...

[ Voor 26% gewijzigd door VR46 op 17-04-2010 16:17 ]

[ValHallASW]

cbernardini schreef op zaterdag 17 april 2010 @ 16:09:
[...]

In de tabellen in phpmyadmin gekeken, is dat niet de goede manier om die conclusie te kunnen trekken?

Als je naar de letters gekeken hebt: nee, want je weet niet wat phpmyadmin ermee heeft gedaan. Je hebt het liefste de byte-representatie van de string zoals 'ie wordt opgeslagen, maar ik geloof niet dat pma dat kan.

Overigens is die internationalization-string nogal brak: alle tekens kunnen ook in latin-1 gerepresenteerd worden. Als je het per sé op deze manier wilt testen: stop er wat niet-latin-1-tekens tussen (cyrillisch, grieks, japans, whatever).

cbernardini schreef op zaterdag 17 april 2010 @ 16:09:
[...]
//Edit: Ik heb nu even de header("Content-Type: text/html; charset=UTF-8"); weggehaald, en ook de $link->query("SET NAMES 'utf8'"); en nu lijkt het ineens te werken.... Wou dat ik begreep waarom...

ValHallASW schreef op zaterdag 17 april 2010 @ 14:47:
heb je niet utf8_encode(latin1_decode(utf8_encoded_string)) opgeslagen in je database?

[ Voor 45% gewijzigd door ValHallASW op 17-04-2010 16:19 ]

[Voutloos]

Test nou waar het fout gaat. Maak desnoods een minimale testcase. Test ook met en zonder die htmlentities, en kijk aub naar die functie in de docs, want hij heeft een 3e
param genaamd $charset .

[VR46]

Helaas, het gaat wéér fout, terwijl ik niets heb veranderd sinds het die ene keer goed ging....

Dank voor je antwoord over htmlentities, dat is me inderdaad ontgaan. Ik zie nu dat als ik htmlentities($string, ENT_QUOTES, 'UTF-8'); gebruik, de string goed wordt getoond. Zonder lukt dat niet. Het lijkt me dus dat PHP een verkeerde charset als standaard heeft ingesteld, aangezien ik geloof dat er niet telkens 'UTF-8' als derde parameter hoeft te worden meegegeven als je default charset UTF-8 is, of zie ik dat verkeerd?

Als je naar de letters gekeken hebt: nee, want je weet niet wat phpmyadmin ermee heeft gedaan. Je hebt het liefste de byte-representatie van de string zoals 'ie wordt opgeslagen, maar ik geloof niet dat pma dat kan.

Ik merk dat als ik $link->query("SET NAMES 'utf8'"); niet gebruik, de tekens ook in phpmyadmin 'verkeerd' komen te staan. Als ik dat wel gebruik, komt de string zoals hij hoort in de database te staan. Dat is toch een redelijk goed bewijs lijkt me? Maar hoort het niet ook te kunnen zonder $link->query("SET NAMES 'utf8'"); als de collatie van de database op utf8 staat, of heeft dat weer ergens anders mee te maken?

[ Voor 111% gewijzigd door VR46 op 17-04-2010 17:46 ]

[Shapeshifter]

Misschien is dit een overbodige opmerking, maar als je de informatie die je in de database wilt krijgen via een formulier als UTF-8 ingevuld hebt en vervolgens via POST hebt doorgegeven moet je eerst utf8_decode() toepassen voordat je het (al dan niet met mysq_real_escape_string()) in een UTF-8 database kunt zetten (ervan uitgaande dat je niet aan de accept-charset optie van een form hebt gesleuteld).

Dit geldt overigens ook voor echo'en naar je scherm. Als je informatie uit een formulier wilt echo'en doe je dat zo:

PHP:

echo htmlentities(utf8_decode([hier je variabele]));

Edit:
Oh, en natuurlijk niet de goede header vergeten, deze is voor XHTML 1.0 Strict

XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Jouw titel</title>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />

[ Voor 25% gewijzigd door Shapeshifter op 17-04-2010 20:06 ]

[cariolive23]

Shapeshifter schreef op zaterdag 17 april 2010 @ 20:04:
Misschien is dit een overbodige opmerking, maar als je de informatie die je in de database wilt krijgen via een formulier als UTF-8 ingevuld hebt en vervolgens via POST hebt doorgegeven moet je eerst utf8_decode() toepassen voordat je het (al dan niet met mysq_real_escape_string()) in een UTF-8 database kunt zetten (ervan uitgaande dat je niet aan de accept-charset optie van een form hebt gesleuteld).

Onzin.

Waarom zou je utf8-content die je als utf wilt opslaan in een utf8-database gaan decoden? En in welk formaat zou je dit dan willen encoden? utf8 zal het niet worden, dat is het namelijk al. Wanneer je óveral utf8 gebruikt, hoef je helemaal niets te doen om het correct in de database op te slaan en later weer correct op te halen. Dit werkt al járen goed, ik heb echt nog nooit utf8_decode() gebruikt op utf8-content en heb helemaal nooit problemen. En die keren dat er een probleem is, heb ik een verkeerde set gekozen in m'n html-pagina. Stomme fout, kan gebeuren en is gelukkig bijzonder eenvoudig op te lossen.

Beveiligen tegen SQL-injection is onmisbaar en mag je nooit vergeten, maar staat los van de characterset problemen.

[Shapeshifter]

Hmm, ik heb databases die UTF-8 gebruiken en een website die een UTF-8 header heeft en daar heb ik wel degelijk utf8_decode() bij nodig anders werkt het niet en krijg ik crap in de db. Maar nogmaals, dit gaat via een formulier, ik weet niet of dat nog invloed heeft...

Overigens wist ik niet dat htmlentities() een charset parameter had, handig.

[NMe]

cbernardini schreef op zaterdag 17 april 2010 @ 15:24:
[...]

Enige wat ik erover wil zeggen is dat er mensen op deze aardkloot zijn die er toch écht minder vestand van hebben dan jij en er dus meer tijd voor nodig hebben om het te begrijpen.

Waarom reageer je dan binnen 4 minuten, zeggend dat het toch allemaal klopt wat je met je database hebt gedaan? Waarom lees je die post niet en probeer je hem te begrijpen? Character encoding is geen superlastige materie maar als je zelf al aangeeft dat je tijd nodig hebt en vervolgens al een reactie in de trant van "ik snapput nie" klaar hebt binnen 4 minuten, dan spreek je jezelf tegen. Als je dan ook nog iemand afzeikt die je bijzonder uitgebreid probeert te helpen, dan zakt mij de broek daar een beetje van af. Jij bent degene met een vraag, wij kiezen ervoor om je in onze vrije tijd van een antwoord te voorzien. Heb dan ook het fatsoen om de tijd te nemen die posts te begrijpen of in elk geval gericht vragen te stellen als je ze niet begrijpt.

[pedorus]

Shapeshifter schreef op zaterdag 17 april 2010 @ 20:42:
Hmm, ik heb databases die UTF-8 gebruiken en een website die een UTF-8 header heeft en daar heb ik wel degelijk utf8_decode() bij nodig anders werkt het niet en krijg ik crap in de db. Maar nogmaals, dit gaat via een formulier, ik weet niet of dat nog invloed heeft...

Vreemd. Je hebt al utf-8, je wilt utf-8 hebben, en je gaat een conversie doen? Probeer eens de string "€0.02" op te slaan in je db?

Overigens wist ik niet dat htmlentities() een charset parameter had, handig.

Waarom zou je niet gewoon htmlspecialchars() gebruiken, en die charset staat al goed voor utf-8?

[FragFrog]

htmlentities documentatie

Like htmlspecialchars(), it takes an optional third argument charset which defines character set used in conversion. Presently, the ISO-8859-1 character set is used as the default.

Nogal duidelijk lijkt me htmlspecialchars heeft trouwens exact hetzelfde argument, dus die zou het ook fout gedaan hebben.

Niet zozeer fout van PHP als wel een ongelukkig gevolg van PHP's latin1 oorsprong. Niet voor niets moet je nogal wat kunstgrepen uithalen om te voorkomen dat er ergens een conversie fout gaat en is er een aardige hoeveelheid functies speciaal voor multibyte-strings.

offtopic:
En als iemand dat nou direct had gepost in plaats van een halve pagina doordrammen was TS een stuk sneller geholpen - dit soort kleine dingen zie je nou eenmaal snel over het hoofd, zeuren dat je 'de materie goed moet kennen' helpt dan echt niet in mijn opinie - helemaal gezien degene die beweert dat TS de materie niet goed kent zelf ook finaal over het hoofd gezien heeft dat de htmlentities die hij gebruikt waarschijnlijk de oorzaak is. TS post notabene nog wel zijn code met de exacte aanhef.

[ Voor 52% gewijzigd door FragFrog op 18-04-2010 05:08 ]

[pedorus]

FragFrog schreef op zondag 18 april 2010 @ 05:01:
htmlspecialchars heeft trouwens exact hetzelfde argument, dus die zou het ook fout gedaan hebben.

Nee!

quote: http://php.net/manual/en/function.htmlspecialchars.php

The default character set is ISO-8859-1.

For the purposes of this function, the charsets ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252, and KOI8-R are effectively equivalent, as the characters affected by htmlspecialchars() occupy the same positions in all of these charsets.

[FragFrog]

pedorus schreef op zondag 18 april 2010 @ 07:52:
Nee!

Mea culpa, I stand corrected Alhoewel ik wel benieuwd ben of het in de praktijk wel goed gaat daarmee.. PHP wil nog wel eens niet helemaal altijd werken zoals je verwacht

//edit
Warempel, even getest en htmlspecialchars doet het inderdaad goed waar htmlentities faalt - op zich ook wel logisch dat characters die niet geconvert worden met rust gelaten worden, maargoed, weer wat geleerd.

[ Voor 27% gewijzigd door FragFrog op 18-04-2010 08:16 ]

[Verwijderd]

cbernardini schreef op zaterdag 17 april 2010 @ 16:22:

Dank voor je antwoord over htmlentities, dat is me inderdaad ontgaan. Ik zie nu dat als ik htmlentities($string, ENT_QUOTES, 'UTF-8'); gebruik, de string goed wordt getoond. Zonder lukt dat niet. Het lijkt me dus dat PHP een verkeerde charset als standaard heeft ingesteld, aangezien ik geloof dat er niet telkens 'UTF-8' als derde parameter hoeft te worden meegegeven als je default charset UTF-8 is, of zie ik dat verkeerd?

Daar mag je wel vanuit gaan, maar klopt niet altijd helemaal. Ten eerste zijn er in het verleden talloze bugs geweest, omdat blijkbaar ook de PHP ontwikkelaars hier stevige moeite mee hebben gehad. Verder lijkt het afhankelijk van het wel of niet laden van de mbstring extensie en de character encoding van de huidige locale.

Misschien is de beste tip die ik kan geven eigenlijk om htmlentities helemaal niet te gebruiken als je al UTF-8 gebruikt. De functie htmlspecialchars escapet alleen de noodzakelijke tekens, en die zijn in vrijwel alle character sets gelijk. Voor de bijzondere tekens zoals klinkers met accenten, is het helemaal niet nodig ze te escapen. Alle clients die UTF-8 ondersteunen hebben geen moeite met dat soort tekens.

Ik merk dat als ik $link->query("SET NAMES 'utf8'"); niet gebruik, de tekens ook in phpmyadmin 'verkeerd' komen te staan. Als ik dat wel gebruik, komt de string zoals hij hoort in de database te staan. Dat is toch een redelijk goed bewijs lijkt me? Maar hoort het niet ook te kunnen zonder $link->query("SET NAMES 'utf8'"); als de collatie van de database op utf8 staat, of heeft dat weer ergens anders mee te maken?

Dat is dus het probleem als applicaties onderling niet goed afsprekken welke data er gaat worden doorgestuurd. Als MySQL UTF-8 encoded data doorkrijgt, maar ISO-8859-1 verwacht (omdat dat bijvoorbeeld standaard is), zal MySQL denken: "hey, de encoding van die client is ISO-8859-1, maar de tabel wil UTF-8 encoding, laat ik eens gaan converteren". Als de string echter al UTF-8 is, dan moet er juist niet geconverteerd worden.

[Shapeshifter]

pedorus schreef op zaterdag 17 april 2010 @ 23:53:
[...]
Vreemd. Je hebt al utf-8, je wilt utf-8 hebben, en je gaat een conversie doen? Probeer eens de string "€0.02" op te slaan in je db?

[...]

Waarom zou je niet gewoon htmlspecialchars() gebruiken, en die charset staat al goed voor utf-8?

Ben er al achter, de database stond niet op utf8_unicode, maar op latin1_general. Tijd om eens flink met mijn hoofd tegen een muur aan te gaan slaan.