> On the other hand, most people may not realize this option even exists, 
> and create unnecessarily bloated Ajax traffic. The idea of TG is to 
> provide good components and good default config settings, and I think 
> ensure_ascii=False is the better option. Nobody would send web pages 
> with character entities for all non-ascii chars. So why should we do 
> something like this for json pages? Plus, the danger of choosing a wrong 
> decoding by the browser is not even given here, since it is clear that 
> Json implicitly means utf-8 anyway (or may be utf-16/utf-32, but the 
> browser can recognize these differences from the content only, without 
> the need for a separate encoding specification).
> 
> For the German alphabet, it does not matter much, we only have a few 
> non-ascii umlauts. But for other languages like Russian it makes a big 
> difference. The Ajax traffix would become 3-4 times larger.
> 
> See also
> http://pylab.blogspot.com/2007/01/how-to-ensureasciifalse-when-using-json.html

I'm not deep enough into JSON protocol layer details - if you say it's 
always one of the UTF-encoding familiy, I'm all ok with that. But I 
wonder *why* is ensure_ascii there then anyway?

Diez

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" 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/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to