Я поддерживаю два, как правило, параллельных сайта, основанных на недавнем выпуске хорошо известной CMS на основе php. Один сайт на английском, другой на польском. (Польская локализация является стандартной опцией для CMS.) Оба работают нормально.
В частности, польский сайт правильно отображает польские диакритические символы, а также несколько "специальных" немецких и кириллических символов. Когда я просматриваю заголовки, созданные CMS, я вижу
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
именно так, как я ожидал. Unicode - это лучший способ.
Английский сайт, конечно же, правильно отображает английские символы, плюс аналогичное количество "специальных" немецких и кириллических символов отображается правильно. Когда я просматриваю заголовки, созданные CMS, я вижу
<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1' />
чего я не ожидал, поскольку iso-8859-1 - насколько я могу судить - не может отображать польские диакритические знаки и любую кириллицу. (Полагаю, я должен исключить недиакритические польские символы и кириллические символы, которые выглядят как латинские, но перекрытия не имеют значения.)
В1: Как правильно отображаются польские диакритические знаки и кириллические символы на странице, объявленной в заголовке как кодированная в формате iso-8859-1? Может ли браузер читать спецификацию или анализировать фактическое содержимое и отменять объявление заголовка? Или что?
Q2: Есть ли веская техническая причина, по которой в английской установке CMS по умолчанию должна по-прежнему использоваться кодировка iso-8859-1 вместо utf-8? Я думаю, что все установки должны использовать кодировку utf-8, но нет никаких серьезных причин для преобразования английской версии. Может здесь кто-то может придумать вескую причину?
A1: Вероятно, ваш веб-сервер настроен на отправку кодировки UTF-8 в заголовке HTTP перед отправкой HTML. Я думаю, вы можете проверить заголовки HTTP с помощью инструментов разработчика Firebug или Chrome (Ресурсы->http: //...-> Заголовки-> Заголовки ответа).
A2: Может быть, они все еще используют 8859-1, потому что у них не было времени перейти на UTF8?
Q1: CMS может использовать объекты HTML для кодирования символов вне диапазона кода ISO 8859-1.
Q2: Мне не известны какие-либо причины для выбора ISO 8859-1 вместо UTF 8 в этом случае.
Проблема с Unicode заключается в том, что все звенья в цепи должны поддерживать его, иначе он будет искажен.
Вот обычная проблема. Хранится ли контент в базе данных? Он должен быть совместим с 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 для кодирования на всех наших сайтах, и у нас не было никаких трудностей.