<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
It occurs to me just now that maybe the best approach is to make it parse according to the standards we all expect. "123" for decimal, "0x3E" for hex, etc. That would require no interface change, but would suddenly work for new numeric bases in a standard way.<BR>
On Wed, 2004-10-20 at 03:43, Bradley S. Huffman wrote:
<PRE><FONT COLOR="#737373"><I>JDOM always escapes with the hex notation and doesn't provide a way to
change that. However escapeElementEntities and escapeAttributeEntities
are the only methods that use EscapeStrategy and are public in XMLOutputter
so you could extend it, cut and paste those two methods, and change the
2 lines with Integer.toHexString to Integer.toString. Maybe not the most
elegant solution, but it should work.
"Mark C. Stafford" writes:
> I'm working with MySQL and Microsoft's Great Plains (Pains). GP is not
> happy with unicode characters unless they're escaped *using decimal
> notation*. Neither have I succeeded in defining an ENTITY that it
> I've implemented an EscapeStrategy which is working well, but have not
> found a property or method that will allow me to choose to "degrade"
> the encoding.
> &#xf1; crashes, but &#241; (tested by hand) works.
> I'm holding up a data conversion. Can you help me? Is this the right
> place to ask? I thought I'd check before resorting to some sort of
> String-based re-parsing with regexp...
> <?xml version="1.0" encoding="UTF-8"?>
> <eConnect xmlns:dt="urn:schemas-microsoft-com:datatypes">
> <!-- <snip/> -->
> <ADDRESS1>Villa Espa&#xf1;a Zaragoza</ADDRESS1>
> <!-- <snip/> -->
> To control your jdom-interest membership:
> </FONT><A HREF="http://email@example.com"><U>http://firstname.lastname@example.org</U></A>
To control your jdom-interest membership:</FONT>