ArtReal's readme
personal unreality:  точка пушистости

О роли кодировок в жизни веб-сервера

16.06.07 12:55 ◇ keywords: web, технологии

Читал о роли nginx в формировании светлого будущего, и вот какой момент заинтересовал:

Внутри проектов удобно иметь кодировку UTF-8, поскольку в ней можно отобразить почти все необходимые символы. Но при передаче по сети текста (если не учитывать сжатия через deflate которое принимают не все клиенты) в кодировке UTF-8 он имеет объем почти в два раза больше чем в кодировке cp1251 или koi8-r. Большинство клиентов используют кодировку cp1251 и если выбирать из koi8-r и cp1251 отдавать клиенту лучше в cp1251. Вот тут то и нужен nginx — он получает ответ от бэкенда в UTF-8 и на лету перекодирует его в cp1251, при этом символы которых нет в UTF-8 заменяются на html-entities, поэтому ничего не теряется. [ >>> ]
И вот тут свой верх взяло сомнение. По моим прикидкам, все наоборот.
а) С учетом того, что доля контента в полностью загруженной странице (как правило) не превышает 10% (остальное — графика, html, скрипты; если без дизайна — то порядка 50%), то объем страницы в utf-8 будет чуть больше, чем в cp1251, а не «в два раза больше»
б) В utf-8 символы кодируются переменным числом байт, а работа скрипта/программы с переменной длиной структуры данных — не лучшая идея. Усложнение алгоритмов обработки, глюки в неожиданных местах, etc. Т.е. обрабатывать на бэкенде лучше в кодировке с фиксированным числом байт на символ — 8 или 16.
Вот и получается, что практичнее обрабатывать (и хранить в БД) лучше в cp1251 (или U-16 для мультиязыковой поддержки), а выдавать — в utf-8

ps (20:18). Чтобы наглядно показать, почему utf-8 так же полезен серверу как коту консервная банка, привязанная к хвосту, рассмотрим некий пример.
Допустим, нам нужно обработать большой массив данных по преобразованию Канна-Дикни. Данные хранятся в формате int, но трех разных размеров (в зависимости от того, в какой размер данное число влезает) — 8, 16 и 32 бит. Алгоритм расчета должен по ходу вычислений (сложение, перемножение, max-min, etc) учитывать то, что два аргумента могут иметь разный размер в байтах (1, 2 или 4), а приведение к одному размеру не производится (т.е. алгоритм должен нативно уметь работать с числами любого, заранее неизвестного размера).
И сравним теперь с ситуацией, когда все числа только 32 бит. Где будут проще алгоритмы и быстрее обработка?

 [ link ]
Comments   [ 2 ]
[ 1 ] Павел  / 16.06.2007 17:09
a) согласен, латиница и всякие «обычные» символы html разметки или js помещаются в ascii и занимают в юникоде тот же байт. разница (именно в два раза) возникнет только на кириллице. например: «я» в cp1251 — FF, а в utf-8 — D1 8F. но экономить на таких спичках — это, имхо, несеръезно.

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

поправьте меня, если я заблуждаюсь в своих рассуждениях.

ArtReal: (Кое-что добавил в запись)

Не совсем понял, с чем именно несогласие. С тем, что обрабатывать надо с фиксированным числом байт на символ (а не с переменным) или с тем, что выдавать с сервера поток нужно не в utf-8?
(не забываем, что у нас тандем из двух серверов: один обрабатывает, а другой — отдает посетителю)


[ 2 ] Павел  / 16.06.2007 21:14
Не согласен с тем, что использование юникода автоматически приведет к проблемам, только потому, что количество символов и количество байтов данных непропорциональны. Либо я знаю, с какой кодировкой я работаю, либо конвертирую в ту, которая мне нужна. И глюков в неожиданных местах (в этом контексте) не будет :)

На счет ps: используя шаблоны, алгоритмы будут одинаковы. В контексте кодировок это значит, что используемые алгоритмы могут быть достаточно high-livel’ные, к чему все, собственно, и идет. Я ошибаюсь?

Другими словами: на каком конкретном примере можно проиллюстрировать проблемы, о которых Вы говорите?

ArtReal: Ну, с точки зрения программиста, которому язык позволяет сказать set encoding=bla-bla, и после этого все строковые функции (включая regexps) магическим образом перенастраиваются — тут действительно, разницы никакой. Если не задумываться над тем, как эта универсальность достигается.
Зато эта разница начинает хорошо ощущаться при дефиците ресурсов.
И, кстати, со стороны веб-сервера или СУБД разница между «резиновыми» данными и «резиновыми» алгоритмами vs. «фиксированные» хорошо ощущается.
(можно я не буду углубляться в теорию алгоритмов, адаптивность при критических нагрузках и основы оптимизации?)


Comments   [ 2 ]