:strip_icc():strip_exif()/u/32734/crop5ee11f3ba965d_cropped.jpeg?f=community)
Ik probeer een xml doc middels xslt om te zetten naar een html doc. Werkt allemaal prima, op 1 ding na.
De translate functie:
Output escaping moet ik nog even netter doen.
De xsl is als volgt:
De resulterende html file is dus helemaal prima, zoals gezegd, alleen worden CRLFs niet weergegeven. In de html file komen wel CRLFs terecht, maar lange zinnen worden afgebroken (allemaal op ongeveer dezelfde lengte) met een eenzame LF, dus zonder CR. Op sommige plekken staan echter wel CRLFs, alleen niet op alle plekken waar ze in de bron xml staan.
Op zich zou het ook geen probleem zijn wanneer ik het doel document alleen in een browser zou bekijken. Jammer genoeg wordt de html als e-mail verstuurd. De meeste mailservers vinden het zo prima, maar ... er zijn een paar mailservers die een eenzame LF een doodzonde vinden, en om die reden de mail gewoon niet accepteren.
Ik had via Google al iets gevonden over Xalan en waar die zich op baseerd mbt de newline chars. Volgens die site zou System.getProperty("line.separator") als uitgangspunt gebruikt worden, maar volgens mijn test is die CRLF, en niet LF.
Iemand een idee hoe ik Xalan wijs kan maken dat hij CRLF moet gebruiken als newline char? Of beter nog, hoe ik Xalan kan vertellen dat hij mijn regels niet moet afbreken (en daar al helemaal geen LF voor moet gebruiken?)
[edit] Mijn laatste redmiddel zou een String replace in de send methode zijn, die alle solo LFs eruit vist. Duidelijk niet de efficientste oplossing, dus als ik hier echt niet uit kom ga ik dat pas overwegen.
De translate functie:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| public static String translate(String xml, String xsl) throws XmlException { try { TransformerFactory tf = TransformerFactory.newInstance(); Source xslSource = new StreamSource(new StringBufferInputStream(xsl)); Source xmlSource = new StreamSource(new StringBufferInputStream(xml)); Transformer optimus = tf.newTransformer(xslSource); StringWriter sw = new StringWriter(); optimus.transform(xmlSource, new StreamResult(sw)); return sw.toString().replaceAll("<", "<").replaceAll(">",">").replaceAll(""","\""); } catch(TransformerException e) { throw new XmlException("translate fout:" +e); } } |
Output escaping moet ik nog even netter doen.
De xsl is als volgt:
XSLT:
1
2
3
4
5
| <?xml version='1.0' encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xalan="http://xml.apache.org/xslt"> <xsl:output method="html" encoding="utf-8" indent="yes" cdata-section-elements="item itemmovable" /> |
De resulterende html file is dus helemaal prima, zoals gezegd, alleen worden CRLFs niet weergegeven. In de html file komen wel CRLFs terecht, maar lange zinnen worden afgebroken (allemaal op ongeveer dezelfde lengte) met een eenzame LF, dus zonder CR. Op sommige plekken staan echter wel CRLFs, alleen niet op alle plekken waar ze in de bron xml staan.
Op zich zou het ook geen probleem zijn wanneer ik het doel document alleen in een browser zou bekijken. Jammer genoeg wordt de html als e-mail verstuurd. De meeste mailservers vinden het zo prima, maar ... er zijn een paar mailservers die een eenzame LF een doodzonde vinden, en om die reden de mail gewoon niet accepteren.
Ik had via Google al iets gevonden over Xalan en waar die zich op baseerd mbt de newline chars. Volgens die site zou System.getProperty("line.separator") als uitgangspunt gebruikt worden, maar volgens mijn test is die CRLF, en niet LF.
Iemand een idee hoe ik Xalan wijs kan maken dat hij CRLF moet gebruiken als newline char? Of beter nog, hoe ik Xalan kan vertellen dat hij mijn regels niet moet afbreken (en daar al helemaal geen LF voor moet gebruiken?)
[edit] Mijn laatste redmiddel zou een String replace in de send methode zijn, die alle solo LFs eruit vist. Duidelijk niet de efficientste oplossing, dus als ik hier echt niet uit kom ga ik dat pas overwegen.
[ Voor 25% gewijzigd door zneek op 11-01-2005 15:24 ]