2009-06-29 4 views
2

Я не буду использовать класс javax.xml.transform.Transformer для выполнения некоторых XSLT переводов, например, так:Как вы предотвращаете трансформацию javax из экранирования пробелов?

TransformerFactory factory = TransformerFactory.newInstance(); 
StreamSource source = new StreamSource(TRANSFORMER_PATH); 
Transformer transformer = factory.newTransformer(source); 
StringWriter extractionWriter = new StringWriter(); 
String xml = FileUtils.readFileToString(new File(sampleXmlPath)); 
transformer.transform(new StreamSource(new StringReader(xml)), 
     new StreamResult(extractionWriter)); 
System.err.println(extractionWriter.toString()); 

Однако, независимо от того, что я делаю, я не могу показаться, чтобы избежать необходимости трансформатора конвертировать любой вкладки, которые были в исходном документе, эквивалентному их символьной сущности (	). Я попытался как:

transformer.setParameter("encoding", "UTF-8"); 

и:

transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8"); 

, но ни один из тех, кто помощи. У кого-нибудь есть предложения? Потому что:

&#9;&#9;&#9;&#9;&#9;<MyElement> 

выглядит действительно глупо (даже если он работает).

+0

В этом случае семантическая разность для XML (тогда XSLT) между ссылкой на символ caracter или фактическим символом Unicode. Также это касается Xalan (как кажется, ваш собственный ответ). Итак, тег rigth для этого ответа - 'xsltprocessor'. – 2010-09-10 18:50:01

ответ

2

Итак, ответ на этот вопрос оказался довольно хромым: обновите Xalan. Я не знаю, что было не так с моей старой версией, но когда я переключился на последнюю версию: http://xml.apache.org/xalan-j/downloads.html внезапно исчезновение объектов на вкладках просто исчезло. Спасибо всем за вашу помощь.

0

Иногда с такими вещами, заменяя их самостоятельно регулярным выражением, это не совсем плохой вариант, который, по крайней мере, заставит вас идти, пока вы не найдете лучший вариант позже.

+0

Спасибо за предложение. Я буду использовать его, если я абсолютно не смогу найти что-нибудь лучше, но мое желание избежать кулджей (и моя гордость, мои коллеги могут увидеть этот код когда-нибудь ;-)) помешает мне использовать его иначе. – machineghost

1

Вы можете попробовать использовать SAXTransformerFactory в сочетании с XMLReader.

Что-то вроде:

SAXTransformerFactory transformFactory = (SAXTransformerFactory) TransformerFactory.newInstance(); 
StreamSource source = new StreamSource(TRANSFORMER_PATH); 
StringWriter extractionWriter = new StringWriter(); 

TransformerHandler transformerHandler = null; 
try { 
    transformerHandler = transformFactory.newTransformerHandler(source); 
    transformerHandler.setResult(new StreamResult(extractionWriter)); 
} catch (TransformerConfigurationException e) { 
    throw new SAXException("Unable to create transformerHandler due to transformer configuration exception."); 
} 

XMLReader reader = SAXParserFactory.newInstance().newSAXParser().getXMLReader(); 
reader.setContentHandler(transformerHandler); 
reader.parse(new InputSource(new FileReader(xml))); 
System.err.println(extractionWriter.toString()); 

Вы должны быть в состоянии установить SAX-анализатор не включать игнорируемые пробелы, если он уже не сделать его по умолчанию. Я на самом деле не проверял это, но я делаю что-то подобное в одном из моих проектов.

+0

Спасибо за предложение, но снова (как я сказал Кристоферу Морли) дополнительный обрабатывающий слой после обработки - это действительно kludge; то, что я действительно ищу, - это способ сказать Transformer просто не конвертировать вкладки в ссылки на сущности в первую очередь. – machineghost

0

Есть ли причина, по которой вы читаете файл в строку сначала, а не напрямую с помощью потока файлов?

Вместо

String xml = FileUtils.readFileToString(new File(sampleXmlPath)); 
transformer.transform(new StreamSource(new StringReader(xml)), 
    new StreamResult(extractionWriter)); 

Вы можете попробовать

transformer.transform(new StreamSource(new FileReader(sampleXmlPath)), 
    new StreamResult(extractionWriter)); 

Это не может быть причиной этой проблемы, но я видел, что это вызывает аналогичные проблемы раньше. Если ваша FileUtils.readFileToString является версией Commons.IO, она считывает строку как UFT-16 (Java default, IIRC), а не то, что вы хотите, это UTF-8.

+0

Хотя я делаю <3 FileUtils, в этом конкретном случае я вообще не использовал его (у меня возникла такая же проблема, даже при запуске Xalan непосредственно из командной строки). – machineghost