Charlie Clark wrote at 2008-12-14 12:32 +0100:
>Am 13.12.2008 um 18:40 schrieb Charlie Clark:
>> I'm struggling with the way formlib forms handle decoding from forms.
>> It looks like this gets set in BrowserView using an
>> IUserPreferredCharsets adapter. The default adapter seems to be in
>> zope.publisher.http and it looks like latin-1 will be set if there is
>> no other charset and I'm having problems with the em-dash and en-dash
>> (u'\u2013' and u'\u2013') characters automatically being converted
>> from latin-1 when they are being entered as cp1252. For content that
>> doesn't through this decoding I have no problems if zpublisher-
>> encoding is set to cp1252 and the default_charset is set to cp1252 as
>> well: decoding with CMFDefault.utils.decode() works just fine.
>> I suspect I'm missing something basic in the way charsets are handled
>> but as it's a windows only IE6 environment, is the easiest solution
>> writing an adapter that defaults to cp1252 if there is no
>> HTTP_ACCEPT_CHARSET in the request header?
>Overriding the adapter works fine. I'm still a bit confused by the
It is usually insane to use client preferences to guess the encoding
used in form data.
Usually, the client will use the charset it has found in the
page containing the form. Thus, unless this charset has been
determined automatically from the "Accept-Charset" header,
it is merely accidental when the client preferences ("Accept-Charset")
is able to guess the charset correctly.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests