Во-первых, я сейчас использую только Python 3.1; его главная заслуга состоит в том, чтобы иметь неоднозначные байтовые строки из объектов Unicode. это делает подавляющее большинство текстовых манипуляций намного безопаснее, чем раньше. Принимая во внимание триллионы пользовательских вопросов, касающихся проблем кодирования в Python 2.x, соглашение u'äbc в Python 2.1 было просто ошибкой; с явными bytes и bytearray жизнь становится намного проще.
во-вторых, если py3k вам не по вкусу, попробуйте использовать from __future__ import unicode_literals, так как это будет имитировать поведение py3k на python 2.6 и 2.7. эта вещь позволила бы избежать (легко совершаемой) ошибки, которую вы совершили, когда говорили print 'exámple'.upper(). по сути, это то же самое, что и в py3k: print( 'exámple'.encode( 'utf-8' ).upper() ). сравните эти версии (для py3k):
print( 'exámple'.encode( 'utf-8' ).upper() )
print( 'exámple'.encode( 'utf-8' ).upper().decode( 'utf-8' ) )
print( 'exámple'.upper() )
Первый, в основном, то, что вы сделали, когда использовали пустую строку 'exámple', при условии, что вы установили кодировку по умолчанию на utf-8 (согласно заявлению BDFL, установка кодировки по умолчанию во время выполнения - плохая идея так что в py2 вам придется обмануть его, сказав import sys; reload( sys ); sys.setdefaultencoding( 'utf-8' ); я представляю лучшее решение для py3k ниже). когда вы смотрите на вывод этих трех строк:
b'EX\xc3\xa1MPLE'
EXáMPLE
EXÁMPLE
вы можете видеть, что когда upper() применяется к первому тексту, он действует на байты, а не на символы. Python допускает метод upper() для байтов, но он определяется только для интерпретации байтов в соответствии с US-ASCII. поскольку utf-8 использует значения в пределах 8 битов, но вне US-ASCII (от 128 до 255, которые не используются US-ASCII), на них не повлияет upper(), поэтому, когда мы декодируем обратно во второй строке, мы получаем строчную букву á. наконец, третья строка делает все правильно, и да, удивительно, python, похоже, знает, что Á - это заглавная буква, соответствующая á. я провел быстрый тест, чтобы увидеть, какие символы Python 3 не конвертирует между прописными и строчными буквами:
for cid in range( 3000 ):
my_chr = chr( cid )
if my_chr == my_chr.upper() and my_chr == my_chr.lower():
say( my_chr )
при просмотре списка обнаруживается очень мало случаев, когда встречаются латинские, кириллические или греческие буквы; большая часть вывода - не европейские символы и знаки препинания. единственные символы, которые я мог найти, что Python ошибся, это Ԥ / ԥ (\ u0524, \ u0525, 'кириллица {заглавная | маленькая} буква pe с опусканием'), так что пока вы остаетесь вне блоков Latin Extended-X ( проверьте их, они могут принести сюрпризы), вы могли бы на самом деле использовать этот метод. конечно, я не проверял правильность отображений.
наконец, вот что я поместил в мой раздел загрузки приложения py3k: метод, который переопределяет кодировку, которую sys.stdout видит, с числовыми ссылками на символы (NCR) как запасной вариант; это приводит к тому, что печать на стандартный вывод никогда не вызовет ошибку кодирования Unicode. когда я работаю в Ubuntu, _sys.stdout.encoding - это utf-8; когда одна и та же программа запускается в Windows, это может быть что-то странное, например cp850. вывод может выглядеть странным, но приложение запускается без исключения на этих тупых терминалах.
#===========================================================================================================
# MAKE STDOUT BEHAVE IN A FAILSAFE MANNER
#-----------------------------------------------------------------------------------------------------------
def _harden_stdout():
"""Ensure that unprintable output to STDOUT does not cause encoding errors; use XML character references
so any kind of output gets a chance to render in a decipherable way."""
global _sys_TRM
_sys.stdout = _sys_TRM = _sys_io.TextIOWrapper(
_sys.stdout.buffer,
encoding = _sys.stdout.encoding,
errors = 'xmlcharrefreplace',
line_buffering = true )
#...........................................................................................................
_harden_stdout()
еще один совет: при тестировании всегда старайтесь print repr( x ) или аналогичную вещь, которая раскрывает личность x. всевозможные недоразумения могут возникнуть, если вы просто print x в py2 и x либо октетная строка, либо объект Unicode. это очень озадачивает и склонно вызывать много царапин на голове. Как я уже сказал, попробуйте перейти хотя бы к py26 с этим из будущего импортного заклинания литералов Unicode.
и в заключение, цитируя цитату: «Глиф Лефковиц лучше всего говорит в своей статье Кодировка :
Я считаю, что в контексте этого
обсуждение, термин "строка"
бессмысленны. Есть текст, а там
это байтовые данные (которые могут очень
хорошо представлять текст, но пока нет
переоборудован в него). В типах Python,
Текст в кодировке Юникод. Данные ул. Идея
"не-Unicode текст" это просто
ошибка программирования в ожидании. "
обновление: только что найденный python 3 правильно преобразует AT LATIN SMALL LETTER LONG S в S при вводе заглавных букв. аккуратный!