Ticket #2197 (new defect)

Opened 9 years ago

Last modified 8 years ago

Stop hardcoding utf-8 in templates

Reported by: gracinet Owned by: gracinet
Priority: P3 Milestone: CPS 3.6.1
Component: CPS (global) Version: 3.5.1rc2
Severity: critical Keywords: unicode utf8
Cc:

Description

This dates back to the branch that's been used as a base for the unicode migration: We have these all over the place in ZPTs:

  <input name="the_input:utf8:ustring">

The 'utf8' should be replaced dynamically by the value specified for zpublisher-encoding in zope.conf. We need to

  • find a standard way of doing this in a non-intrusive manner
  • start applying it carefully

Once that is done, CPS becomes transparent as far as the HTML encoding is concerned, and users can go, e.g, to utf-7 or whatever suits them, provided it is convertible in both ways to unicode.

Change History

comment:1 Changed 9 years ago by gracinet

A proof-of-concept of how to patch ZPublisher so that it applies its default-encoding to inputs like the_inputs:utstring has just been pushed in the implicit_encoding branch of CPSCompat. Since there is a zpublisher-default-encoding section in zope.conf, this does not imho break the rule of "no encode/decode shall be performed from a guess".

It seems to me far better than the Zope's code that's in effect equivalent to : "apply ascii if you don't know".

This is on a branch, because it might be considered risky, but with this patch, blind replacement of utf8:ustring to ustring (and friends) seems possible.

comment:2 Changed 9 years ago by gracinet

I'd like to bring the issue to the attention of Zope developpers, but it'll probably hard to change that so late in the dev cycle of Zope 2.9. Also, it'll be worth taking a look at the behaviour of latest Zope 2 versions in that respect.

comment:3 Changed 8 years ago by gracinet

  • Milestone changed from CPS 3.5.3 to CPS 3.6

We'll see about that after climbing up Zope versions

Note: See TracTickets for help on using tickets.