[PHP]htmlentities doet niet alle characters

[Megamind]

Tekst die ik opsla in mijn database wordt plat opgeslagen als UTF-8. Het schrijven ernaartoe werkt prima, alle tekens kan ik er gewoon inzetten.

Maar als ik het nu opvraag wil ik ALLE rare tekens omzetten in HTML entities.

Dat doe ik dan met

code:

htmlentities($value,ENT_NOQUOTES, 'UTF-8');

Dus ë wordt & euml; en é wordt & eacute;

Maar ik heb ook veel de č. Deze wordt niet omgezet. Deze heeft geen eigen speciaal teken maar heeft & #269;
Ik heb alle documentatie doorgelezen, maar deze tekens krijg ik niet om! Ik heb de volgende functies geprobeerd:
htmlentities
mb_convert_encoding
htmlspecialchars
utf8_encode
etc.

Maar geen enkele werkt, of ben ik er 1 vergeten?

De pagina wordt correct weer gegeven, maar ik wil het gewoon omgezet hebben zodat de validator er niet elke keer over struikelt.

edit: het ziet er naar uit dat GoT het wel goed omzet. Misschien kan een devver kijken welke functie daarvoor gebruikt wordt

[ Voor 7% gewijzigd door Megamind op 14-01-2008 21:22 ]

[TheBorg]

Ik had gehoopt dat iemand een fatsoenlijke oplossing zou komen, dan maar mijn hele smerige:

1. Translation table opvragen van HTML_ENTITIES
2. De table aanvullen met speciale tekens.
3. De nieuwe table gebruiken voor het vertaalwerk.

PHP:

<?php

    $sText = "Some strange character: &#269;";
    
    echo strtr( $sText, get_my_ultimate_translation_table() );
    
    
    function get_my_ultimate_translation_table ()
    {
        $aTable = get_html_translation_table(HTML_ENTITIES);
        $aTable['&#269;'] = '&#269';
        return $aTable;
    }

?>

-edit-
De &#269 in $sText en in $aTable[''] moet een č zijn (wordt iets te goed omgezet in een code blok).

[ Voor 9% gewijzigd door TheBorg op 14-01-2008 21:55 ]

[Megamind]

Hmm dat werkt inderdaad wel. Voor nu is het wel ok, omdat ik een aantal Sloveense tekens gebruik, maar echt super is het niet. Er moet toch wel iets voor te vinden zijn...

[djiwie]

Waarom wil je eigenlijk die 'rare tekens' omzetten naar entities? Wanneer de pagina encoding op UTF-8 staat zouden de tekens ook zonder encodering correct weergegeven moeten worden.

[Voutloos]

Precies, je kan beter kijken waarom die validator je pagina niet als UTF-8 pakt. Want als die validator het niet zomaar kan, kan een andere user-agent dat wellicht ook niet.

[SchizoDuckie]

Ik heb dr zelf ook gezeik mee gehad bij ajax requests. Het is mij ook nog steeds onduidelijk waarom veel niet omgezet wordt... Iig, dit is mijn oplossing:

PHP:

function xHtmlEntities($inputtext)
{
    $replaceArray = array('Œ' => 'Œ', 'œ' => 'œ', 'Ŝ' => 'Š', 'š' => 'š', 'Ÿ' => 'Ÿ', '‘' => '‘', '’' => '’', '‚' => '‚', '“' => '“', '”' => '”', '„' => '„', '†' => '†', '‡' => '‡', '‰' => '‰', '‹' => '‹', '›' => '›', '€' => '€', '™' => '™', 'À' => 'À', 'Á' => 'Á', 'Â' => 'Â', 'Ã' => 'Ã', 'Ä' => 'Ä', 'Å' => 'Å', 'Æ' => 'Æ', 'Ç' => 'Ç', 'È' => 'È', 'É' => 'É', 'Ê' => 'Ê', 'Ë' =>     'Ë', 'Ì' => 'Ì', 'Í' => 'Í', 'Î' => 'Î', 'Ï' => 'Ï', 'Ð' => 'Ð', 'Ñ' => 'Ñ', 'Ò' => 'Ò', 'Ó' => 'Ó', 'Ô' => 'Ô', 'Õ' => 'Õ', 'Ö' => 'Ö', 'Ø' => 'Ø', 'Ù' => 'Ù', 'Ú' => 'Ú', 'Û' => 'Û', 'Ü' => 'Ü', 'Ý' => 'Ý', 'Þ' => 'Þ', 'ß' => 'ß', 'à' => 'à', 'á' => 'á', 'â' => 'â', 'ã' => 'ã', 'ä' => 'ä', 'å' => 'å', 'æ' => 'æ', 'ç' => 'ç', 'è' => 'è', 'é' => 'é', 'ê' => 'ê', 'ë' => 'ë', 'ì' => 'ì', 'í' => 'í', 'î' => 'î', 'ï' => 'ï', 'ð' => 'ð', 'ñ' => 'ñ', 'ò' => 'ò', 'ó' => 'ó', 'ô' => 'ô', 'õ' => 'õ', 'ö' => 'ö', 'ø' => 'ø', 'ù' => 'ù', 'ú' => 'ú', 'û' => 'û', 'ü' => 'ü', 'ý' => 'ý', 'þ' => 'þ', 'ÿ' => 'ÿ', '¡' => '¡', '¤' => '¤', '¢' => '¢', '£' => '£', '¥' => '¥', '¦' => '¦', '§' => '§', '¨' => '¨', '©' => '©', 'ª' => 'ª', '«' => '«', '¬' => '¬', '®' => '®', '™' => '™', '¯' => '¯', '°' => '°', '±' => '±', '²' => '²', '³' => '³', '´' => '´', 'µ' => 'µ', '¶' => '¶', '·' => '·', '¸' => '¸', '¹' => '¹', 'º' => 'º', '»' => '»', '¼' => '¼', '½' => '½', '¾' => '¾', '¿' => '¿', '×' => '×', '÷' => '÷');
    $inputtext= strtr($inputtext, $replaceArray);
    return ($inputtext);
}

[Swaptor]

Waarom wordt het uitbreiden van een kennelijk beperkte lijst gezien als smerig?
Wanneer er echt geen 'kant-en-klare' oplossing bestaat is het aanpassen van een bestaande oplossing die het probleem slechts ten dele bestrijkt een valide methode lijkt mij?

Bovenstaande is toch wel als offtopic te betitelen, excuses daarvoor.

[SchizoDuckie]

Swaptor schreef op dinsdag 15 januari 2008 @ 09:53:
Waarom wordt het uitbreiden van een kennelijk beperkte lijst gezien als smerig?
Wanneer er echt geen 'kant-en-klare' oplossing bestaat is het aanpassen van een bestaande oplossing die het probleem slechts ten dele bestrijkt een valide methode lijkt mij?

Bovenstaande is toch wel als offtopic te betitelen, excuses daarvoor.

Imo is het niet offtopic en imo is het inderdaad de juiste oplossing (zie hierboven).
Er is een soort van ongeschreven regel bij veel programmeurs lijkt het wel dat alles 'zo net mogelijk moet' volgens alle best practices die iedereen ooit geschreven heeft. Mijn eigen filosofie is meer van kies the right tool for the right job, die *nu* werkt, en zorg ervoor dat je het evengoed zo netjes oplost dat het later nog aan te passen is. Ik heb persoonlijk bijvoorbeeld echt niet de behoefte om uit te vinden waarom die wazige validator iets niet slikt, ik wil gewoon dat het werkt.

[ Voor 7% gewijzigd door SchizoDuckie op 15-01-2008 10:00 ]

[jan-marten]

Ik heb hier ook ooit eens last van gehad met PHP 4. Oplossing was om hetzelfde script door PHP 5 uit te laten voeren

O ja: PHP4 versie en PHP5 versie. Tekst wordt via een RSS-feed binnengehaald. Beide pagina's zijn UTF-8.

[ Voor 46% gewijzigd door jan-marten op 15-01-2008 10:05 ]

[FragFrog]

SchizoDuckie schreef op dinsdag 15 januari 2008 @ 09:47:
Ik heb dr zelf ook gezeik mee gehad bij ajax requests. Het is mij ook nog steeds onduidelijk waarom veel niet omgezet wordt... Iig, dit is mijn oplossing:

Ik had hetzelfde probleem hier, bleek dat alles via javascript's escape functie ging. Daar is geen standaard PHP equivalent voor, maar even googelen geeft je deze link waar weinig uit op te maken is, maar even naar beneden scrollen vind je een PHP equivalent van javascrtips unescape() functie die erg goed werkt

As for de discussie wat netter is: als je een lijst met karakters opgeeft die aangepast worden ben je de sjaak zodra er nieuwe characters aan toegevoegd worden. Dat is nu niet aan de orde, maar wie weet over een jaar wel, of twee jaar, om maar iets te noemen. Juist dan wil je niet door je code hoeven te zoeken naar die ene functie die alleen sommige chars goed doet en andere niet, een generieke oplossing is dan wellicht moeilijker om te maken, maar ook duurzamer en minder onderhoudsgevoelig. Ik heb vaak genoeg lappen code zitten verwijderen die ook 'nu werkte', word daar doorgaans niet vrolijk van

[ Voor 32% gewijzigd door FragFrog op 15-01-2008 10:09 ]

[Voutloos]

SchizoDuckie schreef op dinsdag 15 januari 2008 @ 09:59:
Ik heb persoonlijk bijvoorbeeld echt niet de behoefte om uit te vinden waarom die wazige validator iets niet slikt, ik wil gewoon dat het werkt.

Maar je moet wel willen controleren of je headers mbt encoding goed staan, want misschien pakt die tool daarom het niet goed...

[SchizoDuckie]

FragFrog schreef op dinsdag 15 januari 2008 @ 10:05:
[...]

As for de discussie wat netter is: als je een lijst met karakters opgeeft die aangepast worden ben je de sjaak zodra er nieuwe characters aan toegevoegd worden. Dat is nu niet aan de orde, maar wie weet over een jaar wel, of twee jaar, om maar iets te noemen. Juist dan wil je niet door je code hoeven te zoeken naar die ene functie die alleen sommige chars goed doet en andere niet, een generieke oplossing is dan wellicht moeilijker om te maken, maar ook duurzamer en minder onderhoudsgevoelig. Ik heb vaak genoeg lappen code zitten verwijderen die ook 'nu werkte', word daar doorgaans niet vrolijk van

True, true

Maar volgens mij werkte het bij mij de andere kant op. Er komt input van PHP die JS niet snapt. En daar werkt dan ook deze code nog niet voor voor zover ik het nu even zie

Voutloos schreef op dinsdag 15 januari 2008 @ 10:10:
[...]
Maar je moet wel willen controleren of je headers mbt encoding goed staan, want misschien pakt die tool daarom het niet goed...

de TS geeft aan dat hij alles al geprobeerd heeft m.b.t. de standaard UTF-8 encoding functies. En aangezien zijn database ook in UTF-8 is mag je daar wel van uit gaan lijkt me. Verder zijn Ajax request altijd in utf8/16, of je nou wil of niet

[ Voor 21% gewijzigd door SchizoDuckie op 15-01-2008 10:17 ]

[ChessSpider]

jan-marten schreef op dinsdag 15 januari 2008 @ 10:01:
Ik heb hier ook ooit eens last van gehad met PHP 4. Oplossing was om hetzelfde script door PHP 5 uit te laten voeren

O ja: PHP4 versie en PHP5 versie. Tekst wordt via een RSS-feed binnengehaald. Beide pagina's zijn UTF-8.

Van de PHP4 website, zet de encoding eens op "Western European".. of bekijk hem in kladblok. In PHP staat hij dus niet in UTF formaat..

[SchizoDuckie]

ChessSpider schreef op dinsdag 15 januari 2008 @ 15:05:
[...]


Van de PHP4 website, zet de encoding eens op "Western European".. of bekijk hem in kladblok. In PHP staat hij dus niet in UTF formaat..

Dat komt omdat PHP4 nog totaal geen idee had wat UTF-8 is _{(als ik het me goed voor m'n hoofd haal tenminste, ik ben al >3 jaar over op PHP5)} Het gaat dus überhaupt niet werken omdát je UTF8 naar <insert je favo encoding hier> moet omzetten...

[ Voor 9% gewijzigd door SchizoDuckie op 15-01-2008 16:00 ]

[ChessSpider]

SchizoDuckie schreef op dinsdag 15 januari 2008 @ 15:14:
[...]

Dat komt omdat PHP4 nog totaal geen idee had wat UTF-8 is _{(als ik het me goed voor m'n hoofd haal tenminste, ik ben al >3 jaar over op PHP5)} Het gaat dus überhaupt niet werken omdát je UTF8 naar <insert je favo encoding hier> moet omzetten...

najah je hebt die mb_ functies enzo.. PHP5 ondersteund het toch ook niet helemaal 100%? PHP6 ondersteund UTF8 100% native..

[.oisyn]

Zolang je geen stringbewerkingen doet die afhangen van het n^e karakter in een string boeit het geen ene fl*kker of PHP UTF-8 ondersteunt of niet . Waar je wel op moet letten zijn character literals in je code, maar anders dan dat zijn UTF-8 strings en "normale" byte strings volledig uitwisselbaar.

Zoals eerder gezegd, met UTF-8 hoef je tekens als é al niet meer te vervangen. Quotes en < en > e.d. natuurlijk wel, maar die zijn in UTF-8 gelijk aan ASCII, en komen tevens niet voor in de extended characters van UTF-8 (wat het hele idee achter het design van UTF-8 is)

[ Voor 10% gewijzigd door .oisyn op 15-01-2008 16:39 ]

[Megamind]

Nee inderdaad nu werkt het opeens wel in de W3C validator. Eerst struikelde hij altijd over de é en ë maar dat doet hij niet meer. Alle encodings staan goed, ik ben nu bezig in PHP5 maar helaas moet ie op een PHP4 server komen te staan...

Tijd dat hostings eens op 5 overgingen.

[djiwie]

Dat mag zeker wel, PHP 4 wordt niet bepaald meer ondersteund...