Категории

Кодировки

Ситуация такая. В html прописываю <meta http-equiv="Content-Type" content="text/html; charset=windows-1251"> А при открытии страницы определяется UTF-8 ???

весь скрипт полностью на utf-8

одна строчка ничего не изменит. все равно страницы все формируются в utf-8

Здравствуйте!

Проблема заключалась в файле .htaccess У Вас в последних двух строках было
прописано, чотбы по умолчанию браузер открывал страницы в кодировке utf-8...

и что все резко стало отображаться в windows-1251?

потому что все в кодировке utf-8. потому и вывод настроен под кодировку utf-8

Евгений а почему выбор пал именно на utf-8 ?

Просто я положил свой файл в корень сайта и он не отображался. Теперь отображается, как и все остальное :)

Евгений а почему выбор пал именно на utf-8 ?

проблем с кодировкой в разы меньше :)

Евгений а почему выбор пал именно на utf-8 ?

Всем кодировкам кодировка UTF-8: современно, грамотно, удобно
Источник: http://www.webtest.philigon.ru/

Не существует самого лучшего браузера, самого лучшего текстового редактора, самой лучшей операционной системы… А самая лучшая кодировка существует. Это UTF‑8.

За техническими подробностями можно обратиться к RFC 3629 (STD 63) и стандарту Unicode (п. 3.9). А здесь пойдёт речь о практической стороне использования UTF‑8.
Главное преимущество

В кодировке UTF‑8 вы можете непосредственно включать в документ любые символы из всего набора Unicode. Старинные кодировки (например, Windows‑1251 или KOI8‑R) предоставляли не более 256 символов, а в Unicode есть свыше 100 000 символов. Среди них — типографские знаки (тире, кавычки, многоточие, апостроф, неразрывный пробел, неразрывный дефис и пр.), специальные символы (№, §, ©, ‰, × и пр.), буквы с диакритическими знаками и лигатуры (é, è, Ü, Æ, ø, ﬁ и пр.), символы почти всех существующих в мире алфавитов (α, Ω, א, ת, ѣ, 伲, 儻 и пр.), пиктограммы и значки (→, ■, ♥, ☺ и пр.) и множество других символов.

Загляните в «Таблицу символов» на своём компьютере. В кодировке UTF‑8 вы можете взять прямо из этой таблицы любой символ и вставить его непосредственно в свой документ. Если вам нужен знак копирайта, градуса или интеграла — не требуется искать особый шрифт, представлять этот знак в графическом формате или выдумывать ещё какие‑то ухищрения. В кодировке UTF‑8 любой символ, будь то дробь ⅓ или китайский иероглиф, можно использовать в документе точно так же, как латинскую букву «A», русскую «Ы» или знак «+».

В старых кодировках можно было вставить в документ особые символы с помощью подстановок (references). Например, длинному тире соответствовала подстановка — (а также — или —), а греческой букве «пи» — подстановка π (а также π или π). Для большинства символов существовали только числовые подстановки: например, для дроби ⅓ — ⅓ или ⅓, для музыкального знака «бемоль» — ♭ или ♭, для неразрывного дефиса — ‑ или ‑. Конечно, это очень неудобно. Во‑первых, слишком длинно: например, вместо одного символа «♭» приходится вставлять семь: ♭. Во‑вторых, документ с подстановками неприятно просматривать и редактировать. Гораздо удобнее, когда вы видите в документе непосредственно те символы, которые там должны быть, а не коды вроде — или π.

Когда‑то давно разработчики веб‑страниц были вынуждены пользоваться такими громоздкими подстановками, потому что кодировки UTF‑8 ещё не существовало. Но теперь можно забыть как про подстановки, так и про старые кодировки.
Мифы о недостатках

Обсудив преимущества UTF‑8, стоило бы поговорить и о недостатках этой кодировки. А недостатков, представьте себе, у неё нет. Есть только мифы и легенды, а также слухи и домыслы, которые распространяют замшелые консерваторы и махровые ретрограды. Много лет назад некоторые недостатки действительно имели место, но сейчас они канули в Лету.
Браузеры плохо поддерживают UTF‑8?

Говорят, что у некоторых пользователей всё ещё установлены старые браузеры, которые не способны отображать страницы в UTF‑8. Это полная ерунда. Даже Internet Explorer 4 и Netscape 4, которыми уже давно никто не пользуется, прекрасно понимают UTF‑8. А более современные браузеры — и подавно.

UTF‑8 — вовсе не «новомодная» или «молодая» кодировка, она успешно применяется более десяти лет. Если некий разработчик узнал о ней недавно или не знает до сих пор — это недостаток его квалификации, а не кодировки.
С UTF‑8 возникают проблемы на веб‑сервере?

«Я поместил на сервер страницу в UTF‑8, а она отображается кракозябрами»,— так иногда жалуются начинающие разработчики. На самом деле, такая проблема случается с самыми разными кодировками и не связана ни с какими специфическими особенностями UTF‑8. Здесь неприятность в том, что страница сделана в одной кодировке, а сервер в заголовках HTTP сообщает другую. Надо привести настройки сервера в соответствие с действительной кодировкой веб‑страниц. Повторю, что это надо сделать при любой кодировке.
Файлы в UTF‑8 занимают много места?

Говорят, что документы в UTF‑8 становятся в два раза больше, чем в старых кодировках. Это миф из разряда «слышал звон, да не знаю, где он». На самом деле — раз на раз не приходится. Например, если документ состоит только из символов ASCII (латинские буквы, цифры, знаки препинания и т. д.) — то в кодировке UTF‑8 он будет занимать ровно столько же байтов, сколько в любой другой. Если документ содержит только буквы русского алфавита и никаких других символов (что, согласитесь, бывает достаточно редко) — то в UTF‑8 он действительно станет в два раза больше. А если в нём, например, поровну русских и арабских букв — в UTF‑8 он будет в два раза меньше, чем, например, в Windows‑1251 или Asmo‑708.

Та самая страница, которую вы сейчас читаете, в кодировке UTF‑8 занимает 35 килобайтов. А если перевести её, например, в Windows‑1251, она будет занимать 26 килобайтов. Кстати, сравнивая страницы, посмотрите, насколько легче читается код в UTF‑8.

Рассуждая о «весе» веб‑страниц, следует отметить, что основную часть этого веса обычно составляет не код HTML, а изображения. (А также, возможно, другие объекты: ролики Flash, файлы JavaScript и т. д.) В результате даже в тех случаях, когда документ в UTF‑8 увеличивается — это практически незаметно в общем объёме данных. По‑моему, «разбухание» кода на несколько процентов — недорогая цена за главное преимущество UTF‑8, с которого мы начали.

Тем, кто заботится о «весе», следовало бы в первую очередь выкинуть из кода устаревшие атрибуты HTML (вроде cellpadding или valign) и подстановки для тех символов, которым они не нужны (например, — для длинного тире или   для неразрывного пробела). Действительно, иногда доходит до маразма — некто упирается: «Не буду делать страницы в UTF‑8, потому что они от этого увеличиваются» — а сам при этом ваяет код с жуткими атрибутами и подстановками, который без них мог бы быть в пять раз короче.
Серверные языки программирования и базы данных плохо поддерживают UTF‑8?

Кто‑то скажет: «Всё это хорошо, пока мы имеем дело со статичными веб‑страницами. Но если мы пользуемся PHP и MySQL, про UTF‑8 лучше забыть». Это тоже неправда. В древности, действительно, некоторые языки программирования и системы управления базами данных не умели работать с UTF‑8. Но сейчас все современные языки программирования и базы данных находятся в прекрасных отношениях с этой кодировкой. А несовременными языками и базами пользоваться не стóит: чем древнее ваши системы, тем проще их взломать.

На моём персональном сайте можно видеть результаты работы программы на PHP 4, которая расставляет переносы в словах. Она получает на вход текст в UTF‑8 и выдаёт тот же текст в UTF‑8, но с переносами. Между прочим, исходный код самóй программы также представлен в UTF‑8.

Могу ещё продемонстрировать любительский сценарий на Perl, который считает количество вертикальных штрихов в буквах текста. Запуская этот сценарий, ему в качестве параметра надо передать текстовый файл в кодировке UTF‑8, например: palki.pl file.txt. Опять же, сам сценарий тоже представлен в UTF‑8.

Единственная трудность с серверными программами — в том, что многие из них по умолчанию настроены не на UTF‑8, а на другие кодировки. Ну так перенастройте; мы же с вами не дети малые, чтобы везде и всюду использовать только настройки по умолчанию.
Поисковые системы плохо работают с UTF‑8?

Ещё приходится слышать, будто поисковые системы «спотыкаются» об UTF‑8. Эти сведения, опять же, устарели лет на восемь. Вот вам, например, поисковая система «Яндекс»:

Убедитесь, что она прекрасно находит всё, что угодно, на моём персональном сайте, где, между прочим, её работу «осложняет» не только UTF‑8, но и переносы в словах.

Таким образом, не существует никаких противопоказаний к широкому применению UTF‑8. Те, кто считает по‑другому, просто отстали от жизни.
Когда UTF‑8 не надо использовать

Конечно, бывают случаи, когда самую лучшую кодировку UTF‑8 использовать всё‑таки нежелательно. Хотя это вовсе не те ситуации, которыми пугают адепты вышеразвенчанных мифов.

Во‑первых, иногда нам требуется не создавать новый документ, а внести изменения в уже существующий. Обычно в таких случаях нет смысла преобразовывать имеющийся документ в кодировку UTF‑8, поэтому приходится редактировать его в той кодировке, в которой он представлен.

Во‑вторых, иногда работу сайта обеспечивает программное ядро (так называемый «движок»), которое не умеет работать с UTF‑8. В такой ситуации, конечно, следует задуматься, нет ли возможности подправить «движок» или заменить его на другой. Но это не всегда удаётся. Некоторые программные ядра обеспечивают функциональные достоинства, ради которых можно смириться с устаревшей кодировкой.
Как работать с UTF‑8

В качестве «недостатков» UTF‑8 упоминают и тот факт, что с ней сложно работать — мол, не все текстовые редакторы её поддерживают. Ну так пользуйтесь хорошим редактором, у которого нет проблем с современными кодировками. Кодировку UTF‑8 понимают все нынешние редакторы — от стандартного «Блокнота» в Windows до Dreamweaver’а. (Сам я, кстати, пользуюсь EmEditor’ом, и этот сайт сделан именно его средствами.)

Надеюсь, что дальнейшие рекомендации будут вам полезны при работе с UTF‑8.
Отключайте BOM

При сохранении файла многие текстовые редакторы предлагают флажок «Include Unicode Signature (BOM)», «Add Byte Order Mark» или нечто подобное. Прежде всего убедитесь, что в вашем редакторе это есть. Если похожей настройки не обнаружено (как, например, в «Блокноте») — пользоваться таким редактором для серьёзных задач не стóит. Найдя этот флажок — отключите его.

Byte Order Mark (BOM) — это три служебных байта, которые автоматически записываются в начало документа и обозначают, что он сохранён в кодировке UTF. Подробности можно прочитать в справочнике, а практическая сторона заключается в том, что эти служебные байты в UTF‑8 не являются необходимыми, зато, наоборот, могут ввести в заблуждение некоторые старые браузеры и другие программы.
Настройте простые сочетания клавиш для специальных символов

Если за каждой кавычкой, тире или неразрывным пробелом лезть в «Таблицу символов» — можно до старости провозиться с одним‑единственным документом. Для наиболее распространённых специальных символов рекомендуется настроить сочетания клавиш, что обеспечит любой хороший редактор. Например, я наладил EmEditor так, что по нажатию Ctrl↓ -↓ ↑↑ в документе появляется длинное тире, а по нажатию Ctrl↓ пробел↓ ↑↑ — неразрывный пробел. Таких сочетаний клавиш у меня около 20, и они позволяют вводить наиболее полезные специальные символы так же просто, как обычные буквы и знаки препинания.

Конечно, когда мне требуется редко используемый символ — буква «юс», рожица или иероглиф,— я обращаюсь к «Таблице символов».
Указывайте кодировку везде, где требуется

Убедитесь, что веб‑сервер сообщает правильную кодировку страниц. Если это не так — обратитесь к администратору сервера или прочтите справочные материалы о том, как настроить кодировку.

Встречаются службы размещения сайтов (хостинги), которые «намертво привязаны» к какой‑либо одной кодировке и не позволяют хозяевам сайтов пользоваться другими кодировками. С такими хостингами связываться не стóит. В какой кодировке делать страницы — должен решать разработчик сайта, а не служба его размещения.

В коде HTML часто имеет смысл использовать элемент meta:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Существуют разные мнения про использование meta для указания кодировки. Когда‑то я считал, что этот элемент скорее вреден, чем полезен. Однако ряд исследований и собственный опыт заставили меня пересмотреть свою точку зрения. Применять или не применять meta — следует решать отдельно для каждого конкретного сайта.
Не забывайте о шрифтах

Какой бы кодировкой вы ни пользовались, надо помнить, что браузеры отображают только те символы, которые есть в установленных на компьютере шрифтах. «Таблица символов» показывает именно их. Перечень стандартных шрифтов Windows размещён в разделе «Справочники».

В Unicode можно найти немало других символов — например, руны (, и пр.), буквы глаголицы (, и пр.), разнообразные значки и пиктограммы (, , и пр.). Но вставить их в документ не получится: у подавляющего большинства пользователей нет шрифтов, в которых присутствовали бы эти знаки. Тут даже UTF‑8, при всех её достоинствах, помочь не в силах. Приходится размещать такие символы в виде растровых изображений (как сделано здесь) или искать другие обходные пути.

Многие другие «экзотические» символы обычно доступны на компьютерах пользователей, но браузеру приходится помогать найти нужный шрифт. Например, чтобы отобразить старославянские буквы (Ѣ, Ѭ и пр.) или математические знаки (∉, ∀ и пр.) — я указываю в CSS шрифт «Lucida Sans Unicode».

Один из редких мифов в пользу UTF‑8 говорит, что эта кодировка заставляет компьютер отображать такие символы, которые недостижимы ни в одной старой кодировке. Однако чудес не бывает: если у вас на компьютере нет шрифта, в котором присутствует скрипичный ключ,— то вы не увидите этого символа в UTF‑8 с таким же успехом, как в любой другой кодировке.

Главное преимущество UTF‑8 — не в волшебном расширении набора символов, а в простом способе их включения в документ.
Смотрите в будущее

Если вы знакомы с Unicode, то, возможно, поинтересуетесь, почему я советую именно UTF‑8, а не другие современные кодировки — скажем, UTF‑16 или UTF‑32. Отвечаю: они обеспечивают то же главное преимущество, что и UTF‑8, но обладают и рядом недостатков. Во‑первых, они, в отличие от UTF‑8, действительно заметно увеличивают «вес» файлов. Во‑вторых, с ними в некоторых используемых ныне браузерах ещё возникают проблемы.

Кстати, Консорциум W3C рекомендует использовать для веб-страниц именно UTF‑8.

Однако не забывайте о том, что мир постоянно меняется. Возможно, в будущем возникнут причины, которые заставят нас отказаться от UTF‑8 и перейти на какую‑то ещё более совершенную кодировку. Когда это случится, я обязательно вам сообщу.

Источник