cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] Requirement for Servlet in extra-classpath solution
Date Mon, 12 Mar 2001 13:38:07 GMT
Really, I was thinking something simple.  Not a full blown compatibility
layer with CharSet conversion and stuff.  I don't have the time for something
like that.

Tagunov Anthony wrote:
> 
> Evrybody wants to catch his own rat!
> If such a thing would find its way into existence, then
> we could have one of the encodings problems solved!
> 
> The problem is that at least with some servlet engines
> (including Tomcat 3.1.x) there is the following trouble:
> (i've already described it on the list, but now it look a
> good time to re-describe ;)
>   if we have HTML page in an ecoding other then 8859_1
>  (say, UTF-8, for example, but the following appllies to
>   Cyrillic encodings too)
>  and have an input form in this page. Let there be a text
>   input element on it, say with the name "foo".
>  Imagine you type something non-latin there.
>  Then the browser (both IE and NS of versions that
>   support UTF-8) takes the imputed non-latin test,
>   conversts to the bynary representation of the text
>   in UTF-8 (non-latin chars take two bytes), %-s every
>   byte and sends it to the server like ..?foo=%DA%13
>   (the codes to not correspond to anything, just from my
>   head).
> 
>   To get back the nice UTF-8 chars one has too
>    new String(request.getParameter("foo").getBytes("8859_1"),"UTF-8")
> 
> In particular this happens on WAP phones (at least in our tests
> Ericcson R320 phone transmitted cyrillic chars exactly in this way.)
> 
>   - o -
> Does anybody know, has there been any progress with this in Servlet 2.3 spec?
>   - o -
> The trouble is that the Servlet Engine can not automatically determine the
> encoding of the request parameters: the browsers do not send it in the
> request :-(
> 
> So the only way to get values right is to _know _what_ _was_ _the_ _encoding_
> _of_ _the_ _page_  and reconstruct the request parameters  in the fashion
> described above.
> 
> Bad but better then nothing this can be handled in the intermediate layer between
> the application (xsp pages, xslt transformations having access to http request
> parameters, custom actions, matchers, selectors, custon generators and processors)
> and the servlet-engine-provided request class proposed above.
> 
> (Maybe
>  --somewhere in the sitemap
>  --in some action
>  --??
> where the encoding of the page is know, the correct value could be fed into this
> intermidiate layer..
> 
> To avoid confusion, it could have two methods for retriving request parameters:
> one would return directly request.getParameter() and the other would throw
> exception if invoked and the encoding was not set yet. After it has been set
> it would return the recoded value. Setting the encoding twice will be disallowed...
>    - o -
> 
> BAD. VERY BAD. This thing should be handled in the servlet api. If it isn't
> it still looks VERY AWKWARD to handle this in the intermidiate layer between
> servlet api and our apps..
> 
> But is there a better solution? What we have now:
> either new String.. and the stuff code near all parameter retrival? Without
> concentrating the information of what encoding should be used in one place
> but letting it float all over the code? Each developer individually develping
> a method recode(String val, String encoding) somewhere in his personall
> utilities? To me it's even worse..
> 
>   - o -
> 
> I heard there's some good NLS support in Jetspeed. Would be VERY intrigued
> to know if they have a way of solving the trounble. That's why posting to both
> lists.
> 
> Best regards, Tagunov Anthony
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message