Antoine Levy-Lambert wrote:
I have checked in some code lately related to URI encoding and decoding.
BTW should use java.net.URI and File.toURI and new File(URI) when running on JDK 1.4+. I have an old outstanding bug for this, needs to be reexamined:
http://issues.apache.org/bugzilla/show_bug.cgi?id=8031
One bug report was about the impossibility to load properly a jar file having in his manifest a Class-Path attribute pointing to another jar file in a subdir, when the main jar file is in a directory containing spaces.
Note that a relative path in Class-Path is really a URI and must be encoded. E.g.
Class-Path: some%20other%20lib.jar
The other bug report was about entities not found when processing with <xslt/> an XML document located in a non ascii path and referring to entities in the same directory.
May be completely unrelated, but I recently found a JDK bug sounding very similar to this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6341770
Now I am testing manifestclasspath. I tested it with änt (a umlaut nt, or ã) . this works. Now with a directory bearing a hebrew name (iom = םוי ) it does not work.
Just a guess: maybe you forgot to encode in UTF-8 before encoding to %xx octets? That could cause problems for non-ISO-8859-1 text.
-J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
