Cindy: > The <fmt:requestEncoding value="UTF-8" /> tag performs the same function as > the following: > > <%@ page contentType="text/html;charSet=UTF-8" %> > > right?
No. ;-) Even when you specify your page's charset via the 'contentType' attribute of a page directive, your page's locale (and thus character encoding) may differ from the value you specified if your page uses a <locale> action or has enabled browser-sensing capabilities for locales, in which case the i18n action's tag handler implementation calls ServletResponse.setLocale() (which also sets the response's charset) with the specified or best-matching locale, respectively. This assumes that the container calls ServletResponse.setContentType() (with the value of the page directive's contentType attribute, if present) at the BEGINNING of the page, and that any subsequent call to ServletResponse.setLocale() (by an i18n action in the page) overrides the page's existing encoding, so that the locale (and encoding) set by the last i18n action wins. (This assumes that the response is buffered with a big enough buffer size, since setLocale() and setContentType() must be called before ServletResponse.getWriter() in order for the charset to affect the construction of the writer.) > So, was this tag added to clean it up a little and make it less confusing to > the page designer? The purpose of the <requestEncoding> action is to set the request charset to the same as the response charset in a page invoked by a form included in the response . This makes it possible for the container to decode the form parameter values properly, since browsers typically encode form field values using the response's charset. Jan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
