jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anton_slutsky <aslut...@applevac.com>
Subject Re: [JCR Browser] SessionImpl.export*View() serialize with prolog set to UTF-8
Date Fri, 09 Mar 2007 16:45:27 GMT

Hey Jukka,

Basically, Session.importXml() blows up when the following string is present
as a value of a property in my serialized xml: "Español".  The "ñ" character
is causing the problem.  With encoding="UTF-8", my sax parser complains
about an invalid character.  If I set encoding to UTF-16, the problem goes

It could be a parser issue, but still ...



Jukka Zitting wrote:
> Hi,
> On 3/9/07, anton_slutsky <aslutsky@applevac.com> wrote:
>> I'm running into a nasty little problem with the export*View() methods on
>> Session.  It looks like the OutputStream implementation has the encoding
>> part of the xml prolog hardcoded to UTF-8.  Thats fine for serializing,
>> but
>> blows up when deserializing if I have any non-ascii content (my app is
>> i18n'd to spanish).  I've written a workaround and used my own
>> ContentHandler, but I'm wondering if UTF-8 is big enough for general
>> usage?
> Do you have some alternative in mind? I don't see anything wrong with
> UTF-8, it's as standard as it gets when working with Unicode and
> internationalized applications.
> If you need some specific encoding, then your solution is correct,
> i.e. use your own ContentHandler that serializes the data in whatever
> encoding you want. Using javax.xml.transform.sax.SAXTransformerFactory
> is probably the easiest standard way to achieve that.
> BR,
> Jukka Zitting

View this message in context: http://www.nabble.com/SessionImpl.export*View%28%29-serialize-with-prolog-set-to-UTF-8-tf3376445.html#a9398024
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message