Почему внутренний формат Python Unicode был реализован так, как описано в PEP 100?

http://www.python.org/dev/peps/pep-0100/

В PEP 100 указано, что внутренний формат Python Unicode содержит кодировку UTF-16, но адресует значения как UCS-2 (или UCS-4 при компиляции с флагом --enable-unicode=ucs4).

Почему не был выбран UTF-16 (формат переменной длины), а не UCS-2 (фиксированная длина)?

Хотя эти две кодировки в основном одинаковы, UTF-16 было уже 4 года, когда был опубликован PEP-100 (март 2000 г.). Был ли Python Unicode предназначен для решения проблем обратной совместимости?

Мне действительно просто любопытно, почему внутренний формат Python был реализован с использованием этого (казалось бы) гибридного подхода для внутреннего хранения закодированных данных?

Лучший способ задать мой вопрос может быть следующим: есть ли у кого-нибудь цитата или ссылка с цитатой из официального документа, в котором конкретно указано, почему PEP 100 решил рассматривать UTF-16 как UCS-2 вместо использования UTF-16?


python encoding unicode utf-16 ucs2
person mkelley33    schedule 05.11.2011    source источник
comment
А еще лучше, почему бы не использовать UTF-8 или UTF-32?   -  person Keith Thompson    schedule 06.11.2011
comment
Я бы тоже хотел увидеть UTF-8, но я предполагаю, что UTF-8, вероятно, был слишком передовым в то время, после RFC 2279, ietf.org/rfc/rfc2279.txt не публиковался до января 1998 года. Я мало что знаю о UTF-32, но подозреваю, 't выбрал сделать для проблем с хранением. Хороший комментарий :)   -  person mkelley33    schedule 06.11.2011
comment
Примечание. Работа с символьными терминами с длиной, индексированием и нарезкой намного сложнее и неэффективнее в UTF-8, чем в UTF-16. Использование UTF-8 в качестве внутреннего формата (в отличие от внешнего формата) не является хорошей идеей.   -  person John Machin    schedule 06.11.2011
comment
@eryksun Нет. Я спрашиваю, почему UCS-2 был выбран вместо UTF-16. Хотя мне было бы любопытно узнать больше о том, почему это не было написано для правильной передачи суррогатных пар UTF-16.   -  person mkelley33    schedule 06.11.2011
comment
@JohnMachin Почему utf-8 работает в символьном выражении с длиной, индексом и нарезкой намного сложнее и неэффективнее с UTF-8?   -  person mkelley33    schedule 06.11.2011
comment
@ mkelley33: Потому что, начиная с известной точки, часто с начала, вам нужно пройти через строку байтов, на каждой итерации выполняя next_byte_pos = current_byte_pos + length_table[bytestring[current_byte_pos]]   -  person John Machin    schedule 06.11.2011
comment
UTF-16 имеет все недостатки как UTF-8, так и UTF-32 вместе взятых, но не обладает ни одним из преимуществ ни одного из них. Это ублюдок кодировки, и это красиво сказано.   -  person tchrist    schedule 06.11.2011
comment
@John: И как, по-вашему, вы проходите через UTF-16? Вы не можете сделать это кодовой единицей за раз, так же как и с UTF-8.   -  person tchrist    schedule 06.11.2011
comment
@Кит: Отличный вопрос. Вы заметите, что языки, выбравшие UTF-8, имеют гораздо лучшую поддержку Unicode по сравнению с Python: Perl еще в 2000 году и Go гораздо позже. UCS-2 был действительно плохим ходом, и это необходимо даже для того, чтобы начать играть в догонялки.   -  person tchrist    schedule 06.11.2011

Ответы (1)


arrow_upward
1
arrow_downward

Прочитайте немного дальше: «UCS-2 и UTF-16 одинаковы для всех определенных в настоящее время точек символов Unicode»… и это было верно в 2000 году, когда был написан PEP. Первоначальная реализация охватывала только BMP (первые кодовые точки 64K).

person John Machin    schedule 05.11.2011
comment
Я прочитал это и понял, что они были по существу одинаковыми в том, что касается кодовых точек, но зачем выбирать более старую UCS-2 вместо более новой UTF-16, если они обе были одинаковыми для всех кодовых точек на момент написания? В чем преимущество формата фиксированной длины перед форматом переменной длины? - person mkelley33; 06.11.2011
comment
фиксированную ширину просто легче обрабатывать. Кроме того, Unicode был и остается движущейся мишенью. Имеет смысл принять функции Unicode, которые существуют уже несколько лет. - person ObscureRobot; 06.11.2011
comment
@mkelley: Это было проще. Никаких суррогатов, о которых можно было бы беспокоиться. - person John Machin; 06.11.2011
comment
@ObscureRobot: предполагают, что причина заключалась в том, что фиксированную ширину просто легче обрабатывать, или у вас есть цитата, на которую я мог бы сослаться? Я не согласен с вами, и я ценю ваш комментарий, но я хотел бы знать, существует ли где-нибудь документ или официальное объяснение, подтверждающее ваш комментарий. Благодарю вас! - person mkelley33; 06.11.2011
comment
@JohnMachin Я очень ценю, что вы нашли время, чтобы объяснить так много в ответе и комментариях. Есть ли шанс, что вы захотите включить цитату в свой пример? Я полагаю, что ваш ответ правильный, но было бы приятно узнать, что «какой-то программист», работающий над Python Unicode, сказал: «Мы знали, что не стоит пытаться справиться со сложностями суррогатов в то время, когда PEP 100 был была написана, и поэтому мы выбрали UCS-2 с фиксированной шириной, которая использовалась в течение нескольких ( › 4 лет) во всей отрасли. --‹какой-то коммитер-или-человек, работающий-на-PythonUnicod›, ‹дата› - person mkelley33; 06.11.2011
comment
@Джон: Это неправда. Суррогатный механизм был изобретен в 1996 году для Unicode 2.0, поэтому к 2000 году его уже хорошо понимали. На тот момент действительно не было оправдания для выбора тупиковой внутренней репрезентации. Ни UTF-8, ни UTF-32 даже не имеют суррогатов, и даже с UTF-16 вы можете учитывать их, если будете осторожны. Вместо этого они совершили двойную ошибку, выбрав тупиковую кодировку и открыв миру внутреннее представление. Второй так же глуп, как Java, но первый еще хуже. - person tchrist; 06.11.2011
comment
@tchrist Мое намерение здесь заключалось не в том, чтобы обсуждать или критиковать достоинства реализации. Я согласен с вашими первыми двумя предложениями, а также с другими вашими утверждениями о суррогатах, но ваша атака на Java и Python не дает ничего полезного для ответа на мой вопрос. Негатив в ваших комментариях также подрывает доверие к тому, что вы сказали, что на самом деле может быть правдой. Очень жаль. - person mkelley33; 06.11.2011
comment
@ mkelley33: Если вы ищете цитату, я предлагаю вам порыться в архивах списка рассылки python-dev. - person John Machin; 06.11.2011
comment
@mkelley33: Я только что провел почти два года, имея дело с сотнями тысяч строк неработающего кода Java и десятками тысяч строк неработающего кода Python, которые все сломаны одинаково: они думают, что Unicode означает UCS-2. Это означает, что они не могут правильно обрабатывать текстовые корпуса, для которых они были написаны. Например, массивная коллекция открытого доступа PubMed находится в формате XML, поэтому, конечно, кодовые точки не ограничиваются BMP. Весь этот код ломается в этом корпусе и во многих других. Поскольку вы не можете гарантировать широкую сборку, мы используем Perl для нового кода, а не Python. Java — гораздо большая проблема. - person tchrist; 06.11.2011
comment
@JohnMachin спасибо за совет. Я посмотрю и посмотрю, смогу ли я вернуть какую-либо полезную информацию, чтобы добавить сюда. - person mkelley33; 06.11.2011
comment
@tchrist: возможно, обжегся плохой кодировщик (и), который неправильно использовал Python и / или Java для работы с XML. И Python, и Java могут обрабатывать и обрабатывают весь диапазон кодовых точек за пределами BMP. Многие системы Linux поставляются с подготовленным для этого Python. Я скомпилировал Python для Mac OS X, чтобы иметь дело с кодовыми точками вне BMP. Пожалуйста, хватит троллить. - person mkelley33; 06.11.2011
comment
@mkelley33: Да, я знаю, что могут, если ты будешь осторожен. У меня широкое телосложение. Проблема в том, что люди, которые писали код, не понимали, что Unicode — это не UCS-2, а потому волшебной палочкой это не исправить. Вы должны переписать их код. Это очень расстраивает. - person tchrist; 06.11.2011