Xpoint
   [напомнить пароль]

Как дела с UTF-8? Есть ли проблемы с использованием?

Метки: [без меток]
2006-02-05 21:27:35 [обр] wiktar(0/20)[досье]

Добрый день! :)

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

Сайт выдаёт HTML 4.1 Strict. Работает всё на PHP 4.3-5. Хранение данных в БД MySQL 4.0.16-5.1. Сервер - Apache 1.3 - 2.55.
Хочется уже и данные хранить в UTF, и в скрипте обрабатывать именно их, и юзерам выдавать.

Могу ли столкнуться где-то с проблемой недостаточной поддержки?

С отображением шрифтов Arial, Times, Georgia, Verdana, Tahoma в Unicode проблем не будет?
PHP 4.3 без проблем работает с? В частности, регулярные выражения и остальные функции работы с текстом.
И БД... ОК?

Зачем мне это?
Просто хотя проект до сих пор одноязычный (русский), но в планах всегда может стать мультиязычным (Чешский язык, Беларуский).

Ещё вопрос. Объём передаваемых данных в UTF-8 будет в два раза большим, чем в CP1251?

Буду рад ответам :)

спустя 1 час 22 минуты [обр] Алексей В. Иванов(9/2861)[досье]

Глобальных проблем с unicode нет. Все мои последние проекты работают на utf-8.
Про шрифты лишнее, они тут не при чем (набор их символов не зависит от используемой кодировки, конечно, их нельзя назвать совсем полными, но Вы в реальной жизни вряд-ли встретитесь с серьезными проблемами).
Есть некоторые пережитки прошлого, которые дают о себе знать, например:

  • Некоторые модули не готовы работать с unicode, взять для примера smarty. Функция «trancate», которая урезает строку не N-символов (удобно использовать для вывода абзаца новости, например), не умеет работать с многобайтовыми кодировками. Если сказать ей вырезать первые 30 символов от русской строки, то она вернет 15 по понятным причинам;
  • Совковые системы, вроде ASSIST'а, не поддерживают unicode (ASSIST, надо сказать, вообще ничего, кроме win-1251 не поддерживает), поэтому, приходится делать "костыли" в виде страниц-редиректов в кодировке win-1251.

В общем, я хочу сказать, нет таких проблем, которых стоило бы бояться. Плюсов больше или «==».

Объём передаваемых данных в UTF-8 будет в два раза большим, чем в CP1251?

Смотря что подразумевать под передаваемыми данными и какой набор символов они будут использовать. UTF-8 кодирует один символ от 1 до 4 байтов. Если мы берем латиницу, а обычно половина HTML-документа в ней (тэги), то это один байт, русский язык — двумя байтами. Китайский, кажется, все 4 байта.

спустя 19 минут [обр] wiktar(0/20)[досье]

Алексей В. Иванов[досье] спасибо за подробный ответ!

Smarty, кстати, огорчило. Планирую именно его использовать в качестве шаблонизатора. Чтож, что-нибудь придумаем.

А в JavaScript проблем не наблюдалось? В частности, проверка правильности заполнения форм.

спустя 22 минуты [обр] Алексей В. Иванов(9/2861)[досье]

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

С JS никаких проблем быть не может в принципе, ведь он всегда работает с unicode, даже тогда, когда страница загружается в однобайтовой кодировке.

спустя 15 минут [обр] wiktar(0/20)[досье]

Алексей В. Иванов[досье] отлично! Тогда проблем вообще нет.

И если на основе собственного опыта я могу судить о том, что PHP работает с UTF-8 без проблем, то как насчет Perl, Ruby, Python? Что если вдруг понадобиться написать модуль на ином языке, не вызовет ли это проблем?

спустя 16 часов [обр] Владимир Палант(49/4445)[досье]
сообщение промодерировано
Ну как раз в Perl уже более-менее стабильная встроенная поддержка Unicode (Поддержка Unicode), PHP до этого еще далеко, насколько я понимаю.
спустя 6 часов [обр] Алексей Серебряков(0/10)[досье]

Ruby очень плох с поддержкой нелатинских символов
Python изначально проектировался с поддержкой Unicode.

А вообще давно взял UTF-8 за стандарт. Серьезных проблем не встречал.

спустя 18 часов [обр] Закиров Руслан(0/341)[досье]
Маленькая поправка. В UTF-8 один code point занимает от 1-го до 4-х байт, но "символ"(grapheme - графема) может состоять из последовательности code point'ов, например ä можно записать с помощью одного code point'а <a-umlaut> &#x00E4;, но так же и двумя <a + umlaut> &#x0061;&#x0308; ä. Некоторые графемы могут состоять из большего числа кодирующих точек, например &#x03B0; (2 байта в UTF-8) при преобразованиях регистра может превратиться в &#x03C5;&#x0308;&#x0301; (6 байт в UTF-8).
спустя 1 день 6 часов [обр] wiktar(0/20)[досье]
Закиров Руслан[досье] гм. Так ведь символы, например, кириллицы не обязательно представлять в виде &#x0045 - таких вот штук? или обязательно???
спустя 1 день 1 час [обр] Закиров Руслан(0/341)[досье]

wiktar[досье] Есть code point (кодирующая точка) - любое значение из диапазона целых чисел от 0 до 10FFFF (0 - 1 114 111). Вообщем-то unicode - это отображение всевозможных метаданных в этот диапазон, то есть код несет различные свойства, например что это буква алфавита, цифра или что-то еще.

Для передачи или представления Unicode можно использовать непосредственно кодирующие точки, например в HTML entities, но стандарт также определяет несколько форматов преобразований Unicode (Unicode Transformation Format - UTF): UTF-7, UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE. Число определяет минимальную длинну в битах для кодирования одного unicode кода, а суфикс LE или BE определяют старшинство байтов в многобайтных кодировках (разные платформы записывают по разному машинные слова).

О форматах:

  • UTF-7 используется только в протоколах передачи данных, где возможные значения байта ограничены от 0 до 127, например почта и Content-Transfer-Encoding: 7-bit;
  • UTF-8 наиболее распространен, обладает рядом преимуществ:
    • нет зависимости от последовательности байт,
    • коды от 0-127 остаются без изменений
  • UTF-16 менее распространен, этот формат трансформирует коды от 0 до D7FF без изменений в 16 бит, а 32 бита используется только для больших значений кодов.
  • UTF-32 без преобразования, но самый прожорливый по объемам так как значимых только 21 битов, используется для внутреннего представления данных в некоторых системах и/или их API.

В рамках веб-разработок стоит подробно остановится на UTF-8 и UTF-16. Если рассматривать русский язык, то в основном понадобятся unicode коды из диапазона 0400-04FF, что в укладывается в два байта в UTF-8, но вот если вы будете отдавать CJK в UTF-8, то большинство кодов будет занимать по 3-4 байта и для таких вариантов предпочтительней UTF-16, где все таки большинство кодирующих точек укладывается в два байта.

спустя 29 дней [обр] wiktar(0/20)[досье]

База данных MySQL 4.0.16.
Поиски в интернете показали, что она не совсем хорошо работает с unicode? И нормальная поддержка появилась только в MySQL 4.1.

Неужели правда?

спустя 1 день 11 часов [обр] Иван Шумков(0/77)[досье]
Правда. UTF-8 поддерживает версия 4.1 и старше.
Powered by POEM™ Engine Copyright © 2002-2005