The UTF-8 assumption is in place in two (I think) places in Yesod:

* The ToContent instances for String, Html, Text... all use UTF-8 encoding. You'll most likely want to stick to the lazy ByteString instance of ToContent to ensure you can specify your encoding. (Similarly, the typeHtml, typePlain... values all include a utf-8 charset identifier.)

* The default query string parsing will assume UTF-8 encoding. I can make that configurable in the future if there's demand (which it sounds like there is).

Additionally, path parsing assumes UTF-8. However, my understanding and experience both say that- while this is not clearly defined in the HTTP spec- it is what all web browsers assume. However, the query string encoding *is* dependent on the character encoding of the page.

But I'm curious: is it really a necessity to use shift_jis for these providers? They really don't support UTF-8? I would be very surprised if there's any significant bandwidth savings, since (1) so much of the page will be ASCII characters for the markup and (2) GZIP compression would hopefully mitigate other issues.

Michael

On Tue, Apr 19, 2011 at 7:52 AM, Katsutoshi Itoh <cutsea110@gmail.com> wrote:

Hi

I think trying to support a mobile phone.
There are three mobile phone carrier, in Japan.
To accommodate all carriers instead of UTF-8 CP932(known as Shift_JIS)
in the code word you need to interact with the Web UI.
Please tell me what do I like?

- How to specify charset
- String embedded in a page how to generate CP932 (UTF-8 instead)
- How to decode the parameters posted

thank you.

_______________________________________________
web-devel mailing list
web-devel@haskell.org
http://www.haskell.org/mailman/listinfo/web-devel