[XML/ASP] special characters en createCDataSection

[zoepercavia]

ik heb weer 's problemen met special characters en XML. Om helemaal w3c vriendelijk te zijn zet ik alle characters met ascii value > 127 om in een html char code : &#xxx;.
Gaat allemaal prima, maar nu moet ik de string uit de database in een Cdata sectie in mn XML zetten (er zit nog wat niet XHTML in mn database, ivm backwardscompatibility dus). Dat doe ik met een simpele functie (zelf geschreven, voor het gemak):

code:

sub createXMLCDataChild(nodeNaam, parent, inhoud)
    dim xml_tempCData, xml_tempChild
    set xml_tempChild = xmldoc.CreateNode("element", nodeNaam, "")
    parent.appendChild(xml_tempChild)
    if not isNull(inhoud) then
        set xml_tempCData = xmldoc.createCDataSection(inhoud)
        xml_tempChild.appendChild(xml_tempCData)
    end if
end sub

alleen op deze manier wordt alle & (ampersand) ge-escaped en komen dus als & in de XML.. GRR! í (ë) wordt dan &#237;. Hoeft opzich geen probleem te zijn, maar omdat ik <xsl:value-of select="node" disable-output-escaping="yes"/> gebruik (ivm met de HTML), krijg ik als resultaat í en niet ë!

Mijn vraag dus (eindelijk) hoe voorkom ik dat mn data ge-escaped de XML in gaat?

[mbravenboer]

zoepercavia: ik heb weer 's problemen met special characters en XML. Om helemaal w3c vriendelijk te zijn zet ik alle characters met ascii value > 127 om in een html char code : &#xxx;.

Waarom zou dat W3C vriendelijke zijn? Je kan gewoon een encoding gebruiken met een fatsoenlijke range zoals bijvoorbeeld UTF-8. Je kan ook helemaal uit je dak gaan en UTF-16 pakken .

Je probleem is denk ik duidelijk: je escaped tekst en neemt deze tekst daarna op in een CDATA section. Het is dan nogal logisch dat het niet goed werkt: de tekst in een CDATA section wordt niet geparsed en letterlijk overgenomen, inclusief XML constructies.

Persoonlijk zou ik helemaal niet aan het escapen gaan, maar dit gewoon aan de DOM implementatie of de XML outputter overlaten: deze zou zelf voor escaping moeten zorgen als dat nodig is (de implementaties die ik gebruik doen dat in ieder geval...).

Als je toch wilt escapen is er maar 1 oplossing: gebruik geen CDATA sectie.

[zoepercavia]

[AARGH-mode]
VERGEET DIT ALLEMAAL

dit stond in mn 'ubb' parser :

code:

parseformData = Replace(parseformData, "&", "&")

ik vergeet mn eigen code
ban me maar ofzo van dit forum
[/AARGH-mode]

maareh... (als ik nog wat mag vragen):
wat betreft w3c vriendelijkheid... ik meen dat het standaard is dat je ë gebruikt in de source en niet ë of is dat nu weer veranderd?
(microsofts xmlhttp object loopt bijvoorbeeld stuk op ë)

[mbravenboer]

zoepercavia: hmm.. waar escape ik mijn tekst dan?

Hum... dat zeg je toch zelf?

Om helemaal w3c vriendelijk te zijn zet ik alle characters met ascii value > 127 om in een html char code : &#xxx;.

Als je dit in een CDATA section stopt: &blaat; en op wat voor niveau dan ook wordt je CDATA section omgezet naar gewone parsed text, dan wordt het omgezet naar &blaat;. Je moet er dus voor zorgen er nooit entities in een CDATA section voorkomen als je die niet zo wilt zien in je output (en dat wil je bijna nooit). De beste manier om dit te voorkomen is volgens mij je om helemaal niet met het herschrijven naar entiteiten bezig te houden: dat is iets voor een DOM implementatie of XML outputter.

wat betreft w3c vriendelijkheid... ik meen dat het standaard is dat je ë gebruikt in de source en niet ë of is dat nu weer veranderd? (microsofts xmlhttp object loopt bijvoorbeeld stuk op ë)

De vereisten voor well-formed zijn van een XML document hebben eigenlijk alleen gevolgen voor wat specieke XML karakters als de <. Verder mag je alle bijzondere tekens opnemen, zolang die maar in de encoding passen die je aangeeft. met e" is dus helemaal niets mis, het is immers helemaal geen gereserveerd XML karakter.

Als het xmlhttp object van Microsoft hier niet goed mee omgaat (om wat voor reden dan ook), is het waarschijnlijk niet compatible en moet je wellicht upgraden.

Als je een XML request over HTTP gaat versturen moet je er uiteraard ook even rekening mee houden dat de goede charset wordt opgenomen in de Content-Type header...