On Tue, 18 Apr 2000 11:47:43 -0700, Jason Hunter wrote:
> The "whole problem" is that the client doesn't tell what charset they
> send the data in. Having the ability to tell the server what charset
> the client is using doesn't solve the problem of figuring out that piece
> of information. But it's better than nothing.
That's currect. The sad thing is that this "nothing" is rather annoying
right now. It's costly. Personally, I grew to not pay attention to it
anymore, because I have my own solution for some time already. But people
keep complaining -- there's a lot of new people joining the Java technology
these days, and you keep telling -- "yes, guys, read the FAQ, the JSDK is
inaccurate, here's the solution".
> It's not a real big help though because people have always been able
> to use the techniques from my Chapter 12 to massage the data into the
> right charset. This new method doesn't provide any new capabilities, it
> just makes it a little easier.
Isn't that important? Why should you massage the data yourself every time,
if it could be massaged for you properly? :)
After all, it more looks like fixing an inconsistency, rather than adding
something new. Who knows, maybe tomorrow we will have a server which will
take care of the encoding, and let us forget about the problem forever. To
be fair, nobody prevents us from doing that right now, all we need is just
to make it use our own parsers instead of API-supplied ones. But it more
likely going to happen with the proper API in place.
Sincerely,
Dmitry.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
