[php] htmlspecialchars geeft leeg resultaat met euro teken

[Mooya]

Hi,

Bij een webhosting is de Php ge-upgrade naar v5.6.
Nu heeft het CMS problemen met het weergeven van variabelen met het euro teken.

Dit gaat bijvoorbeeld fout:

<?php

$Var = "bedrag: € 500";
echo "Waarde: ". htmlspecialchars($Var);

?>

Er komt nu gewoon een lege waarde. Indien het euro teken weg gelaten wordt uit de $Var gaat het wel goed.

Op deze manier gaat het wel goed:

<?php

$Var = "bedrag: € 500";
echo "Waarde: ". htmlspecialchars($Var, ENT_COMPAT, 'ISO-8859-15');

?>
Dus door de ENT_COMPAT - ISO-8859-15 toe te voegen wordt het euro teken goed gepakt.
Nou is dit op erg veel plekken aan de hand, en is het niet echt een optie om overal die ENT_COMPAT toe te voegen.


Iemand een idee hoe dit beter te fixen is?

[DJMaze]

Mooya schreef op woensdag 1 maart 2017 @ 16:35:
Iemand een idee hoe dit beter te fixen is?

Ja, leer programmeren in UTF-8 en sla je bestanden op in UTF-8 zonder BOM.
Zorg dat je databases ook unicode/utf8mb4 zijn.
Zorg voor de juiste Content-Type

Dit zou in het jaar 2000 al moeten zijn gefixt door je voorgangers.

[ Voor 24% gewijzigd door DJMaze op 01-03-2017 17:43 ]

[NMe]

Gebruik een wrapperfunctie. Schrijf zelf een myOwnHtmlSpecialChars($string, $mode = ENT_COMPAT, $charset = 'ISO-8859-15') die onder water htmlspecialchars($string, $mode, $charset) aanroept, vervang alle htmlspecialchars-calls door een call naar je eigen functie en het werkt ineens overal, ook als je op bepaalde plekken al die charset gezet had. Als je later inderdaad volledig overstapt op UTF-8 hoef je alleen die ene default in de functiedefinitie aan te passen.

DJMaze schreef op woensdag 1 maart 2017 @ 17:39:
[...]

Ja, leer programmeren in UTF-8 en sla je bestanden op in UTF-8 zonder BOM.
Zorg dat je databases ook unicode/utf8mb4 zijn.
Zorg voor de juiste Content-Type

Dit zou in het jaar 2000 al moeten zijn gefixt door je voorgangers.

Hoewel het juiste antwoord is het een beetje een lullige "oplossing" gezien het feit dat hij met legacy code zit die nu stuk is en gefixt moet worden.

[ Voor 34% gewijzigd door NMe op 01-03-2017 17:57 ]

[DJMaze]

NMe schreef op woensdag 1 maart 2017 @ 17:55:
Hoewel het juiste antwoord is het een beetje een lullige "oplossing" gezien het feit dat hij met legacy code zit die nu stuk is en gefixt moet worden.

Hij vroeg om een betere fix, anders gebruik dit ipv een wrapper:

PHP:

ini_set('default_charset', 'ISO-8859-15');

Het staat ook (cryptisch) vermeld in de documentatie

[ Voor 18% gewijzigd door DJMaze op 01-03-2017 18:11 ]

[Mooya]

Thanks @DJMAze en @NME

De nieuwe functie voor de htmlspecialchars lijkt een goede oplossing.
Het liefst heb ik een optie die in 1x alles fixed

De content-type van de pagina is ook: "text/html; charset=iso-8859-1"
Ik heb dat eens aangepast naar iso-8859-15 en geen verschil.

Ik heb de ini_set ook verwerkt bovenin de pagina, en toen verdwenen de euro tekens uit de pagina. Dus daar werd het ook niet beter van


Ik heb de MySQL Server nagekeken, en daar staat het volgende: Karakterset van server: UTF-8 Unicode (utf8)
Ik kon niet bij de database vinden of deze een andere karakterset heeft.
Dus dat lijkt dan goed toch?


ff domme vraag over karakter sets,
in de bron van GOT staat de content-type ook op "text/html; charset=iso-8859-15". Waarom staat die niet op UTF-8 ? Of is dat ook nog nasleep van oude code?

[NMe]

Mooya schreef op woensdag 1 maart 2017 @ 21:12:
De content-type van de pagina is ook: "text/html; charset=iso-8859-1"
Ik heb dat eens aangepast naar iso-8859-15 en geen verschil.

Als je het over de HTML-tag hebt: dat is mosterd na de maaltijd. Je bent je browser daar al content aan het serveren en halverwege de pagina zeg je ineens "oh, dit is eigenlijk een andere charset dan je dacht." De content-type die je in je HTTP-headers zet is veel belangrijker. The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Ik heb de ini_set ook verwerkt bovenin de pagina, en toen verdwenen de euro tekens uit de pagina. Dus daar werd het ook niet beter van

Die functie werkt niet zomaar overal, hangt van je host af. Vandaar ook mijn suggestie om een wrapperfunctie te maken.

Ik heb de MySQL Server nagekeken, en daar staat het volgende: Karakterset van server: UTF-8 Unicode (utf8)
Ik kon niet bij de database vinden of deze een andere karakterset heeft.
Dus dat lijkt dan goed toch?

Niet per se.

ff domme vraag over karakter sets,
in de bron van GOT staat de content-type ook op "text/html; charset=iso-8859-15". Waarom staat die niet op UTF-8 ? Of is dat ook nog nasleep van oude code?

Dat laatste.

[Mooya]

Thanks, ik weet genoeg.
Zal het eens nalezen verder.

[DJMaze]

Mooya schreef op woensdag 1 maart 2017 @ 21:12:
Het liefst heb ik een optie die in 1x alles fixed

Zie http://php.net/mb_output_handler

PHP:

mb_http_output("ISO-8859-15");
ob_start("mb_output_handler");

[ Voor 6% gewijzigd door DJMaze op 02-03-2017 10:42 ]

[Mooya]

Thanks DJMaza,

De provider had ook nog dit in de algemene htaccess gezet: AddDefaultCharset iso-8859-15
Zodra ik de pagina charset ook op iso-8859-15 had staan werden de euro tekens (uit de DB) nog niet goed weergegeven.

Ik speur nog even verder.
Je genoemde toevoegingen helpen helaas ook niet.

En anders maak ik wel een nieuwe functie voor de htmlspecialchars (htmlspecialchars2)

[DJMaze]

Mooya schreef op donderdag 2 maart 2017 @ 11:19:
werden de euro tekens (uit de DB) nog niet goed weergegeven

Logisch, dit hangt af van veel factoren:

Is de DB column definitie UTF-8 of latin?
Is de DB column content echt UTF-8 of binair of latin?
Is de DB client verbinding UTF-8 of latin?

Ik blijf terugvallen op mijn eerste reply
Lees ook eens mijn oude FAQ item (uit 2004 notabene) https://dragonflycms.org/FAQ/cat=14.html

[ Voor 10% gewijzigd door DJMaze op 02-03-2017 15:46 ]