Hi Ivan Thank you very much for making things very clear here.
It seems the whole issue cryes for a unification of the whole django source before the 1.0 release, or do I misinterpret? Do you know which parts of django still use bytecode strings? greets Philipp On Sat, Jan 27, 2007 at 06:10:48PM +0300, Ivan Sagalaev wrote: > > Michael Radziej wrote: > > 1. Are all these tickets really about the connection encoding? > > > > 2. If so, what's the problem of using utf8 for the connection for > > everybody? I don't see how this would be a problem for anybody who is > > using a different encoding for templates, within the database's storage > > or else, since there's no loss in converting anything into utf8. Or is > > there? > > I agree with the 2nd point. You still can run into a theoretical problem > with it in a scenario when an input is richer than a storage: > > - a database that is internally stores data in a legacy encoding (say > iso-8859-1) > - a web frontend that talks utf-8 > - a user enters, say, Russian characters into a form > - data travels as utf-8 right until db where it will fail to encode them > in iso-8859-1 because it doesn't have place for Russian characters > > But it's indeed a very theoretical case. Most legacy system use the same > legacy encoding for both backend and frontend and there would be no > errors in the path: legacy (web) - unicode (newforms) - utf-8 (db > connection) - legacy (db) > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
