Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[HTML] Charsets

Pagina: 1
Acties:

  • Tijgertje84
  • Registratie: Augustus 2005
  • Laatst online: 04-06 14:43
Ik heb ik zo hier en daar wat gezocht / gevonden / toegepast en helaas tot nu toe zonder resultaat.

Mijn probleem is als volgt:

Heb een PHP website en heb daar een database achterstaan. Alle gegevens worden daarin opgeslagen. Hierbij worden speciale karakters als û (html-entities)etc etc opgeslagen.
Maar als ik deze data wil ophalen en deze vervolgens wegschrijven in een formulier op het scherm krijg ik rechtstreeks deze data in een input veld: &.ucirc; etc... En dat mot niet natuurlijk :P

Nu heb ik al zitten proberen met form enctype en Character encodings (ISO-8859-1 en utf-8)
Maar helaas zonder resultaat.

Doel is dus gewoon om deze entities als gewone tekst (û etc) op het scherm te krijgen..

Heb een testje gemaakt alsvolgt:
PHP:
1
2
3
4
5
6
7
8
9
10
// ik gebruik hier dus beide vormen van û en de html entitie ervan
$test = "Brûle û";
echo "Standaard ";
info($test);
echo "htmlentities ";
info(htmlentities($test));
echo "html_entity_decode ";
info(html_entity_decode($test));
echo "htmlspecialchars ";
info(htmlspecialchars($test));

Met als output: (even de entities zonder . nemen ^^, anders pakt hij het verkeerd..)
Standaard
Brûle �; (edit: typfout)
htmlentities
Br&.ucirc;le û
html_entity_decode
Br�le �;
htmlspecialchars
Br&.ucirc;le �;

Op een of andere manier maakt hij er dus een � van.
Rechtstreeks een html entitie in het veld pasten werkt gewoon maar ik werk via PHP/AJAX en daarmee gaat dat dus fout. Ook met de PHP functies zoals hierboven...

Anyone?

Alvast bedankt!

EDIT:
sorry voor late post maar dit even te verduidelijking van mijn probleem:

Het probleem begon als volgt:
"Brûle" staat in de DB en bij het opvragen van gegevens werdt dit in de browser weggeschreven als "Br?" en verder niets erachter....
Door die "?" merkte ik dus dat het fout ging met die speciale karakter.
Heb dus wat uitgezocht en wat uitgeprobeerd.

Als test heb ik dus even HARD in de DB "Brûle" vervangen door "Br&.ucirc;le" (zonder punt :))
Dan de data weer opgehaald in de browser en nu kreeg ik wel de goede tekst te zien. Werkt dus prima! (ik merkte een typfout in mijn TS, sorry)

Maar er zat wat haken en ogen aan namelijk:
  • Het werkt niet in een input veld van een form...... daar staat nog gewoon die html entitie in
Dus ben ik gaan uitproberen met die enctype van form en php encodings maar zonder resultaat.
Mijn probleem is dus in principe het weergeven van de html entities die rechtstreeks in een form veld komen te staan.

ik heb niets gedaan mbt het opslaan van de gegevens in de db, want dit is pas stap 2 nadat ik zeker weet dat dit werkt ;)

[ Voor 27% gewijzigd door Tijgertje84 op 26-11-2007 12:00 ]

Intel© Conroe E6600 | Asus P5Q PRO Turbo | Sapphire Vapor-X HD5770 1GB | G.E.I.L. 2 GB DDR2-667 Kit CL4 4-4-12 | WD Caviar SE16 2x250GB (S-ATA2) (Raid0) | Sunbeam Trio | Chaintec CFT-500A | Windows XP Pro SP3 | Samsung Syncmaster S23A350H


  • Raynman
  • Registratie: Augustus 2004
  • Nu online
Ik vind je verhaal niet heel helder. Zou je in ieder geval nog even duidelijk willen maken of je htmlentities() op de gegevens loslaat vóór je ze in de database gooit? Dus heb je & e.d. in je database staan of &?

En wat doet info() ?

  • crisp
  • Registratie: Februari 2000
  • Laatst online: 19:30

crisp

Devver

Pixelated

Daarom is het ook handiger om pas HTML-encoding te doen op het moment dat dat noodzakelijk is, en niet als je het in de database opslaat.

Note overigens dat in de meeste karakterencodings karakters als û gewoon valide zijn en dus niet noodzakelijk als een entity hoeven te worden weergegeven. Normaliter is htmlspecialchars() meer dan voldoende.

Intentionally left blank


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Als je letterlijk & ziet staan, heb je gewoon in totaal 2x htmlentities gedaan.
En als je htmlentities toepast voordat je data in de db opslaat, vraag je daar ook een beetje om. Je escape't vanwege een bepaalde context. Voor queries is dat ivm query syntax/sql injection en bij presentatie is dat ivm html syntax.

{signature}


  • Confusion
  • Registratie: April 2001
  • Laatst online: 01-03-2024

Confusion

Fallen from grace

T ijgertje84 schreef op zondag 25 november 2007 @ 20:55:
Maar als ik deze data wil ophalen en deze vervolgens wegschrijven in een formulier op het scherm krijg ik rechtstreeks deze data in een input veld: &.ucirc; etc...
Dan heeft Voutloos waarschijnlijk gelijk. Als je de karakters '&' naar een browser stuurt, dan geeft die een '&' weer. Als de browser '&' weergeeft, dan heeft deze '&' ontvangen. Welke character encoding je gebruikt maakt daarvoor waarschijnlijk niet uit, want in de meestgebruikte (ISO-8859 varianten en UTF-8) zijn de karakters in & hetzelfde gecodeerd (de bytes 26, 61, 6D, 70 en 3B).

[ Voor 4% gewijzigd door Confusion op 25-11-2007 22:02 . Reden: nohtml tags toegevoegd :) ]

Wie trösten wir uns, die Mörder aller Mörder?


  • Tijgertje84
  • Registratie: Augustus 2005
  • Laatst online: 04-06 14:43
sorry voor late post maar dit even te verduidelijking van mijn probleem:

Het probleem begon als volgt:
"Brûle" staat in de DB en bij het opvragen van gegevens werdt dit in de browser weggeschreven "Br?"
Door die "?" merkte ik dus dat het fout ging met die speciale karakter.
Heb dus wat uitgezocht en wat uitgeprobeerd.

Als test heb ik dus even HARD in de DB "Brûle" vervangen door "Br&.ucirc;le" (zonder punt :))
Dan de data weer opgehaald in de browser en nu kreeg ik wel de goede tekst te zien. Werkt dus prima! (ik merkte een typfout in mijn TS, sorry)

Maar er zat wat haken en ogen aan namelijk:
  • Het werkt niet in een input veld van een form......
Dus ben ik gaan uitproberen met die enctype van form en php encodings maar zonder resultaat.
Mijn probleem is dus in principe het weergeven van de html entities die rechtstreeks in een form veld komen te staan.

ik heb niets gedaan mbt het opslaan van de gegevens in de db, want dit is pas stap 2 nadat ik zeker weet dat dit werkt ;)
info() is een zelf gemaakte functie die niets anders is dan var_dump/printf ;) alleen dan iets anders zodat het overzichtelijker is (vooral met arrays/objecten).

[ Voor 12% gewijzigd door Tijgertje84 op 26-11-2007 12:05 ]

Intel© Conroe E6600 | Asus P5Q PRO Turbo | Sapphire Vapor-X HD5770 1GB | G.E.I.L. 2 GB DDR2-667 Kit CL4 4-4-12 | WD Caviar SE16 2x250GB (S-ATA2) (Raid0) | Sunbeam Trio | Chaintec CFT-500A | Windows XP Pro SP3 | Samsung Syncmaster S23A350H


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Je verduidelijkt het probleem, maar imo moet je ook verder kunnen met gegeven hints. ;) Dus waar loop je nu vast?
Op elk punt waar je met strings werkt moet je weten welke encoding het is. Vervolgens op de juiste plek op de juiste manier escapen en klaar is Tijgertje.

{signature}


  • Tijgertje84
  • Registratie: Augustus 2005
  • Laatst online: 04-06 14:43
Voutloos schreef op maandag 26 november 2007 @ 12:04:
Je verduidelijkt het probleem, maar imo moet je ook verder kunnen met gegeven hints. ;) Dus waar loop je nu vast?
Op elk punt waar je met strings werkt moet je weten welke encoding het is. Vervolgens op de juiste plek op de juiste manier escapen en klaar is Tijgertje.
vind het jammer dat ik nu niets kan testen aangezien ik aan het werk ben. pas vanavond zal ik wellicht weer wat kunnen doen.
Maar main probleem ligt dus bij die html entities in een form. Had verwacht dat een form, aangezien dat ook gewoon html is die entities gewoon kan lezen en dus zelf omzetten naar het juiste karakter....
We zullen zien zodra ik thuis kom :) en zo niet dan merk je al snel een reply ^^

Intel© Conroe E6600 | Asus P5Q PRO Turbo | Sapphire Vapor-X HD5770 1GB | G.E.I.L. 2 GB DDR2-667 Kit CL4 4-4-12 | WD Caviar SE16 2x250GB (S-ATA2) (Raid0) | Sunbeam Trio | Chaintec CFT-500A | Windows XP Pro SP3 | Samsung Syncmaster S23A350H

Pagina: 1