Least-lossy string.encode to us-ascii?

[Steven D'Aprano]

On Thu, 13 Sep 2012 21:34:52 -0500, Tim Chase wrote:

> On 09/13/12 21:09, Mark Tolonen wrote:
>> On Thursday, September 13, 2012 4:53:13 PM UTC-7, Tim Chase wrote:
>>> Vlastimil's solution kept the characters but stripped them of their
>>> accents/tildes/cedillas/etc, doing just what I wanted, all using the
>>> stdlib.  Hard to do better than that :-)
>> 
>> How about using UTF-7 for transmission and decode on the other end? 
>> This keeps the transmission all 7-bit, and no loss.
>> 
>>     >>> s=u"serviço móvil".encode('utf-7')
>>     >>> print s
>>     servi+AOc-o m+APM-vil
>>     >>> print s.decode('utf-7')
>>     serviço móvil
> 
> Nice if I control both ends of the pipe.  Unfortunately, I only control
> what goes in, and I want it to be as un-screw-uppable as possible when
> it comes out the other end (may be web, CSV files, PDFs, FTP'ed file
> dumps, spreadsheets, word-processing documents, etc), and us-ascii is
> the lowest-common-denominator of unscrewuppableness while requiring
> nothing of the the other end. :-)

Wrong. It requires support for US-ASCII. What if the other end is an IBM 
mainframe using EBCDIC?

Frankly, I am appalled that you are intentionally perpetuating the 
ignorance of US-ASCII-only applications, not because you have no choice 
about inter-operating with some ancient, brain-dead application, but 
because you artificially choose to follow an obsolete *and incorrect* 
standard.

It is *incorrect* because you can change the meaning of text by stripping 
accents and deleting characters. Consequences can include murder and suicide:

http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail

At least tell me that "ASCII only" is merely an *option* for your 
application, not the only choice, and that it defaults to UTF-8 which is 
the right standard to use for text.



-- 
Steven