Кодировка символов: UTF8 vs iso-8859-1
Я поддерживаю два обычно параллельных сайта, основанных на недавнем выпуске хорошо известной CMS на основе php. Один сайт на английском, один на польском. (Польская локализация является стандартной опцией для CMS.) Оба работают нормально.
В частности, польский сайт правильно отображает польские диакритические знаки, а также несколько "специальных" немецких и кириллических символов. Когда я проверяю сгенерированные CMS заголовки, я вижу
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
именно так, как я ожидал. Юникод это путь.
Конечно, английский сайт правильно отображает английские символы, а также добавляются "специальные" немецкие и кириллические символы. Когда я проверяю сгенерированные CMS заголовки, я вижу
<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1' />
это не то, чего я ожидаю, так как iso-8859-1 - насколько я могу судить - не способен изобразить польские диакритические знаки и любую кириллицу. (Я полагаю, что я должен за исключением недиакритических польских символов и кириллических символов, которые выглядят как латинские, но совпадения не имеют значения.)
Q1: На странице, объявленной в заголовке для кодировки iso-8859-1, как правильно отображаются польские диакритические знаки и кириллические символы? Может ли браузер читать спецификацию или анализировать фактический контент и переопределять объявление заголовка? Или что?
В2: Есть ли веская техническая причина, по которой при установке CMS на английском языке по-прежнему используется кодировка iso-8859-1 вместо utf-8? Я думаю, что все установки должны использовать кодировку utf-8, но нет особой причины конвертировать английскую версию. Может, кто-то может здесь придумать вескую причину?
3 ответа
Q1: CMS может использовать объекты HTML для кодирования символов вне диапазона кода ISO 8859-1.
В2: Я не знаю каких-либо причин выбирать ISO 8859-1 вместо UTF 8 в этом случае.
A1: Вероятно, ваш веб-сервер настроен на отправку кодировки UTF-8 в заголовке HTTP перед отправкой HTML. Я думаю, что вы можете проверить HTTP-заголовки с помощью инструментов разработчика Firebug или Chrome (Resources-> http:> Headers-> Response Headers).
A2: Может быть, они все еще используют 8859-1, потому что у них не было времени, чтобы переключиться на UTF8?
Проблема с юникодом заключается в том, что все звенья в цепочке должны поддерживать его, иначе он будет искажен.
Вот общая проблема. Содержимое хранится в базе данных? Это должно быть UTF8-совместимым. Для mysql войдите в систему из командной строки и введите команду
show table status
Каждая таблица будет отображать кодировку / набор символов.
Вы можете увидеть больше о кодировке php utf8 здесь
https://stackoverflow.com/questions/1344692/i-need-help-fixing-broken-utf8-encoding
и больше на php/mysql здесь
https://stackoverflow.com/questions/405684/php-mysql-with-encoding-problems
Чтобы ответить на ваш второй вопрос - от U+0000 до U+00FF в UTF8 идентичен ISO 8859-1 (Latin-1). Мы используем UTF-8 для кодирования на всех наших сайтах и не испытывали никаких трудностей.