Следует ли считать устаревшими кодировки символов помимо UTF-8 (и, возможно, UTF-16 / UTF-32)?

Моя любимая мозоль смотрит на очень много программных проектов, которые имеют горы кода для поддержки набора символов. Не поймите меня неправильно, я за совместимость, и я рад, что текстовые редакторы позволяют открывать и сохранять файлы в нескольких наборах символов. Что меня раздражает, так это то, что распространение неуниверсальных кодировок символов называется «надлежащей поддержкой Юникода», а не «проблемой».

Например, позвольте мне выбрать PostgreSQL и его поддержку набора символов . PostgreSQL работает с двумя типами кодировок:

• Кодировка клиента: используется для связи между клиентом и сервером.
• Кодировка сервера: используется для внутреннего хранения текста в базе данных.

Я могу понять, почему поддержка большого количества клиентских кодировок - это хорошо. Это позволяет клиентам, которые не работают в UTF-8, обмениваться данными с PostgreSQL без необходимости выполнять преобразование. Чего я не понимаю: почему PostgreSQL поддерживает несколько серверных кодировок? Файлы базы данных (почти всегда) несовместимы от одной версии PostgreSQL к другой, поэтому совместимость с разными версиями здесь не проблема.

UTF-8 - это единственный стандартный ASCII-совместимый набор символов, который может кодировать все кодовые точки Unicode (если я ошибаюсь, дайте мне знать). Я нахожусь в лагере, что UTF-8 - лучший набор символов, но я готов мириться с другими универсальными наборами символов, такими как UTF-16 и UTF-32.

Я считаю, что все неуниверсальные наборы символов должны быть устаревшими. Есть ли веская причина, по которой они не должны?

Поскольку вы упомянули PostgreSQL, я могу с некоторой степенью достоверности сказать, что основная причина, по которой кодировки, не относящиеся к UTF8, поддерживаются на таких деталях, заключается в том, что это нужно японцам. По-видимому, идентичное преобразование в обоих направлениях между Unicode и различными японскими «устаревшими» кодировками не всегда возможно, а в некоторых случаях таблицы преобразования даже различаются у разных поставщиков. Это действительно сбивает с толку, но это, очевидно, так. (Широкая поддержка набора символов также является одной из причин, почему PostgreSQL так популярен в Японии.)

Поскольку мы говорим о системе баз данных, одной из основных задач является возможность надежного хранения и извлечения данных, как это определено пользователем, поэтому преобразование набора символов с потерями иногда не сработает. Если вы имели дело с веб-браузером, скажем, где все, что действительно имеет значение, это то, выглядит ли результат нормально, тогда вы, вероятно, можете избежать поддержки меньшего количества кодировок, но в системе баз данных у вас есть дополнительные требования.

Некоторые из других причин, упомянутых в других ответах, также применяются в качестве вспомогательных аргументов. Но пока японцы наложили вето, поддержка настройки персонажа не может быть уменьшена.

Две очевидные причины: в зависимости от данных, которые вы храните, преобразование в другой формат может занять довольно много времени и дополнительного места. Если вы храните 400 мегабайт информации, удвоение требований к хранилищу не составляет большого труда - но если вы храните 400 терабайт, это начинает означать немного больше. Преобразование 400 терабайт данных из (скажем) Shift-JIS в UTF-x также может занять некоторое время.

Это становится особенно трудным, если у вас есть (например) гарантии безотказной работы, которые говорят, что база данных будет доступна для всех, но, скажем, 10 минут из любого данного года, и у вас есть база данных, которая обновляется несколько сотен раз в секунду. Имейте в виду, что в такой ситуации все еще возможно управлять крупными конверсиями, но это не то, что нужно предпринимать легко. В некоторых случаях это может легко занять годы планирования, чтобы подготовиться к такому преобразованию.

Если вы начинаете с базы данных, которая (например) поддерживает только ASCII, возможно , есть веская причина обсудить, имеет ли смысл добавить поддержку всех этих кодировок, но если вы уже поддерживаете их, мало что можно извлечь из отбрасывания. поддержка для них.

Обратите внимание, в частности, на то, что вы, вероятно, почти ничего не получите в плане упрощения кода или чего-то подобного. Им все равно потребуются все процедуры преобразования, чтобы в любом случае иметь дело с преобразованиями между клиентом и сервером. Таким образом, удаление поддержки будет означать удаление одного (второстепенного) вызова функции в путях «запись на диск» и «чтение с диска», но мало (если что-нибудь еще). Если бы вы поддерживали даже две кодировки на диске, вы бы этого даже не получили - у вас все равно был бы вызов функции, поэтому все, что вы действительно должны были бы сделать, это ограничить диапазон кодировок, поддерживаемых этой функцией.

По крайней мере, если бы я проектировал это, я, вероятно, написал бы ядро ​​базы данных для работы в UCS-4, а затем имел бы процедуры преобразования между ядром и диском, а также между ядром и пользователем. Я бы использовал один и тот же набор подпрограмм в обоих случаях, поэтому самым простым способом было бы позволить дисковому хранилищу использовать точно такой же набор кодировок, который разрешено использовать клиентам.

Есть пара проблем с хранением только UTF-8 на сервере:

1. Каков предел VARCHAR(20)столбца? Это 20 байтов или 20 «символов» (а в Unicode, что такое «символ», когда вы учитываете комбинирование символов, лигатур и т. Д.?). Хуже того, как насчет того, CHAR(20)где он фактически должен зарезервировать все возможное пространство: я полагаю, что в MySQL он резервирует в 4 раза больше байтов для столбца в кодировке UTF-8 (то есть 80 байтов для CHAR(20)) только для обработки наихудшего случая.
2. Необходимо выполнить постоянные преобразования кодировки между кодировкой сервера и кодировкой вашего клиента. Можно утверждать, что вы также хотите прекратить поддержку нескольких клиентских кодировок, но если вы этого не сделаете, все строки необходимо преобразовывать все время. Если вы можете сопоставить кодировку вашего сервера и кодировку клиента, то преобразования не требуются.
3. Как отмечали другие, UTF-8 достаточно эффективен для хранения английского текста, но он очень неэффективен для других языков - в частности, для восточноазиатских языков. Полагаю, вы могли бы разрешить использовать UTF-16 или UTF-8 в качестве костюма. Или сжать текст, но это делает индексацию и поиск неэффективными.

Сказав все это, я согласен с вами: унаследованные кодировки в большинстве случаев бессмысленны, и Unicode, как правило, является лучшей кодировкой для всех новых приложений. Если бы я сегодня писал сервер баз данных с нуля, я бы поддерживал только Unicode и вообще не поддерживал бы устаревшую кодировку.

Разница в том, что PostgreSQL и большинство других серверов баз данных, используемых сегодня, существовали еще до того, как Unicode был приемлемым вариантом. Таким образом, у них уже была поддержка унаследованных кодировок (конечно, они не были унаследованными тогда), и нет особого смысла вырывать весь этот код по идеологическим причинам.

Неуниверсальные (и особенно однобайтовые) кодировки имеют свое место: в системах, которые:

• Недостаточно памяти для хранения базы данных символов Unicode.
• Иметь однобайтовый шрифт, жестко запрограммированный в ПЗУ.
• Не иметь доступа к Интернету, чтобы предоставить источник файлов с различной кодировкой.

Это верно сегодня для некоторых типов встраиваемых устройств. Но на рабочем столе и в серверной комнате не-Unicode-кодировки должны быть уже давно устаревшими.

UTF-8 - лучший для вас эгоцентрик ¹ англоговорящий. Если бы вы были японцами, примерно 99% ваших персонажей заняли бы 3-4 байта вместо двух в UTF-16.

Нелатинские диалекты действительно страдают от UTF-8 на уровне размера. Не забывайте, что в течение нескольких лет большинство ваших клиентов могут быть китайцами, а китайская письменность содержит миллионы символов. Вы не можете поддерживать это эффективно с UTF-8.

В противном случае, я ненавижу, когда у меня есть текстовые документы, которые не в UTF- что-то . Я часто стараюсь изо всех сил, если мне нужно иметь правильное кодирование. В моей книге не кодировки Unicode мертвы.

_{1. Не принимайте эгоцентрическую роль лично. Я хотел сделать красочную иллюстрацию, и я на самом деле не это имел в виду.}

Unicode принципиально сломан и вряд ли когда-либо будет исправлен. Это должно быть заменено чем-то лучшим, чем-то действительно универсальным. Если что-то требует устаревшего, это Unicode.

Примеры проблем с Unicide:

• UTF8 - разумный взлом, но большинство программ на основе UTF16 не работает. Большинство приложений Windows, поддерживающих Unicode, используют UTF16, включая саму ОС. Наиболее распространенной проблемой является не поддержка больше, чем базовая плоскость, то есть многословные символы.

• Объединение Хань - это безудержная катастрофа. Невозможно смешать японский / китайский / корейский текст в одном документе без дополнительных метаданных, и трудно определить, какой шрифт следует использовать.

• Комбинационные символы - еще одна катастрофа. Более разумные схемы кодирования отображают один символ в один код, что делает обработку строк относительно разумной. Юникод не имеет. Unicode даже не согласован - ханьские символы в основном являются комбинациями, но не кодируются как таковые, как европейские комбинационные символы.

• Имена некоторых людей не могут быть написаны правильно в Юникоде, или очень склонны к неправильной визуализации из-за проблем, упомянутых выше. Это может иметь серьезные последствия, например, при попытке сесть на самолет с паспортом, который не соответствует тому, что (неправильно) напечатано в билете.

Из-за этих и многих других проблем многие неанглийские программы не могут использовать Unicode и используют локальные кодировки символов. Это особенно характерно для японского и китайского программного обеспечения.

В идеале Unicode должен быть устаревшим. Кодировка символов TRON является довольно хорошей заменой Юникоду и в значительной степени совместима с существующим программным обеспечением, которое не будет обновляться.

Может быть, для записи, но не для чтения.

Существует много существующего контента, который использует эти кодировки, и некоторые кодировки, такие как base64, никуда не денутся, потому что некоторые текстовые протоколы предписывают их как способы внедрения двоичных данных.

Настоящей проблемой является автоматическое обнаружение кодировок, что приводит к дырам в безопасности. Я не возражаю против того, чтобы некоторые неясные кодировки, такие как UTF-7, просто исчезли.

Автоопределение также имеет тенденцию плохо работать с контентом, созданным наивно соединенными строками байтов.

Я могу согласиться с тем, что кодировка символов по умолчанию для баз данных и новых приложений должна быть своего рода вариантом UTF. Я лично выбрал бы UTF-16, так как он кажется разумным компромиссом между пространством и сложностью (больше, чем UTF-8). Тем не менее, некоторые кодировки символов все еще имеют смысл в некоторых случаях.

• Если вы храните / переносите текст base64, вам нужен только ASCII, и вы даже можете использовать 7-битные кодированные протоколы, такие как электронная почта. Дополнительные издержки UTF-8 не нужны.
• Несколько файлов и существующих данных построены на этих старых кодировках символов, поэтому важно иметь возможность их читать.

Обратите внимание, что есть 4 стандартных алгоритма нормализации UTF. Если вас беспокоят символы с несколькими кодами, вы можете использовать один из двух алгоритмов нормализации, которые свернут их в эквивалентный символ с одним кодом. Разница между ними связана с логической эквивалентностью и физической эквивалентностью символов.