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 бит. Где будут проще алгоритмы и быстрее обработка?