Re: UnicodeString encoding

Ian Bicking <[email protected]> Thu, 12 Mar 2009 11:22:28 -0500
Newsgroups gmane.comp.python.formencode
Message-ID <[email protected]>
On Thu, Mar 12, 2009 at 8:05 AM, Christoph Zwerschke <[email protected]> wrote:
> FormEncode assumes 'utf-8' encoding for the UnicodeString validator.
> This is usually ok, and you can even overwrite this using the
> inputEncoding and outputEncoding settings. However, what you can *not*
> do is have *no* input or output encoding at all, i.e. you can't use
> Unicode in the "outside world", too. But this is necessary, for
> instance, if you're using FormEncode with ToscaWidgets forms, because
> most templating languages expect Unicode objects instead of encoded
> strings. That's why ToscaWidgets comes with its own modified
> UnicodeString validator. It would be nice to have this feature in
> FormEncode already.
>
> My suggestion is to allow setting inputEncoding and outputEncoding to
> None. Currently, this will use the default encoding utf-8. I suggest not
> decoding/encoding at all in this case, i.e. using unicode. If you don't
> excplicity specify any inputEncoding or outputEncoding then, the default
> utf-8 encoding will be used as before. I have already created a patch
> for this feature. Can I check this in to the trunk?

Changing the default behavior could mess up working code.  I think it
would make sense to treat an encoding of None as do-not-encode (or
decode).  A subclass of UnicodeString could have that value
(outputEncoding) default to None.

-- 
Ian Bicking  |  http://blog.ianbicking.org

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com