2010-06-09 8 views
7

Mam następujący DOMJak zatrzymać przekształcanie XmlSerializer ê na & # 234; w atrybucie?

<row> 
     <link href="B&#252;ro.txt" target="_blank"> 
      my link 
     </link> 
    </row> 

Kiedy szeregować je do pliku przy użyciu Java XmlSerializer to wychodzi tak:

<row> 
     <link href="B&amp;#252;ro.txt" target="_blank"> 
      my link 
     </link> 
    </row> 

Czy istnieje jakiś sposób, aby kontrolować sposób XmlSerializer uchwyty uciekające w atrybuty? Czy powinienem robić to w inny sposób?

Aktualizacja

Pragnę również powiedzieć, że używam JRE 1.6. Byłem przy użyciu jre 1,5 do niedawna i jestem pewien, że to było w odcinkach „poprawnie” (czyli „&” nie uciekł)

Wyjaśnienie

DOM tworzony jest programowo. Oto przykład:

 Document doc = createDocument(); 
     Element root = doc.createElement("root"); 
     doc.appendChild(root); 
     root.setAttribute("test1", "&#234;"); 
     root.setAttribute("test2", "üöä"); 
     root.appendChild(doc.createTextNode("&#234;")); 

     StringWriter sw = new StringWriter(); 

     serializeDocument(doc, sw); 
     System.out.println(sw.toString()); 

Moje rozwiązanie tak naprawdę nie chcesz tego zrobić, ponieważ zaangażowany sporo zmiany kodu i testowania ale postanowiłem przenieść dane atrybutów do elementu CDATA. Problem został wyeliminowany.

Odpowiedz

2

Jak uzyskać DOM? Czy to może mieć z tym coś wspólnego? Próbowałem twojego przykładowego XML-a za pomocą standardowego DocumentBuilder (tylko b/c jestem bardziej obeznany z nim) używając Sun Java 6 i najnowszego Xerces-J (2.9.1), który zresztą pogarsza XmlSerializer na rzecz LSSerializer lub TrAX.

W każdym razie, korzystając z tej techniki, zserializowany dokument nie zawiera już odnośnika do znaku i jest konwertowany na "Büro.txt". Użyłem poniższy kod:

String xml = "<row>\n" 
    + "  <link href=\"B&#252;ro.txt\" target=\"_blank\">\n" 
    + "   my link\n" + "  </link>\n" + " </row>"; 

InputStream is = new ByteArrayInputStream(xml.getBytes()); 
Document doc = DocumentBuilderFactory.newInstance() 
    .newDocumentBuilder().parse(is); 

XMLSerializer xs = new XMLSerializer(); 
xs.setOutputCharStream(new PrintWriter(System.err)); 

xs.serialize(doc); 
+0

Dzięki +1. DOM jest tworzony programowo (appendChild itp.). Dodam wyjaśnienie do pytania. Właśnie odkryłem LSSerializiera, więc przyjrzę się temu. – paul

+0

Dobra, zobaczmy. Może ktoś inny zna lepsze rozwiązanie, ale podejrzewam, że niemożliwe jest (przynajmniej w czysty sposób) tworzenie odniesień do znaków w ten sposób, ponieważ dane są traktowane jako takie, a nie instrukcje XML. Może być jednak źle ... Ponieważ zarówno XML, jak i Java są znane z Unicode, może nie być tak źle. – musiKk

4

Problemem jest to, że budujemy DOM z wartościami atrybutów, które już „uciekły”, zgodnie z konwencjami XML. DOM (oczywiście) nie zdaje sobie sprawy, że to zrobiłeś i ucieka z ampersandu.

należy zmienić

root.setAttribute("test1", "&#234;"); 

do

root.setAttribute("test1", "\u00EA"); 

Innymi słowy, wykorzystanie ciągi składające się z prostych codepoints Unicode przy konstruowaniu DOM. XMLSerializer powinien następnie zamienić znaki Unicode na jednostki znaków zgodnie z wymaganiami ... w zależności od wybranego kodowania znaków dla dokumentu wyjściowego.

EDIT - Powodem, że może być jeszcze surowe widząc znaki zamiast odpowiednik znaku w pliku XML jest to, że Ouput XMLSerializer używa domyślnego kodowania dla XML; tj. UTF-8. Aby rozwiązać ten problem, należy użyć konstruktora XMLSerializer(OutputFormat), przekazując kod OutputFormat, który określa wymagane kodowanie znaków dla XML. (Wygląda na to, że używasz "ASCII".) Upewnij się, że używasz kompatybilnego kodowania znaków dla urządzenia OutputStream.

+0

+1 brzmi bardzo rozsądnie. Jednak próbowałem go i "\ u00EA" pozostaje nieprzetworzone. Wstawiam wartość atrybutu w atrybucie href znacznika zakotwiczenia, np. paul

+0

\ u00EA jest ucieczką Unicode Java.Jeśli jakoś pojawia się w danych wyjściowych w tej formie ... musi być uwzględnione w danych wejściowych, a nie jako znak Java lub literał ciągu. –

+1

Korzystanie z "ASCII" zamiast "UTF8", jak dobrze działa kodowanie. – Etan

Powiązane problemy