Re: charset used for parameters decoding on HTTP request Tomcat3.x,4

[Tim Tye]

Title: charset used for parameters decoding on HTTP request Tomcat3.x,4



Because of the way byte values are URL encoded, (and the way tomcat decodes 
them.) What you usually receive with get parameters is a byte stream one byte 
per character.  You can post process the string obtained by getParameter by 
converting it back to a byte array, then convert to a string and specify the 
encoding.
 

  - Original Message - 
  From: 
  Adalbert 
  Wysocki 
  To: [EMAIL PROTECTED] 
  Sent: Monday, February 12, 2001 12:00 
  PM
  Subject: charset used for parameters 
  decoding on HTTP request Tomcat3.x,4
  
  Hi all, 
  I would like to know the policy for the request's parameters 
  decoding in Tomcat 3.x. In Servlet 2.3 specifications 
  a new method on the HttpServletRequest object was added in order to be able to 
  specify the request's parameters charset encoding. This charset is used 
  futhermore while the parameters parsing. This method is implemented in Tomcat 
  4.
  What is about Tomakat 3.2 implementing the servlet 2.2 
  specifications where the charset for parameters' decoding cannot be specified 
  and considering that browsers never send the form encoding charset in th 
  erequests' headers. In the case pages generated by my servlet run with Tomcat 
  3.2 are UTF-8 encoded, and requests for theses pages contain UTF-8 encoded 
  parameters, how can I specify to the servlet engine running my servlet to 
  decode parameters from UTF-8 and not using the default plateform encoding 
  (8859-J, Shift_JIS (for japan plateforms)...).
  These are my questions: --- 
    - is Tomcat 3.2 supports double byte encoded parameters 
  (I sew that parameters are parsed with javax.servlet.http.HttpUtils that does 
  not support double byte encoded parameters)
    - if it is possible, how to do it. 
  NB: A solution would be to overwrite the system property 
  "file.encoding" on the command line. But on exotic platforms (such as Korean), 
  overwriting the property "file.encoding" on the command line while the servlet 
  engine starting is not taken under consideration while the default 
  characters-bytes/bytes-characters converters instantiation (this behavior is 
  listed in Sun's bugs list but is not considered as a bug). In these cases the 
  default plateform encoding is used.
  Adalbert 
  Adalbert Wysocki, software engineer  
  phone: +33 (0)1 71.00.68.67 fax: +33 
  (0)1 71.00.68.02 

Re: charset used for parameters decoding on HTTP request Tomcat3.x,4

[Tim Tye]

You will still need to fix the actual parameter parsing routine to delay
applying the encoding until the name and parameter are parsed out of the
input stream...

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 12, 2001 1:14 PM
Subject: Re: charset used for parameters decoding on HTTP request
Tomcat3.x,4


> > I would like to know the policy for the request's parameters decoding in
> > Tomcat 3.x.
>
> AFAIK there are still problems in both 3.2.x and 3.3(dev). Fixing this is
> one of the highest things on my todo list, and you should expect a
> solution before 3.3 beta ( i.e. in about a month ).
>
> The solution will likely use a special module that will try to "guess" the
> encoding using the common hints ( Content-Type, Accept-Language, the
> common solution of passing a charset parameter ). It is not possible to
> use the setCharset() method from Servlet2.3 - but in most cases you'll not
> have to.

Good Idea.
BTW, Netscape navigator 4.7x seems to return the charset header value when
it is not the same as the default encoding.

Tim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Tomcat file locations on Unix

[Tim Tye]

- Original Message -
From: Guillaume Rousse <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 21, 2001 7:23 AM
Subject: Re: Tomcat file locations on Unix


> On 2001.02.21 13:18:00 +0400 Rolf Veen wrote:
> > > From what i'm seeing on my own system (Mandrake 7.2), general services
> > > (ftp, www, etc) have their own
> > > /var/name dir, while specific applications (postgres, wine, etc...)
> > have
> > > their /var/lib/name dir.
> > > >
> > $PKGS/tomcat/
> >  /conf
> >  /bin
> >  /lib
> >  /doc
> >  /src
> >  /log(a symlink to /var/log/tomcat as a last resort)
> >  /META-INF   (yes, a meta directory to be used by generic
> > tools)
The beauty of Unix is that a product may be installed anywhere the product
designers want, then the directories moved to where the need to be with
symlink providing the connection between simple design, and safe usable file
system layout.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Implementation in 4.0.b1

[Tim Tye]

Where is the interface document for tomcat object factories?
I would like to have an object factory for JBoss context.

- Original Message -
From: Remy Maucherat <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 09, 2001 7:13 PM
Subject: Re:   Implementation in 4.0.b1


> > I am trying to obtain a remote reference to an EJB in another machine.
> > I have set the ejb-ref in web.xml as follows:
> > 
> > Sample bean generated by coolgen placed here for ease
of
> >  early testing
> > ejb/S_STRESS_32K
> > Session
> > cool.models.coop07.java.S_STRESS_32KpsHome
> > cool.models.coop07.java.S_STRESS_32Kps
> > jndi:/ttt1.ca.com:1099/S_STRESS_32Kps
> > 
> > However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a
null
> > reference instead of the necessary remote reference to the home
interface.
> > Is ejb-link implemented and documented?
> > Which code is involved in ejb-link lookup?
> > Is this fixed in the latest 4.0?
>
> Tomcat 4 will parse the web.xml file and bind references to the specified
> resources in the naming environment. To be able to resolve those
references,
> TC needs an appropriate object factory. If no object factory is available,
> null is returned when you do a lookup.
>
> Right now, there are two factories :
> - one for getting Tyrex managed data sources
> - one for getting Tyrex UserTransactions
> You can easily add additional factories for additional resource types
(EJBs,
> JMS resources ...). Contributed object factories (provided they are
generic
> enough) could be added to the repository.
>
> Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Implementation in 4.0.b1

[Tim Tye]

The EJB 2.0 Draft specification does specify  via  as the
connection between different EJB containers.  Also, all naming lookup does
go through a JNDI interface usually starting at a local InitialContext.
I can send you the section describing this in the EJB specification on
Monday.

- Original Message -
From: Aaron Mulder <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 10, 2001 7:40 AM
Subject: Re:   Implementation in 4.0.b1


> I'm a little confused by all of the discussion around this.
> Acoording to the spec, the  is supposed to have the name of
> an EJB deployed in the same application unit.  In other words, no JNDI
> stuff, no factories, just a name.  "MyBean", or whatever.
> If Tomcat wants you to put JNDI stuff in there, isn't that an
> abuse of the spec?  Shouldn't Tomcat be using a separate server-specific
> deployment descriptor to provide the extra information to reference beans
> that are in a different application (i.e. those that require cusotm JNDI
> settings)?
>
> Aaron
>
> On Fri, 9 Mar 2001 [EMAIL PROTECTED] wrote:
> > Weining Qi writes:
> >
> > > if you are running tomcat 3.x in the same window (tomcat run), look at
the
> > > feedback from tomcat when call the ejb that way, you can see that
tomcat
> > > does not recognize the namespace "java:com/env/" for calling ejb as
> >   The name is "java:comp/ejb"  NOT --.
> >   And yes tomcat does recognize it
> >   Because it is defined in web.xml as shown in the snip.
> >
> > > the sun j2ee specification v1.3. you should call ejb directly by its
jndi
> > > name, which you gave when you deployed it.
> > I tried that, it does not work.  I get "NamingException".
> > Note: the EJB is deployed in a different machine than tomcat.
> > When I try to open the context to that machine directly from a servlet
in
> > tomcat, I get:
> > javax.naming.NoInitialContextException: Cannot instantiate class:
> > org.jnp.interfaces.NamingContextFactory.  Root exception is
> > java.lang.ClassCastException: org.jnp.interfaces.NamingContextFactory
> > at
> > javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:659)
> > at
> > javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:250)
> > at javax.naming.InitialContext.init(InitialContext.java:226)
> > at javax.naming.InitialContext.(InitialContext.java:202)
> > at SimpleServlet.printContextInfo(SimpleServlet.java:168)
> > at SimpleServlet.doIt(SimpleServlet.java:99)
> > at SimpleServlet.doGet(SimpleServlet.java:30)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:573)
> > at
> >
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
er.java:321)
> > at
> >
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
.java:236)
> > at
> >
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java
:386)
> > at
> >
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:215)
> > at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
> > at
> >
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:180)
> > at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
> > at
> >
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:180)
> > at
> >
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:251)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> > at
> >
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:196)
> > at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
> > at
> >
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:464)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
> > at
> >
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
> > at
> >
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161
)
> > at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
> > at
> >
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
> > at
> >
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:159)
> > at
> > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> > at
> >
org.apache.catalina.connector.ht

Re: Strange problem with URL_PKG_PREFIXES

[Tim Tye]

According to NamingManager documentation, first it will look for
'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so it
should next look for 'org.apache.naming.java.javaURLContextFactory' which
does exist.
So, this should work.
BTW, the 'org.apache.naming' prefix is concatenated onto the URL prefixes by
jakarta.  Also, when the jnp.jar is removed, it still fails with the same
error.
How can this be made to work?

- Original Message -
From: Remy Maucherat <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 5:49 PM
Subject: Re: Strange problem with URL_PKG_PREFIXES


> > The Context.URL_PKG_PREFIXES environment variable is a colon-seperated
> list
> > of package prefixes.  However, when I set this environment variable to
> > "org.jnp.interfaces:org.apache.naming" and attempt to get a Context;
> >   Context ctx = new InitialContext().lookup("java:/comp");
> > The lookup fails with:
> > javax.naming.ConfigurationException: Provider URL missing
> > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:702)
>
> > However, when I set this environment variable to
> > "org.apache.naming:org.jnp.interfaces"
> > The lookup succeeds!
> > "org.jnp.interfaces" only contains one class and that is
> > "org.jnp.interfaces.jnp.jnpURLContextFactory".
> > It seems to me that the lookup code is not correctly parsing the
> > Context.URL_PKG_PREFIXES environment variable.
>
> It looks like the JNP InitialContext has a custom way to retrieve URL
> contexts.
> It's supposed to call NamingManager.getURLContext (see the
> javax.naming.InitialContext source code for more details).
>
> Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: JDBC-Session store

[Tim Tye]

In the Java world, varchar should support UNICODE characters, not 8-bit
bytes.
Yes, I know some data bases do not store UNICODE, but some (Oracle,
InstantDB etc) do.  The other problem with character, is character encoding,
when/if the encoding of the application does not match the native character
encoding of the table, a translation is performed, and the results are not
always reversible.
The correct type used to store serialized data is byte, or varbyte, or even
blob.
Remember, Java characters are unsigned sixteen bit numbers not eight bit
data elements (called char by 'C', 'C++' and many databases).

- Original Message -
From: Krishna R. Baddam <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 7:25 PM
Subject: RE: JDBC-Session store


> Blob is a bad idea. Serialize the objects and store them as varchar. We
> implemented a home grown session store and the varchar route works lot
> better. I believe IBM's WebSphere session store also uses varchars.
>
> Krishna
>
> -Original Message-
> From: Bip Thelin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 2:13 AM
> To: [EMAIL PROTECTED]
> Subject: JDBC-Session store
>
>
> I've been looking at the FileStore implementation and you(Kief/Craig)
> basically
> store a java object in the textfile, using the same approach with a DB
> usually(?!)
> involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want
to
> store
> the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of
> reluctant
> to save objects in to a RDBMS and sort or "overriding" the native formats.
>
> Have anyone got any ideas on how to solve this in a good way? Preferably
so
> it would
> work with JDBC < 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go
> ahead and
> implement it as either a blob or a STRUCT whichever works out best.
>
> Thanks, Bip
>
>

Re: Using JNDI with Jakarta-Tomcat 4.0 beta 3

[Tim Tye]

- Original Message -
From: Remy Maucherat <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 1:47 PM
Subject: Re: Using JNDI with Jakarta-Tomcat 4.0 beta 3


> > Hi,
> >
> > I have been using Jakarta-Tomcat 3.2.1 and when I upgraded to the 4.0
beta
> 3
> > I have a propblem with my JNDI configuration.
> >
> > I have a servlet that uses an EJB container that requires the following
> > "jndi.properties" :
> >
> > java.naming.factory.initial
> > com.sun.jndi.rmi.registry.RegistryContextFactory
> > java.naming.provider.url rmi://localhost:1099
> > java.naming.factory.url.pkgs   org.objectweb.jonas.naming
> >
> > With 3.2.1 I just needed to make sure that I had my jndi.properties file
> on
> > the classpath, with 4.0 beta 3 I do not seem to be able to get this read
> by
> > any means. The only mechanism that I found to get this to work is if I
> call
> > "System.setProperty()" in my servlet just before I call "new
> > javax.naming.InitialContext()". If I do not do this I get the following
> > error message:
> >
> > javax.naming.NoInitialContextException: Cannot instantiate class:
> > org.apache.naming.java.javaURLContextFactory.  Root exception is
> > java.lang.ClassCastException:
org.apache.naming.java.javaURLContextFactory
> >
> >
> > Can anyone tell me how I am supposed to set this for my servlet? I tried
> the
> > following without any success:
> >
> > 1) Using env-entry in my WEB-INF/web.xml
> > 2) Putting the jndi.properties into the classpath
>
> That will fail, since Catalina ignores your classpath.
> Try putting the jndi.properties in common/classes/jndi.properties. It
should
> work better.
>
> Note that to use JNDI related stuff (esp with load-on-startup), I
recommend
> using the latest nightly.
>
> Remy
>
I have also had success in 4.0 B2 setting the -D
java.naming.factory.url.pkgs=org.objectweb.jonas.naming
parameter on Tomcat Start script.
Then I use ctx.lookup("rmi://localhost:1099"); to obtain the context of the
ejb server.
Also, 4.0 B2 supports the  tags including the full redirection of
the lookup to the EJB server (via url factory context)..
Tim

Re: [PROPOSAL] Revised Tomcat 4.0-beta-2 Release Plan

[Tim Tye]

> "Craig R. McClanahan" wrote:
> >
> > Over the last week or so, there has been some interest in changes to Tomcat
> > 4.0-beta-1, including some changes in fundamental APIs within Catalina.  It
> > would be desireable to make these changes before a 4.0 release is completed, so
> > that we can strive to maintain API compatibility, to the maximum degree
> > possible, throughout the 4.x lifetime.
> >
> > Therefore, I would like to propose "unfreezing" the 4.0 codebase, and opening it
> > again to new development, with some of the major items listed below.  The
> > revised release plan for Tomcat 4.0 Beta 2 would then become:
> >
> > Proposed Release Manager: Craig McClanahan (unless someone
> > else wants to volunteer for this part)
> > Proposed Code Freeze Date:  February 5, 2001 (two weeks from today)
> > * Miscellaneous bug fixes from BugRat reports, as well as bug reports
> >   on the mailing lists.  (a variety of patches have already been proposed).
> >
> > Craig McClanahan

I would like to see the encoding of the input stream fixed in this release also.  At
least use the value of ServletRequest.setCharacterEncoding() to specify the encoding
of parameter names and values.  (BugRat #785).
I will do the work on this one.
And, If my vote counts +1

Tim Tye


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java

[Tim Tye]

Since characters in Java are UNICODE, what does this code do when it encounters a 
character who's code point is greater than 0xFF?
My suggestion, is to first encode the path as a UTF-8 byte array, then encode the 
bytes according to this algorithm
Tim

[EMAIL PROTECTED] wrote:

> remm01/01/29 19:50:09
>
>   Modified:catalina/src/share/org/apache/catalina/servlets
> DefaultServlet.java
>   Log:
>   - Will now encode all unsafe characters on the URL.
>
>   Revision  ChangesPath
>   1.22  +84 -28
>jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
>
>   Index: DefaultServlet.java
>   ===
>   RCS file: 
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
>   retrieving revision 1.21
>   retrieving revision 1.22
>   diff -u -r1.21 -r1.22
>   --- DefaultServlet.java   2001/01/25 05:45:40 1.21
>   +++ DefaultServlet.java   2001/01/30 03:50:08 1.22
>   @@ -1,7 +1,7 @@
>/*
>   - * $Header: 
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
> 1.21 2001/01/25 05:45:40 remm Exp $
>   - * $Revision: 1.21 $
>   - * $Date: 2001/01/25 05:45:40 $
>   + * $Header: 
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
> 1.22 2001/01/30 03:50:08 remm Exp $
>   + * $Revision: 1.22 $
>   + * $Date: 2001/01/30 03:50:08 $
> *
> * 
> *
>   @@ -76,6 +76,7 @@
>import java.io.Reader;
>import java.io.InputStreamReader;
>import java.io.Writer;
>   +import java.io.OutputStreamWriter;
>import java.net.MalformedURLException;
>import java.net.URL;
>import java.net.URLEncoder;
>   @@ -87,6 +88,7 @@
>import java.util.Locale;
>import java.util.TimeZone;
>import java.util.Hashtable;
>   +import java.util.BitSet;
>import java.text.ParseException;
>import java.text.SimpleDateFormat;
>import java.security.MessageDigest;
>   @@ -119,7 +121,7 @@
> *
> * @author Craig R. McClanahan
> * @author Remy Maucherat
>   - * @version $Revision: 1.21 $ $Date: 2001/01/25 05:45:40 $
>   + * @version $Revision: 1.22 $ $Date: 2001/01/30 03:50:08 $
> */
>
>public class DefaultServlet
>   @@ -219,6 +221,40 @@
> StringManager.getManager(Constants.Package);
>
>
>   +/**
>   + * Array containing the safe characters set.
>   + */
>   +protected static BitSet safeCharacters;
>   +
>   +
>   +protected static final char[] hexadecimal =
>   +{'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
>   + 'A', 'B', 'C', 'D', 'E', 'F'};
>   +
>   +
>   +// - Static Initializer
>   +
>   +
>   +static {
>   + safeCharacters = new BitSet(256);
>   + int i;
>   + for (i = 'a'; i <= 'z'; i++) {
>   + safeCharacters.set(i);
>   + }
>   + for (i = 'A'; i <= 'Z'; i++) {
>   + safeCharacters.set(i);
>   + }
>   + for (i = '0'; i <= '9'; i++) {
>   + safeCharacters.set(i);
>   + }
>   + safeCharacters.set('-');
>   + safeCharacters.set('_');
>   + safeCharacters.set('.');
>   + safeCharacters.set('*');
>   + safeCharacters.set('/');
>   +}
>   +
>   +
>// - Public Methods
>
>
>   @@ -853,7 +889,7 @@
> replaceChar +
> normalized.substring(index + 3);
>}
>   -
>   +
> // Normalize the slashes and add leading slash if necessary
> if (normalized.indexOf('\\') >= 0)
> normalized = normalized.replace('\\', '/');
>   @@ -902,29 +938,49 @@
> * @param path Path which has to be rewiten
> */
>protected String rewriteUrl(String path) {
>   -
>   -String normalized = path;
>   -
>   - // Replace " " with "%20"
>   -while (true) {
>   - int index = normalized.indexOf(" ");
>   - if (index < 0)
>   - break;
>   - normalized = normalized.substring(0, index) + "%20"
>   - + normalized.substring(index + 1);
>   - }
>   -
>   - // Replace "&" with "%26"
>   -while (true) {
>   - int index = normalized.indexOf("&");
>   - if (index < 0)
>   - break;
>   - normalized = normalized.substring(0, index) + "%26"
>   - + normalized.substring(index + 1);
>   - }
>   -
>   -return normalized;
>   -
>   +
>   +/**
>   + * Note: This code portion is very similar to URLEncoder.encode.
>   + * Unfortunately, there is no way to specify to the URLEncoder which
>   + * characters should be encoded. Here, ' ' should be encoded as "%20"
>   + * and '/' shouldn't 

Re: Bugzilla categories

[Tim Tye]

Sounds good to me.
Tim
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 02, 2001 11:58 PM
Subject: Bugzilla categories


> Hi,
>
> What about another category - "Encoding" for all encoding-related bugs ?
> ( that would include all "special chars", charsets, etc). It's a big
> issue and I want to have all the related bugs grouped togheter.
>
> ( I'll work on them - but it's not easy and will take few weeks to sort it
> out )
>
> --
> Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: serializing XML to a ServletOutputStream fails

[Tim Tye]

UTF-16 is not an acceptable encoding for XML as it takes two bytes per
character, is byte order sensitive, and the XML tags would not be
recognized...
UTF-8 is the correct encoding!  Any 31 bit character in the ISO10646
specification can be correctly represented in UTF-8.  UNICODE is the first
65768 characters of ISO10646.
A CKJ character code point value of 0x6123 is represented in UTF-8 as three
bytes E6 84 A3.
What byte values are you seeing for the encoding of a given Chinese code
point?

- Original Message -
From: Zhu Ming <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 05, 2001 4:24 AM
Subject: RE: serializing XML to a ServletOutputStream fails


> Hi,
>
> Maybe you should not use character set "UTF-8". I remember
> that it's 8-bit Unicode. As I know, Chinese and Korean has
> 16-bit code. So at least, you should try 16-bit Unicode.
> I forgot the name, maybe it's "UTF-16". But I'm not sure if
> JDK have fully support to "UTF-16".
>
> I'm not an Unicode expert. I'll be happy if what I say can
> be a hint to solve this problem.
>
> Ming
>
>
> -Original Message-
> From: Michael Mealling [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 05, 2001 03:04
> To: [EMAIL PROTECTED]
> Subject: serializing XML to a ServletOutputStream fails
>
>
> (This might be a bug so I'm cc-ing to tomcat-dev)
> Hi,
> I'm trying to serialize some XML out to a ServletOutputStream but
> the resulting XML on the client side contains corrupted Unicode
> characters (the DOM I'm serializing out contains Chinese, Korean,
> English, etc). Here's the code in question:
>
> response.setContentType("text/xml; charset=UTF-8");
> ServletOutputStream out = response.getOutputStream();
>
> out.print("\n" +
>"" \"http://www.ietf.org/cnrp.dtd\">\n");
> out.flush();
> OutputFormat format = new OutputFormat(document);
> format.setOmitXMLDeclaration(true);
> format.setIndenting(true); // it makes debuggin easier
> format.setEncoding("UTF-8"); // this is the default anyway
> XMLSerializer serializer = new XMLSerializer(out, format);
> serializer.serialize(document.getDocumentElement());
>
> The XML that the client gets is fine except that the non-ASCII subset
> of the UTF-8 encoded Unicode characters are garbled. I can serialize
> the XML out to a FileOutputStream and it works just fine.
>
> I'm running Tomcat 3.2.1 that's the backend for a remote
> Apache 1.3.17 server using ajp13 (and thus mod_jk).
>
> This code looks like its the right way to do this but either
> I've hit a bug or else I'm missing something (an encoding somewhere
> between a Stream and a Writer?)
>
> -MM
>
> --
> --
--
> 
> Michael Mealling |  Vote Libertarian!   | www.rwhois.net/michael
> Sr. Research Engineer   |   www.ga.lp.org/gwinnett | ICQ#:
> 14198821
> Network Solutions |  www.lp.org  |  [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]