Не удается определить тип кодировки юникод сохраните файл с сигнатурой bom

Обновлено: 04.07.2024

Если не ошибаюсь, UTF-8 без BOM это кодировка, в которой каждому символу соответствует 1 байт. А просто UTF-8 тоже самое только в начале файла идут символы ef bb bf (в HEX)
Я всё правильно понял? Какой из них лучше использовать когда сохраняешь файлы?

И ещё. Что значит строчка в статус-баре Notepad++"ANSI AS UTF-8"? Это когда выбираешь кодировку "UTF-8 без BOM"

без BOM.
если сохраните с ним, то на файлах, где есть сессии или заголовки, будет ошибка.

Если написать в utf-8 файл в 3 символа, русский пробел и английский
'З Z'
покажет без BOM
d0 97 20 5a
а с ним
ef bb bf d0 97 20 5a
т.е. два байта там только первая буква, bom это три байта

причём если набрать в строке "Выполнить" charmap
, выбрать юникод-шрифт, например "Arial"
, то символ З там записан как U+0417 Cirrilic Capital Letter Ze
а Z как U+005a Latin Capital Letter Z

т.е. чтобы файл не весил в два раза больше, из юникода сделали utf-8,
но я что-то не понял зачем сделали d097 из 0417, просто лень лезть искать чего почитать, из-за какой-то мелочи ,)

BOM актуален только для UTF-16 и UTF-32. В UTF-8 вообще нет такого понятия как BOM.

В notepad++ есть UTF-8 с BOM и без.

То что судя по всему в UTF-8 есть такое понятие как BOM. Вот попробовал сохранить русский текст с помощью notepad++ в кодировке UTF-8 без BOM - размер файла в байтах равен количеству символов (1 байт - 1 символ). Потом тот же текст просто в UTF-8 - получился файл на 3 байта больше, т.е. в начало файла добавился этот BOM, разве нет?

Нужно смотреть не на то, что написано в редакторе, а на то, что написано в стандарте.
BOM = Byte Order Mark = метка порядка следования байтов. Стандарт не определяет порядок следования байтов в UTF-8.
Поэтому три символа в начале файла с кодами EF BB BF нельзя считать BOM. На самом деле эта сигнатура обозначает, что дальше идёт текст в формате UTF-8.

> размер файла в байтах равен количеству символов (1 байт - 1 символ)
Это верно только для символов с кодом менее 128.

В UTF-8 порядок следования байтов определен, (равно как и порядок следования бит в кодовых позициях байтов) и определен весьма жестко.
В начале файла нет трех символов с кодами EF BB BF
В начале файла есть три байта EF BB BF, представляющие один символ - Byte Order Mark (0. 0FEFFu).

>Это верно только для символов с кодом менее 128.

Ну пожалуй соглашусь, только что замутил файл который состоял из 94 символов и весил 188 байт без БОМ и 191 с БОМ.

Текстовый файл сохраняемый как UTF-8 с сигнатуры BOM в начале имеет 3 байта с значениями: EF, BB, BF. Сигнатура BOM - метка порядка байтов (Byte Order Mark, BOM). Часто, BOM называют сигнатурой (соответственно, UTF-8 и UTF-8 with Signature). Признак BOM определяет, является ли файл закодированным в UTF-8. Не все программы могут корректно работать с файлами с сигнатуры BOM.

Разместил: E_Migachev Версии: | 8.x | Дата: 19.04.2013 Прочитано: 17491

Еще в этой же категории

При использовании VS Code для создания и редактирования сценариев PowerShell очень важно, чтобы ваши файлы сохранялись в правильной кодировке символов.

Что такое кодировка и почему она важна?

VS Code управляет интерфейсом ввода строки символов в буфер пользователем и чтения-записи блоков байтов в файловой системе. При сохранении файла в VS Code используется кодирование текста для определения того, какие байты получит каждый символ. Подробные сведения см. в статье О шифровании символов.

Аналогичным образом, когда оболочка PowerShell запускает скрипт, ей необходимо преобразовать байты из файла в символы для преобразования файла в программу PowerShell. Так как VS Code записывает файл, а PowerShell считывает файл, этим средствам необходимо использовать одну и ту же систему кодировки. Этот процесс синтаксического анализа скрипта PowerShell идет так: байты -> символы -> лексемы -> дерево абстрактного синтаксиса -> выполнение.

И VS Code, и PowerShell устанавливаются с подходящей конфигурацией кодировки по умолчанию. Тем не менее кодировка по умолчанию, используемая PowerShell, была изменена с выпуском PowerShell 6. Чтобы избежать проблем с PowerShell и расширениями PowerShell в VS Code, необходимо настроить параметры VS Code и PowerShell должным образом.

Распространенные причины проблемы с кодировкой

Проблемы с кодировкой возникают, если кодировка VS Code в целом или вашего файла скрипта не совпадает с кодировкой, ожидаемой в PowerShell. В PowerShell нет способа автоматически определить кодировку файла.

Проблемы с кодировкой более вероятны при использовании символов не из 7-разрядной кодировки ASCII. Пример:

Расширенные небуквенные символы, такие как длинное тире ( — ), неразрывный пробел ( ) или левая двойная кавычка ( " ).
Латинские символы с диакритикой ( É , ü )
Нелатинские символы, такие как кириллица ( Д , Ц )
Символы иероглифического письма ( 本 , 화 , が ).

Распространенные причины проблем с кодировкой:

Параметры кодировок по умолчанию VS Code и PowerShell не были изменены. В версиях до PowerShell 5.1 (включительно) кодировка по умолчанию отличается от используемой в VS Code.
Открыт другой редактор, и файл перезаписан в новой кодировке. Это часто происходит с интегрированной средой сценариев.
Файл возвращается в систему управления версиями в кодировке, отличающейся от той, которая ожидается в VS Code или PowerShell. Это может произойти, когда участники совместной работы используют редакторы с различными конфигурациями кодировок.

Как определить наличие проблемы с кодировкой

Часто ошибки кодирования в скриптах представляются как ошибки синтаксического анализа. Если вы видите странные последовательности символов в скрипте, это может быть проблемой. В примере ниже тире ( – ) отображается в виде символов â€" :

Эта проблема возникает, так как VS Code кодирует символ – в UTF-8 как байты 0xE2 0x80 0x93 . Если эти байты декодируются в кодировке Windows-1252, они интерпретируются как символы â€" .

Некоторые странные последовательности символов, которые можно видеть:

â€" вместо – .
â€" вместо — .
Ã„2 вместо Ä .
Â вместо (неразрывный пробел);
Ã© вместо é .

Этот удобный справочник перечисляет распространенные шаблоны, которые указывают на проблему между кодировками UTF-8 и Windows-1252.

Взаимодействие расширения PowerShell для VS Code с кодировками

Расширение PowerShell взаимодействует со скриптами несколькими способами:

При изменении скриптов в VS Code содержимое отправляется из VS Code в расширение. Протокол языкового сервера требует, чтобы это содержимое передавалось в UTF-8. Таким образом, расширение не сможет получить неправильную кодировку.
При выполнении скриптов в интегрированной консоли они считываются оболочкой PowerShell непосредственно из файла. Если кодировка PowerShell отличается от кодировки VS Code, может произойти сбой.
Когда скрипт, который открыт в VS Code, ссылается на другой скрипт, который не был открыт в VS Code, расширение загружает содержимое второго скрипта из файловой системы. Расширение PowerShell по умолчанию использует кодировку UTF-8, но при этом применяет обнаружение метки порядка байтов (BOM), чтобы выбрать правильную кодировку.

Проблема возникает при предположении кодировки, не использующей BOM (такой как UTF-8 без метки порядка байтов или Windows-1252). Расширение PowerShell по умолчанию использует UTF-8. Расширение не может изменить параметры кодировки в VS Code. Дополнительные сведения см. в разделе Проблема № 824.

Выбор подходящей кодировки

Различные системы и приложения могут использовать различные кодировки:

Кодировки Юникода также используют понятие метки порядка следования байтов (BOM). BOM ставится в начале текста, чтобы декодер мог определить, какая кодировка используется в тексте. Для многобайтовых кодировок BOM также указывает порядок следования байтов кодировки. BOM представляются байтами, которые редко встречаются в тексте в Юникоде. Это позволяет сделать обоснованное предположение, что текст записан в Юникоде, если присутствует метка BOM.

BOM не являются обязательными; в мире Linux они не так популярны, поскольку во всех прочих местах используется надежное соглашение UTF-8. Большинство приложений Linux предполагают, что текстовый ввод кодируется в UTF-8. Хотя многие приложения Linux могут распознавать и правильно обрабатывать BOM, некоторые этого не делают, что приводит к появлению артефактов в тексте, открываемом с помощью этих приложений.

Таким образом:

Если вы работаете в основном с приложениями Windows и Windows PowerShell, следует предпочтительно использовать такие кодировки, как UTF-8 с BOM или UTF-16.
Если вы работаете на разных платформах, следует отдавать предпочтение UTF-8 с BOM.
Если вы работаете главным образом в контексте Linux, следует отдавать предпочтение UTF-8 без BOM.
Windows-1252 и latin-1 — устаревшие кодировки, которых по возможности следует избегать. Тем не менее некоторые приложения предыдущих версий в Windows зависят от их.
Также стоит отметить, что подписывание скриптов зависит от кодировки, то есть изменение кодировки в подписанном скрипте потребует повторного подписывания.

Настройка VS Code

Кодировка VS Code по умолчанию — UTF-8 без метки порядка байтов.

Чтобы задать Кодировка в VS Code, перейдите к параметрам VS Code ( CTRL + , ) и задайте параметр "files.encoding" :

Возможны следующие значения:

utf8 : [UTF-8] без метки порядка байтов
utf8bom : [UTF-8] с меткой порядка байтов
utf16le : [UTF-16] с прямым порядком байтов
utf16be : [UTF-16] с обратным порядком байтов
windows1252 : [Windows-1252]

Должен отобразиться раскрывающийся список представления графического пользовательского интерфейса или дополнение в представлении JSON.

Чтобы обеспечить автоматическое определение кодировки, если это возможно, можно также добавить следующее:

Если вы не хотите, чтобы эти параметры влияли на все типы файлов, в VS Code можно задавать конфигурации для каждого языка отдельно. Создать параметр для конкретного языка можно, поместив параметры в поле [<language-name>] . Пример:

Вы также можете установить средство отслеживания Gremlins для Visual Studio Code. Это расширение раскрывает определенные символы Юникода, которые могут быть легко повреждены из-за своей невидимости или схожести с другими обычными символами.

Настройка PowerShell

В PowerShell кодировка по умолчанию зависит от версии:

В PowerShell 6+ кодировка по умолчанию на всех платформах — UTF-8 без метки порядка байтов.
В Windows PowerShell кодировка по умолчанию — обычно Windows-1252, расширение latin-1, которое также называется ISO 8859-1.

В PowerShell 5 + можно определить кодировку по умолчанию так:

Следующий скрипт может использоваться для определения кодировки, которую ваш сеанс PowerShell выводит для скрипта, где нет метки порядка байтов.

Можно настроить PowerShell так, чтобы использовать заданную кодировку в более общем виде с помощью параметров профиля. См. следующие статьи:

Заставить PowerShell использовать конкретную кодировку для входных данных невозможно. В PowerShell 5.1 и более ранних версий в Windows с языковым стандартом en-US по умолчанию используется кодировка Windows-1252, если отсутствует метка порядка байтов. Другие параметры языкового стандарта могут использовать другую кодировку. Для обеспечения совместимости лучше сохранять скрипты в Юникоде с меткой порядка байтов.

Любые другие имеющиеся у вас инструменты для работы со скриптами PowerShell могут зависеть от выбранных параметров кодировки или преобразовывать скрипты в другую кодировку.

Существующие скрипты

Скрипты, которые уже находятся в файловой системе, могут нуждаться в повторном кодировании в указанную вами кодировку. В нижней строке VS Code вы увидите метку UTF-8. Щелкните ее, чтобы открыть панель действий, и выберите команду Сохранить с кодировкой. Теперь вы можете выбрать новую кодировку для этого файла. Подробные инструкции см. в разделе Кодировка в VS Code.

Если вам нужно повторно кодировать несколько файлов, можно использовать следующий скрипт:

Интегрированная среда сценариев (ISE) PowerShell

При редактировании скриптов с помощью интегрированной среды сценариев PowerShell необходимо синхронизировать здесь параметры кодировки.

Интегрированная среда сценариев должна учитывать метку порядка байтов, но можно также использовать отражение для задания кодировки. Обратите внимание, что это значение не сохраняется между запусками.

Система управления версиями

Некоторые системы управления версиями, например git, игнорируют кодировки; git отслеживает только байты. Поведение других, например Azure DevOps или Mercurial, может отличаться. Даже некоторые средства, основанные на git, полагаются на декодирование текста.

Если это так, убедитесь, что вы:

Настроили кодировку в системе управления версиями в соответствии с вашей конфигурацией VS Code.
Сделали так, что все файлы добавляются в систему управления версиями в соответствующей кодировке.
Остерегайтесь изменять кодировки, полученные через систему управления версиями. Ключевым признаком здесь будет разностный файл, который указывает, что изменения отсутствуют (так как изменены байты, но не символы).

Среды других участников

Настроив систему управления версиями, убедитесь также, что параметры других участников, работающих над теми файлами, к которым вы предоставляете общий доступ, не переопределяют кодировку путем повторного кодирования файлов PowerShell.

Другие программы

Все другие программы, которые считывают или записывают скрипты PowerShell, могут перекодировать их.

Использование буфера обмена для копирования и вставки скрипта. Такое часто встречается в следующих случаях:

Копирование скрипта в виртуальную машину.
Копирование скрипта из электронной почты или с веб-страницы.
Копирование скрипта через документ Microsoft Word или PowerPoint.

Блокнот;
vim;
любой другой редактор скриптов PowerShell.

Get-Content / Set-Content / Out-File
Операторы перенаправления PowerShell, такие как > и >> .
sed / awk

Веб-браузер при скачивании скриптов.
Общий файловый ресурс.

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

Другие ресурсы о кодировках в PowerShell

Существует несколько других достойных публикаций на тему кодировок и настройки кодирования в PowerShell:

Кодировки… Вопрос, вроде бы, банальный, но, если набрать в поиске фразу типа «что такое кодировка html-документа», с одной стороны, Google, Яндекс выведут немало страниц, релевантных данному запросу. С другой стороны, внимательное прочтение многих статей заставляет сделать вывод: их авторы механически, толком не понимая, что делают, применяют те или иные кодировки. И, зачастую, достаточно успешно. Попробуем докопаться до истины, если не полностью, то хотя бы отчасти.

Проблема с кодировками может возникнуть, когда идет речь о национальных языках, которые состоят из нелатинских букв. Также может появиться необходимость в отображении на странице определенных «особенных» символов.

Известно, что в настоящее время универсальной, вроде бы, является кодировка UTF-8. Особых недостатков она, по идее, не имеет. Хотя, вот ее недостатки по сравнению с Windows-1251:

Пишут, что… Юникод достаточно коварен и подвержен «атакам неправильной кодировкой». Кстати, с Windows-1251 - все проще: она является однобайтовой, поэтому подобная атака при ее использовании едва ли возможна. Строки, закодированные в кодировке UTF-8 , недостаточно эффективно обрабатываются, например, регулярными выражениями.

Можно встретить следующие доводы, в пользу преимуществ от использования кодировки UTF-8:

Многие серверы в интернете настроены на нее по умолчанию; Кодировка UTF-8 стандартно используется в операционных системах типа UNIX/Linux ; Если браузер работает в НЕРУСИФИЦИРОВАННОЙ операционной системе Windows, то русскоязычные символы в кодировке Windows-1251 отображаться НЕ БУДУТ (или будут, но – неверно), в отличие от тех же символов, закодированных в UTF-8 ; Юникод включает практически все современные письменности, а также специальные, математические и некоторые иные символы; Если сайт выполнен на РНР , то UTF-8 – это одна из (довольно большого перечня) кодировок, которая может там использоваться; это упрощает разработку программ на РНР в силу отсутствия необходимости перекодировать строки; При необходимости поддержки других языков (например, одновременно – арабского, норвежского и т.д.) придется или использовать соответствующие этим языкам кодировки или одну – UTF-8 (впрочем, возможна UTF-16 и т.п.).

Видится, что наиболее существенным является довод из последнего пункта и, отчасти, второго. А именно – если планируется размещение, скажем, китайского, арабского и русского текста на одной вебстранице – тут едва ли получится обойтись одной лишь Windows-1251 . Тогда как UTF-8 справится с данной задачей без особых проблем. А главное преимущество UTF-8 — не в расширении набора символов, а в простом способе их включения в документ.

Как будет вести себя сервер при разных кодировках?

Пусть на вебстранице есть форма, которая передает данные на сервер. Принимает эти данные программа, например, написанная на языке PHP.

Форма, как правило, передает данные в кодировке UTF-8, для чего они предварительно перекодируются javascript при помощи строчки вида

var data = encodeURIComponent(data);

При этом при создании AJAX-запроса необходимо указать вид кодировки:

В подавляющем большинстве случаев для AJAX-запросов используется именно такой подход. Это означает, что данные на сервер пойдут в кодировке UTF-8 .

Соответственно, именно в такой кодировке они будут приняты программой (РНР). Если на сервере (точнее, на хостинге) установлена кодировка тоже UTF-8 – проблем меньше. Они возникают, если там присутствует другая кодировка, например, Windows-1251 (CP1251) .

Кстати, виртуальный сервер Denwer по умолчанию настроен именно на Windows-1251 . Заменить ее на UTF-8 , при желании, можно, открыв файл

найти там строчку

и заменить ее на

Ну и, мосле этого – перезапустить Denwer .

От чего зависит кодировка, используемая РНР?

На самом деле, она там может быть РАЗНОЙ – в зависимости от того, ГДЕ применяется. Например, регулярные выражения кодируются в одной кодировке. Строки – в другой…

По умолчанию, кодировка строк, с которыми работает программа на PHP, используется та, в которой сохранен файл с программой. Посмотреть ее можно, открыв этот файл (с расширением php) в текстовом редакторе, например, в Notepad++ . Внизу справа будет присутствовать наименование кодировки, например, ANSI as UTF .

Что означает UTF-8 без BOM ?

Кликнув мышью на пункт «Кодировки», видим, в самом деле, что установлена кодировка UTF-8 без BOM

Кстати, что такое ВОМ?

Дело в том, что для определения формата представления Юникода в начало текстового файла записывается сигнатура — символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый маркером последовательности байтов (от английского слова byte order mark ( BOM )). Это позволяет различать UTF-16LE и UTF-16BE , поскольку символа U+FFFE не существует. Также этот способ иногда применяется для обозначения формата UTF-8 , хотя к этому формату и неприменимо понятие порядка байтов. Файлы, следующие этому соглашению, начинаются с таких последовательностей байтов:

UTF-8 - EF BB BF
UTF-16BE - FE FF
UTF-16LE - FF FE
UTF-32BE - 00 00 FE FF
UTF-32LE - FF FE 00 00

Таким образом, если подобные байты присутствуют в файле (увидеть в окне редактора их не получится), то Notepad++ может самостоятельно определить кодировку файла (внимание!), даже если там нет ничего вообще (т.е. файл «пустой»).

Если выбрать « Кодировать в UTF » (это означает UTF-8 с BOM ), то надпись внизу справа окна редактора сменится на UTF-8 . Это означает, что редактор сам определил тип кодировки файла по наличию тех самых байтов, задающих ВОМ .

Примечание . Следует различать в программе Notepad++ операции « Кодировать в… » от « Преобразовать в … ». Операция « Кодировать в… » лишь меняет характер отображения текста на экране редактора, не меняя самого файла, содержащегося на жестком диске (хотя, произведенные изменения можно сохранить, тогда файл на жестком диске перезапишется). Тогда как операция « Преобразовать в… » производит именно – перекодирование, т.е. преобразование самого файла.

Пример

Рассмотрим такой код на РНР:

<?php
// Определяем кодировку программы на РНР по умолчанию:
echo "Default coding: ". mb_internal_encoding().' ';
echo 'This is the regular expression coding: '. mb_regex_encoding () . " ";
echo "Soon we shall create file. Вскоре мы создадим файл. ";
// Устанавливаем кодировку в программе на РНР как UTF-8:
mb_internal_encoding("UTF-8");
// Определяем кодировку программы на РНР по умолчанию:
echo "Custom coding: ". mb_internal_encoding().' ';
echo 'This is the regular expression coding: '. mb_regex_encoding () . " ";
// Пытаемся создать файл под названием new_file в корневом каталоге сайта:
$input = @fopen($_SERVER['DOCUMENT_ROOT'] . '/new_file.html', "a+") or die('Невозможно создать или открыть файл.');
echo "The file is created. Файл создан. ";
?>

Запускаем этот файл в Denwer , вот что получается:

Default coding: ISO-8859-1
This is the regular expression coding: EUC-JP
The file is created. Р¤Р°Р№Р» СЃРѕР·РґР°РЅ.
Custom coding: UTF-8
This is the regular expression coding: EUC-JP
The file is created. Р¤Р°Р№Р» СЃРѕР·РґР°РЅ.

Вначале по умолчанию РНР использовал кодировку ISO-8859-1 , хотя, вроде как, Notepad++ нам указывал на UTF . Кстати, если открыть этот файл в программе PHPStorm , внизу справа также будет указана кодировка UTF-8 . После принудительного задания кодировки функцией mb_internal_encoding("UTF-8") она стала UTF-8 . Регулярные выражения кодированы в совсем другой кодировке, а именно – в EUC-JP , причем – ВНЕ ЗАВИСИМОСТИ(!) от кодировки файла, в котором находится данная программа (на РНР). Русскоязычный текст отображается нечитаемо в обоих случаях.

Открыв созданный файл new_file.html , можно убедиться, что он создан, если верить Notepad++ , в кодировке ANSI (что означает Windows-1251 в данном случае), являясь при этом пустым(!). Если же открыть его в программе PHPStorm , он смело показывает его кодировку, как UTF-8 . М-да. Больше и сказать нечего.

А теперь будем экспериментировать

Изменим через Notepad++ ( PHPStorm , вроде бы, не дает такой возможности, хотя и является платной IDE, в отличие от первого) кодировку с ANSI as UTF на UTF . Для этого кликнем « Кодировки », « Кодировать в UTF-8 ». Сохраняем файл. В браузере, после обновления страницы, видим:

Default coding: ISO-8859-1
This is the regular expression coding: EUC-JP
The file is created. Файл создан.
Custom coding: UTF-8
This is the regular expression coding: EUC-JP
The file is created. Файл создан.

Открываем файл new_file.html
в Notepad++ и в PHPStorm и видим, что кодировки, указываемые этими программами, не изменились. Кстати, в PHPStorm можно задать кодировку Windows-1251 , при этом Notepad++ продолжит указывать все ту же ANSI .

Задаем кодировку Windows-1251 в метатеге вебстраницы

Для этой цели дополняем код немного:

Запускаем в браузере. Результаты – те же самые, что и в предыдущем случае. И именно, русский текст выводится читаемо только в том случае, когда указана кодировка (через Notepad++ ) UTF-8 (т.е. UTF-8 с ВОМ ). Тогда как выбор UTF-8 без BOM приводит вновь к нечитаемым символам на месте русских букв. То же самое наблюдается и когда в метатеге задана UTF-8 вместо Windows-1251.

Выводы:

Метатег html, задающий кодировку страницы как Windows-1251 или UTF-8 , в данном случае не влияет на ее отображение браузером. На отображение русскоязычного текста влияет, в какой кодировке сохранена исходная страница. Причем, это имеет значение как для текста, который задан на самой странице (при помощи тега ), так и сформирован при помощи PHP.

А если файл будет иметь расширение html и не будет обрабатываться интерпретатором РНР?

В том смысле, что такой файл не будет обрабатываться интерпретатором РНР и загрузится локально, т.е. по протоколу file. Понятно, что при этом PHP-код будет отображаться в виде простого (отформатированного по умолчанию) текста в браузере.

При этом если в метатеге страницы указана кодировка UTF-8, нет разницы, сохранена ли страница в UTF-8 с BOM или без: в любом случае русский текст отображается читаемо. Т.е. наличие ВОМ здесь не играет роли.

А вот если на странице в метатеге задать кодировку Windows-1251, то корректно отображается она (страница) только в случае, когда в Notepad++ задать кодировку UTF-8 (с BOM ). Тогда как кодировка без BOM приводит к нечитаемому отображению русского текста.

Вот тебе бабушка и Юрьев день и, якобы, «бесполезность» кодировки UTF с ВОМ … для UTF-8 , постулируемая Википедией и не только. Эту «бесполезность» почему-то любят постулировать также и на компьютерных форумах.

Вопрос, зачем и почему – оставим без внимания (Ю.Ю. Шевчук).

И еще: файлы, которые интерпретируются PHP, отображаются, в общем случае, иначе по сравнению со статическими файлами html – в смысле читаемости в случае несовпадения кодировок. Это и понятно: ведь на последние не влияют ни кодировка сервера, ни кодировка РНР.

А теперь изменим кодировку сервера

На файл, загруженный по протоколу file , конечно, никаких влияний не будет – все останется, как прежде.

А вот с файлом PHP – дело немного интереснее. Вне зависимости от того, как кодируется файл в кодировке UTF-8 с BOM или без, результат получается примерно такой:

Это просто абзац текста.
Default coding: ISO-8859-1
This is the regular expression coding: EUC-JP
The file is created. Файл создан.
Custom coding: UTF-8
This is the regular expression coding: EUC-JP
The file is created. Файл создан.

Текст отображается читаемо уже ВНЕ ЗАВИСИМОСТИ от того, какая кодировка указана в метатеге html: UTF-8 или Windows-1251 , что видится логичным: коль скоро на сервере указана кодировка (по умолчанию) UTF-8 , то наличие BOM , призванных различать разные типы UTF кодировок, получается, ни к чему: сервер и так знает про UTF-8 . Более того, русский текст отображается в браузере читаемо, даже если файл с кодом РНР кодировать как ANSI : при этом русскоязычные символы, естественно, становятся нечитаемыми (будет, так сказать, абракадабра), но, в браузере все отображается, как полагается.

Далее, видим, что кодировка РНР по умолчанию осталась той же самой, что и ранее: ISO-8859-1 . Т.е. это – вещь не зависящая от кодировки, установленной на сервере. Не изменилась и кодировка регулярных выражений в PHP.

Однако, файл new_file.html , создаваемый программой, судя по указанию Notepad++ , каждый раз имеет кодировку ANSI (т.е. windows-1251 ), опять же, ВНЕ зависимости от того, какую кодировку указать в метатеге. Конечно, PHPStorm , как обычно, указывает для него кодировку UTF-8 .

По всей видимости, тот факт, что файл всегда создается в ANSI , зависит, скорее, от операционной системы (Windows 7), чем от самого Denwer. Это тоже логично: ведь PHP, работающий под управлением Denwer , вроде как, пользуется для целей создания файлов «услугами» операционной системы, системным интерфейсом, направляя к нему соответствующие стандартные системные вызовы. А стандартная кодировка Windows – это Windows-1251 .

Выводы

Ну, во-первых, во избежание неточностей, целесообразно бы указывать кодировку (для строк) в самом начале программы РНР. Что не было потом, как говорится. Благо, это – несложно и делается одной строчкой. Например, для UTF-8 можно написать: Задание кодировки UTF-8 по умолчанию на виртуальном сервере делает текст в браузере читаемым независимо от того, в какой кодировке закодирован исходный файл PHP и независимо от кодировки, заданной в метатеге. Это справедливо, по крайней мере, для кодировок Windows-1251 и UTF-8 . Кодировка файла ANSI as UTF (т.е. без ВОМ) может быть причиной нечитаемости русскоязычного текста в случае кодировки виртуального сервера Windows-1251 или при локальной загрузке страницы (при помощи протокола file ), в том случае, когда в метатеге страницы кодировка задана как Windows-1251 или она вообще отсутствует. Иными словами, отсутствие BOM для файла, кодированного в UTF-8 , может вызвать проблемы с отображением контента страницы.

Для наглядности, выводы сведены в таблицу:

Кодировка, заданная в метатеге страницы	Кодировка файла, показываемая в Notepad++	Отображение файла html по протоколу file	Отображение файла PHP при кодировке виртуального сервера
Кодировка, заданная в метатеге страницы	Кодировка файла, показываемая в Notepad++	Отображение файла html по протоколу file	Windows-1251	UTF-8
-	ANSI as UTF (UTF-8 без BOM)	Нечитаемый	Нечитаемый	Читаемый
-	UTF-8	Читаемый	Читаемый	Читаемый
Windows-1251	ANSI as UTF (UTF-8 без BOM)	Нечитаемый	Нечитаемый	Читаемый
Windows-1251	UTF-8	Читаемый	Читаемый	Читаемый
UTF-8	ANSI as UTF (UTF-8 без BOM)	Читаемый	Нечитаемый	Читаемый
UTF-8	UTF-8	Читаемый	Читаемый	Читаемый

Вот почему кодировка сервера UTF-8 , в самом деле, видится более удобной, чем Windows-1251 – даже при использовании в операционной системе Windows (седьмой версии).

Как быть с русскоязычным текстом, формируемым на странице, отдаваемой сервером при помощи PHP?

Итак, если кодировкой сервера является UTF-8 – проблем меньше. Можно просто отдавать русскоязычный текст при помощи, например, команды echo. Если же кодировкой сервера является Windows-1251 , то, на самом деле, особенно страшного ничего нет: надо лишь кодировать русскоязычный текст, отдаваемый РНР серверу, который он, в свою очередь, отдает браузеру. Если текст присутствует или формируется в самом файле РНР, то для этой цели наиболее целесообразна команда типа

mb_convert_encoding('Русскоязычный текст', "Windows-1251", "utf-8" );

Однако, бывают случаи, когда русскоязычный текст считывается из файла, например, базы данных. И вот здесь зависит от того, как он закодирован. Например, если в файле – кодировка ANSI ( Windows-1251 ), то это означает, что перекодировать считываемый из него текст НЕ НАДО. Ибо он и так уже закодирован в нужной кодировке. Этот момент может привести, иной раз, к проблемам. Когда, к примеру, разные части баз данных записаны в разных кодировках (о чем свидетельствуют обсуждения на компьютерных форумах). Тем более, что повторное кодирование может привести к нечитаемости некоторых символов (в частности, кириллической буквы И) - даже при последующем обратном (тоже повторном!) перекодировании.

Читайте также: