[JS] " en createTextNode

[--MeAngry--]

Op het moment worden titels op de volgende manier in een databasetabel opgeslagen middels PHP:

PHP:

$title = htmlentities($title, ENT_QUOTES);

En deze worden zonder verdere handelingen weer uitgelezen.

Met javascript lees ik deze variabele vervolgens weer uit om het geheel met een createTextNode in m'n pagina te zetten. Nu worden alleen tekens als " (door de ENT_QUOTES) niet omgezet naar ", maar wordt de & van " ook nog eens omgezet naar &, waardoor in de generated source dus komt te staan:

code:

"

Ik heb al unescape geprobeerd, maar deze is ook eigenlijk voor een heel ander soort encoding. (URL-encoding, wat met HEX-tekens werkt.)
Hoe krijg ik m'n quotes op de gewenste manier in de textNode?
Het zal waarschijnlijk iets heel stoms zijn wat ik over het hoofd zie, en ik weet dat ik ook gewoon ENT_QUOTES kan weghalen, maar dat is meer een weg om het probleem heen en daarnaast kan het soms ook voorkomen (het wordt gebruikt in een CMS) dat het gewoon in de HTML moet worden gezet, dan is ENT_QUOTES dus noodzakelijk.
Anders moet ik namelijk addslashes gaan gebruiken bij het invoeren, en als ik deze strip bij het ophalen kom ik weer in de problemen met Javascript, en anders staan er weer slashes voor in de HTML.

Argh Wie weet raad?

[crisp]

Gewoon unencoded opslaan en pas gaan encoden als je gaat outputten. Als je output HTML moet zijn gebruik je htmlspecialchars (htmlentities is meestal overbodig) en naar JS moet je escapen, bijvoorbeeld zo:

PHP:

$jsstring = addcslashes($data, "\0\n\r\t\\'/");

Overigens als je jezelf aanleert HTML-attribuutwaarden altijd netjes tussen dubbele quotes te zetten heb je geen ENT_QUOTES nodig.

Verder is addslashes niet bedoelt voor escaping in een (MySQL) query, daar heb je mysql_escape_string en mysql_real_escape_string voor. En data die je uit je database haalt hoef je doorgaans niet te unescapen.

[ Voor 6% gewijzigd door crisp op 24-08-2006 11:19 ]

[--MeAngry--]

Nou, het gaat er juist om dat ik niet vantevoren weet of het in javascript of HTML gebruikt gaat worden. Het geheel wordt naar een Smarty-variabele gestuurd en verder wordt het in de template in HTML of in Javascript gezet.

Overigens, als ik addslashes, of inderdaad mysql_(real_)escape_string gebruik moet ik nog steeds stripslashes uitvoeren bij het ophalen, doe ik dit niet, dan wordt het geheel met slashes en al in de HTML gezet. Ik kan me alleen voorstellen dat dit met de magic_quotes instellingen te maken heeft.

ENT_QUOTES is overigens ook niet persé nodig nee omdat overal netjes dubbele quotes worden gebruikt. (Voor zover de templates door mij zijn gemaakt.) Maar dan zit ik nog steeds met de single quotes. (Als ik htmlspecialchars gebruik ipv htmlentities ook.)

Het moet toch gewoon mogelijk zijn om in javascript HTML tekens te decoden? Ik heb het al met

code:

<string>.replace("&quot;", "\"");

geprobeerd, maar dat wil ook niet werken om een reden die ik niet kan achterhalen.

Hier staan de twee pagina's waar het in dit geval om gaat:

http://www.stpiusx.nl/index.php?news=229&page=1
Hier wordt het geheel gewoon in de HTML gezet.

http://www.stpiusx.nl/index.php?id=28
Hier wordt het geheel met javascript toegevoegd in het blok tussen de streepjes.

Op het moment doe ik het invoeren met:

code:

addslashes(htmlspecialchars($string, ENT_NOQUOTES));

En ophalen zonder wat voor modifiers dan ook.

(Let overigens niet op de ranzige HTML van de content op die pagina, dat komt door de teksteditor die gebruikt wordt.)

[ Voor 4% gewijzigd door --MeAngry-- op 24-08-2006 11:37 ]

[Janoz]

Normalitair hoor je die conversie pas bij het afdrukken te doen. Pas in het template zou je aan moeten geven of het op die plek in JS stijl, in html style of helemaal niet geencode hoeft te worden. Geen idee of dat met smarty wel werkt.

[--MeAngry--]

Janoz schreef op donderdag 24 augustus 2006 @ 11:54:
Normalitair hoor je die conversie pas bij het afdrukken te doen. Pas in het template zou je aan moeten geven of het op die plek in JS stijl, in html style of helemaal niet geencode hoeft te worden. Geen idee of dat met smarty wel werkt.

Haha, ja ik weet het, maar dit CMS is oorspronkelijk door iemand anders begonnen en ik ben het nu aan het uitwerken tot een volwaardig systeem. Het probleem is alleen dat het wel backwards compatible moet blijven (in grote lijnen) met oude templates omdat er redelijk wat sites mee draaien welke een onderhoudscontract hebben en dus eenvoudig moeten worden geupdate.

Eigenlijk is dit ook de enige site (voorlopig) waar het geheel in javascript aan een element moet worden toegevoegd.

Overigens, mocht ik het nu onencoded opslaan, dan moet ik in javascript alsnog slashes gaan toepassen, en voor zover ik weet lukt dat niet in Smarty. Ik kan wel een HTML modifier over de string halen om het in XHTML te plaatsen, maar sowieso werd er oorspronkelijk al htmlspecialchars gebruikt wat uiteraard al goed werkte in XHTML. Maar voor javascript heb ik dan nog steeds geen oplossing.
Mijn hoofdvraag is eigenlijk nog steeds waarom van " " wordt gemaakt op het moment dat ik het met createTextNode aan een element toevoeg.

[ Voor 24% gewijzigd door --MeAngry-- op 24-08-2006 12:10 ]

[crisp]

Als er ook slashes staan in de data die je terugkrijgt uit je query dan moet je magic_quotes_runtime uitzetten.

Verder verwacht een textNode inderdaad gewoon tekst zonder encoding. Je zou eventueel nog een JS-functie kunnen gebruiken om de entitites te decoden:

JavaScript:

function unhtmlspecialchars(string)
{
    string = string.replace(/&lt;/g, '<');
    string = string.replace(/&gt;/g, '>');
    string = string.replace(/&quot;/g, '"');
    string = string.replace(/&#0?39;/g, '\'');
    string = string.replace(/&amp;/g, '&');
    
    return string;
}

Een alternatief kan zijn om 2 variabelen in je templates te gebruiken; eentje met de JS-escaped data en eentje met HTML encoded data

[ Voor 10% gewijzigd door crisp op 24-08-2006 12:26 ]

[--MeAngry--]

crisp je bent geweldig
Ik zat al met string.replace te stoeien, maar ik had over het hoofd gezien dat het met regular expresions werkt. Dankzij deze functie werkt het in ieder geval! Eigenlijk niet de netste oplossing, ik zou eventueel nog een variabele naar Smarty kunnen exporteren met de raw waarde zonder encoding, maar hiermee hoeft dat in ieder geval niet meer.