On 03/01/2010 02:28 PM, Martin Aspeli wrote:
> I'm with Wichert here.
> In most places, we tend to carry around unicode strings internally, and
> only encode on the boundaries, e.g. when the URL is "rendered". I don't
> see why redirect() can't have a sensible and predictable policy for
> unicode strings, making life easier for everyone.
> If we think that non-ASCII URLs are illegal, then maybe we should
> validate for that and throw an error. However, I don't think that's the
> case (anymore?). In that case, passing a unicode object to the function
> seems entirely consistent with other places, e.g. when we pass unicode
> to the page template engine or return unicode from a view, which the
> publisher then encodes before it's pushed down to the client.
I opened a question in another part of the thread, but haven't gotten an
answer yet. In my understanding, a Unicode string is not able to
represent the structural properties of a URL in http scheme properly,
thus encoding back to ASCII is not possible.
Can someone confirm or disprove this?
Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -