In his example ( where both XML and JSP declare encodings ) - which one would win ?
IMO the XML encoding should win i.e. if the file uses xml syntax and starts with <?xml version="1.0" encoding="iso-8859-2" ?>, then jsp pageEncoding should be ignored. If a jsp is written using the XML syntax - it is supposed to follow the XML rules - there is no exception in the XML spec for jsps specifying their different syntax for encoding. For non-XML jsps - I think respecting pageEncoding is a must, the jsp reader must scan the file to find the pageEncoding string - which is not trivial ( there is a reason why XML requires the encoding to be the first thing in the file, at the top, I would't bet on jasper implementing it correctly :-) Costin On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote: > > > > > -----Original Message----- > > From: Jean-frederic Clere [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 17, 2006 4:13 AM > > To: Tomcat Developers List > > Subject: Re: svn commit: r386315 - > > /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa > > rserController.java > > > > Bill Barker wrote: > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > >>Sent: Thursday, March 16, 2006 3:55 AM > > >>To: tomcat-dev@jakarta.apache.org > > >>Subject: svn commit: r386315 - > > >>/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa > > >>rserController.java > > >> > > >>Author: jfclere > > >>Date: Thu Mar 16 03:54:29 2006 > > >>New Revision: 386315 > > >> > > >>URL: http://svn.apache.org/viewcvs?rev=386315&view=rev > > >>Log: > > >>If the encoding is not specified use the detected one. > > >> > > >> > > >> > > > > > >-1. > > >If it gets to this point, the detected encoding is *wrong* > > (e.g. <?xml > > >version="1.0" encoding="iso-8859-2" ?> in JSP syntax). > > > > > Why wrong? > > Because the right encoding is the one specified in the <[EMAIL PROTECTED] > pageEncoding="utf8"%>. > > > +++ > > Connected to localhost. > > Escape character is '^]'. > > GET /try1.jsp > > <?xml version="1.0" encoding="ISO-8859-2"?> > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > > +++ > > > > This is about pageEncoding, so I don't see the relevance. > > > > > > > > > >I don't have access to an EBCDIC machine to know what the > > problem is, but > > >this isn't the fix. Possibly a better way to guess the > > encoding of the > > >Reader? > > > > > > > > Thinking to it the patch is not prefect but the old code is worse we > > have a piece of code that detects correctly the source encoding and > > detroy it... > > > > However, the old code adheres to the JSP spec, whereas your patch breaks > the > JSP spec (Appendix D). That automatically makes the old code better than > your patch. > > > In doParse() in ParserController.java the following happends > > parse() is called with pageEnc = sourceEnc > > jspConfigPageEnc = null > > isDefaultPageEncoding = false. > > But the line before the jspReader uses the sourceEnc to create the > > InputStreamReader so the content of the file is translated to > > utf-8 when > > reading it. > > In validator.java the charset will be set to the detected > > encoding... In > > the example above iso-8859.2. Bad for me that will be > > OSD_EBCDIC_DF04_1. > > > > The only issue is why Jasper can't recognize your <[EMAIL PROTECTED] > pageEncoding="OSD_EBCDIC_DF04_1" %> statement. That's the part that I > can't > figure out (and your patch is masking :). > > > Cheers > > > > Jean-Frederic > > > > > > > > > > > > > > > > >This message is intended only for the use of the person(s) > > listed above as the intended recipient(s), and may contain > > information that is PRIVILEGED and CONFIDENTIAL. If you are > > not an intended recipient, you may not read, copy, or > > distribute this message or any attachment. If you received > > this communication in error, please notify us immediately by > > e-mail and then delete all copies of this message and any attachments. > > > > > >In addition you should be aware that ordinary (unencrypted) > > e-mail sent through the Internet is not secure. Do not send > > confidential or sensitive information, such as social > > security numbers, account numbers, personal identification > > numbers and passwords, to us via ordinary (unencrypted) e-mail. > > > > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > This message is intended only for the use of the person(s) listed above as > the intended recipient(s), and may contain information that is PRIVILEGED > and CONFIDENTIAL. If you are not an intended recipient, you may not read, > copy, or distribute this message or any attachment. If you received this > communication in error, please notify us immediately by e-mail and then > delete all copies of this message and any attachments. > > In addition you should be aware that ordinary (unencrypted) e-mail sent > through the Internet is not secure. Do not send confidential or sensitive > information, such as social security numbers, account numbers, personal > identification numbers and passwords, to us via ordinary (unencrypted) > e-mail. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
