<br><br><div><span class="gmail_quote">On 9/5/06, <b class="gmail_sendername">David Hopwood</b> <<a href="mailto:david.nospam.hopwood@blueyonder.co.uk">david.nospam.hopwood@blueyonder.co.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Guido van Rossum wrote:<br>> On 9/5/06, Brian Quinlan <<a href="mailto:brian@sweetapp.com">brian@sweetapp.com</a>> wrote:<br>> [...]<br>><br>> That would not be doing what the user wants. We have extensive
<br>> experience with defaulting to ASCII in Python 2.x and it's mostly bad.<br>> There should definitely be a way to force ASCII as the default<br>> encoding (if only as a debugging aid), both in the program code and in
<br>> the environment; but it shouldn't be the only default. There should<br>> also be a way to force UTF-8 as the default, or ISO-8859-1. But if<br>> CP436 is the default encoding set by the OS I don't see why Python
<br>> shouldn't use that as the default *in the absence of any other<br>> preferences*.<br><br>Cp436 is almost certainly *not* the encoding set by the OS; Python<br>has got it wrong. If Brian is using an English-language variant of
<br>Windows XP and has not changed the defaults, the system ("ANSI")<br>encoding will be Cp1252-with-Euro (which is similar enough to ISO-8859-1<br>if C1 control characters are not used).</blockquote><div><br>
<a href="http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbdaen9/00000376.htm">http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbdaen9/00000376.htm</a><br>
<br>
"There are at least two code pages in use on
most PCs. Applications using the Windows graphical user interface use
the Windows code pages. These code pages are compatible with ISO
character sets, and also with ANSI character sets. They are often
referred to as <strong>ANSI code pages</strong>.
<p> Character-mode applications (those using the console or command
prompt window) in Windows 95/98/Me and Windows NT/200/XP, use code
pages that were used in DOS. These are called <strong>OEM code pages</strong> (Original Equipment Manufacturer) for historical reasons.</p>
<p>...<br>
</p>
<h6><a class="name" name="natlang-bridgehead-4154540">Example</a> </h6>
<p>Consider the following situation:</p>
<ul>
<li><p class="list">A PC is running a Windows operating system with ANSI code page 1252.</p>
</li><li><p class="list">The code page for character-mode applications is OEM code page 437.</p>
</li><li><p class="list">Text is held in a database created using the collation UTF8.</p>
</li>
</ul>
<p>An upper case A grave in the database is stored as hex byes C380. In
a Windows application, the same character is represented as hex CO. In
a DOS application, it is represented as hex B7."<br>
</p>
<p>Now notice that when we introduce Unicode (and all Python 3K strings
are Unicode), we aren't talking about DISPLAY of characters. We're
talking about INTERPRETATION of characters. So if I read a file and
then merge it with some XML data then a Windows default encoding-using
application will create different output in a Python script run from
the command line versus run from the Windows desktop. Same app. Same
data. Different default encodings. Different output.<br>
</p>
<p>Of course we could arbitrarily choose one of these two encodings as
the "true" one, but the fact that they are ALMOST ALWAYS inconsistent
indicates something about how likely either one is to be correct for a
particular user's goals.<br>
</p>
<p> Paul Prescod<br>
<br>
</p>
</div></div>