- From: Addison Phillips [wM] <aphillips@webmethods.com>
- Date: Sun, 30 Nov 2003 22:09:55 -0500
- To: "Jungshik Shin" <jshin@i18nl10n.com>
- Cc: <public-i18n-geo@w3.org>
Hi Jungshik, > > You're absolutely right. Therefore, the charset declaration in a JSP > file serves dual purposes. It indicates the character encoding of the > JSP file to the Java compiler (i.e. playing the same role as '-encoding' > option when invoking 'javac') and it also indicates in what character > encoding the generated html file should be served to the outside world. > Someone might argue that there need to be two separate 'directives' for > two roles, but I guess it's all right to overload pageEncoding directive. > Not quite: there are two directives: pageEncoding and contentType and they can indicate *different* encodings. If you use pageEncoding on its own, it is assumed that the encoding of the source JSP file should be the encoding used to deliver the file. If you use contentType on its own, then the page is delivered in the encoding specified, but read as Latin-1. If you want to use one encoding (say KS-X-1001) for the JSP file and a different encoding for the delivery (say UTF-8) then you can use both directives together. For example, see Norbert Lindeberg's excellent article here: http://developer.java.sun.com/developer/technicalArticles/Intl/MultilingualJ SP/ In addition, the pageEncoding is how the JSP container reads the .jsp file in, but the resulting servlet may not be written in the specified encoding (e.g. the javac invocation might not use an -encoding directive). One more note: if your JSP page reads data from a HttpServletRequest object, you may have to call the setCharacterEncoding() method on that object before retrieving parameters sent to your JSP page via GET or POST. Best Regards, Addison
Received on Sunday, 30 November 2003 22:14:34 UTC