+1 on this one.
-Filip
On 2008-07-29 16:39, Howard Lewis Ship wrote:
Well, it's not like we're pushing a bytestream from the web browser to
the database, or vice-versa. Everything is being read into memory as
UTF, whether it starts as UTF-8 in the browser, or ISO-8859-1 in the
database. As its read from one source or written to another, the
character set is going to change.
My observation is that the current design; allowing every page to have
its own charset, is beginning to feel like overkill, especially given
that the solution has a number of frayed edges.
On Tue, Jul 29, 2008 at 2:28 AM, Massimo Lusetti <[EMAIL PROTECTED]> wrote:
On Tue, Jul 29, 2008 at 2:17 AM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
Here's a question. I'm still struggling with getting Tapestry to do
the right encoding when producing output, and to set the response
encoding to the correct value before reading query parameters.
There's lots of edge cases, related to Ajax, to form uploads, and to
complex components, such as BeanEditForm, where content may be
gathered from multiple pages.
What if there was just a single default application character set,
which would default to UTF-8? This is pretty much what people are
doing with the UTF-8 RequestHandler filter.
This would simplify a bunch of stuff, since output encoding would
always be the same, as would request encoding. We could get rid of
the some of the meta-data as well.
Is UTF-8 sufficiently well supported by browsers? Is this an option
that works for Big5 Chinese and other non-Western language locales?
Howard, how this would fit with existing DB and/or other data sources
(files for example) already encoded as ISO-8859-1 ?
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
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]
