Как сохранить файл php в utf 8
Обновлено: 05.07.2024
у меня есть приложение, которое работает с клиентами со всего мира, и, естественно, я хочу, чтобы все, что входит в мои базы данных, было закодировано UTF-8.
основная проблема для меня заключается в том, что я не знаю, какая кодировка источника любой строки будет - это может быть из текстового поля (используя <form accept-charset="utf-8"> полезно только в том случае, если пользователь действительно отправил форму), или это может быть из загруженного текстового файла, поэтому у меня действительно нет контроля над вводом.
Что Я need-это функция или класс, который гарантирует, что материал, поступающий в мою базу данных, насколько это возможно, кодируется UTF-8. Я пробовал iconv(mb_detect_encoding($text), "UTF-8", $text); но у этого есть проблемы (если вход "невеста", он возвращает "жених"). Я много чего перепробовал=/
для загрузки файлов мне нравится идея попросить конечного пользователя указать кодировку, которую они используют, и показать им предварительные просмотры того, как будет выглядеть вывод, но это не помогает против неприятных хакеров (на самом деле, это может сделать их жизнь немного облегчающий.)
Я читал другие вопросы SO по этому вопросу, но все они, похоже, имеют тонкие различия, такие как "мне нужно анализировать RSS-каналы" или "я очищаю данные с веб-сайтов" (или, действительно, "Вы не можете").
но должно же быть что-то, что хотя бы имеет хороший попробовать!
то, что вы просите, чрезвычайно трудно. Если возможно, лучше всего заставить пользователя указать кодировку. Предотвращение нападения не должно быть намного проще или сложнее таким образом.
однако, вы можете попробовать сделать это:
установка его в строгий может помочь вам получить лучший результат.
в Родине России у нас есть 4 популярных кодировки, поэтому ваш вопрос пользуется большим спросом здесь.
только по символьным кодам символов вы не можете обнаружить кодировку, потому что кодовые страницы пересекаются. Некоторые кодовые страницы на разных языках имеют даже полное пересечение. Итак,нам нужен другой подход.
единственный способ работы с неизвестными кодировками-это работа с вероятностями. Поэтому мы не хотим ответить на вопрос "Что такое кодировка текста?"мы пытаясь понять"какова наиболее вероятная кодировка этого текста?".
один парень здесь, в популярном российском технологическом блоге, изобрел этот подход:
построить диапазон вероятностей кодов символов в каждой кодировке, которую вы хотите поддерживать. Вы можете построить его, используя некоторые большие тексты на вашем языке (например, некоторые художественные произведения, использовать Шекспира для английского и Толстого для русского, lol ). Вы получите что-то вроде этого:
далее. Вы берете текст в неизвестной кодировке и для каждой кодировки в вашем "вероятностном словаре" вы ищете частоту каждого символа в неизвестном закодированном тексте. Сумма вероятностей символов. Кодирование с большим рейтингом, скорее всего, победитель. Лучшие результаты для больших текстов.
если вы заинтересованы, Я могу с удовольствием помочь вам с этой задачей. Мы можем значительно повысить точность, построив список вероятностей с двумя кодами.
кстати. mb_detect_encoding certanly не работает. Да, вообще. Пожалуйста, возьмите посмотрите исходный код mb_detect_encoding в "ext/mbstring/libmbfl/mbfl / mbfl_ident.с."
Вы, наверное, пробовали это, но почему бы просто не использовать функцию mb_convert_encoding? Он попытается автоматически определить набор символов предоставленного текста или вы можете передать ему список.
кроме того, я попытался запустить:
и результаты одинаковы для обоих. Как вы видите, что ваш текст усечен до "жениха"? это в БД или в браузере?
основная проблема для меня заключается в том, что я не знаю, какая кодировка источника любой строки будет - это может быть из текстового поля (использование полезно только в том случае, если пользователь действительно отправил форму), или это может быть из загруженного текстового файла, поэтому у меня действительно нет контроля над вводом.
Я не думаю, что это проблема. Приложение знает источник входных данных. Если это из формы, используйте кодировку UTF-8 в вашем случае. Эта работа. Просто проверьте данные при условии правильно закодирован (проверка). Имейте в виду, что не все базы данных поддерживают UTF-8 в полном диапазоне.
Если это файл, вы не сохраните его в кодировке UTF-8 в базе данных, но в двоичном виде. Когда вы снова выводите файл, также используйте двоичный вывод, тогда это полностью прозрачно.
ваша идея хороша тем, что пользователь может сказать кодировку, будь он/она может сказать в любом случае после загрузки файла, так как он двоичный.
поэтому я должен признать, что не вижу конкретный вопрос, который вы поднимаете с вашим вопросом. Но, возможно, вы можете добавить еще несколько деталей, в чем ваша проблема.
вы можете создать набор метрик, чтобы попытаться угадать, какая кодировка используется. Опять же, не идеально, но может поймать некоторые из промахов от mb_detect_encoding().
если вы готовы "взять это на консоль", я бы рекомендовал enca . В отличие от упрощенных mb_detect_encoding , он использует " смесь разбора, статистического анализа, угадывания и черной магии для определения их кодировок "(lol - см. на странице). Однако обычно необходимо передать язык входного файла, если вы хотите обнаружить такие кодировки для конкретной страны. (Однако, mb_detect_encoding по существу имеет то же требование, что и кодировка, которая должна появиться " справа поместите" в список передаваемых кодировок, чтобы он был обнаружен вообще.)
enca и пришел сюда: как найти кодировку файла в Unix через скрипт(ы)
- попытка определить кодировку: $encodings = ['UTF-8', 'ISO-8859-1', 'ASCII'];
- если кодировка не может быть обнаружена, throw new RuntimeException
- если вход UTF-8 , продолжай.
иначе, если это ISO-8859-1 или ASCII
A. попытка преобразования в UTF-8 (подождите, не закончено)
b. определите кодировку преобразованного значения
c. если сообщенный кодирование и преобразованное значение как UTF-8 , продолжай.
d. Else, throw new RuntimeException
cURL параметры по умолчанию:
Я пробовал что-то вроде этого. Это помогло мне. Если найдено на meta charset info, я конвертирую, иначе ничего не делаю.
У меня есть куча файлов, которые не в кодировке UTF-8, и я конвертирую сайт в кодировку UTF-8.
Я использую простой скрипт для файлов, которые хочу сохранить в utf-8, но файлы сохраняются в старой кодировке:
Как сохранить файлы в кодировке utf-8?
File_get_contents / file_put_contents не преобразует кодировку волшебным образом.
Вы должны явно преобразовать строку; например, с помощью iconv() или mb_convert_encoding() .
Или, альтернативно, с помощью потоковых фильтров PHP:
Добавить спецификацию: UTF-8
На помощь приходит Iconv.
В Unix / Linux в качестве альтернативы можно использовать простую команду оболочки для преобразования всех файлов из заданного каталога:
Также может быть запущен через PHP exec ().
Я получил эту строку от Cool
Если вы хотите использовать рекурсивное перекодирование и фильтровать по типу, попробуйте следующее:
У меня это работает. :)
Это очень полезный вопрос. Я думаю, что мое решение на Windows 10 PHP7 весьма полезно для людей, у которых еще есть проблемы с преобразованием UTF-8.
Вот мои шаги. Сценарий PHP, вызывающий следующую функцию, здесь с именем utfsave.php , должен сам иметь кодировку UTF-8, это можно легко сделать путем преобразования в UltraEdit.
В utfsave.php мы определяем функцию, вызывающую PHP fopen ($ filename, " wb "), т. Е. Она открывается как в режиме записи w, так и особенно с b в двоичном режим.
Исходный файл cp936gbktext.txt содержимое файла:
Запуск utf8save.php в Windows 10 PHP, созданные таким образом файлы utf8text.txt , utf8text2.txt будут автоматически сохранены в формате UTF-8.
При использовании этого метода символ спецификации не требуется. Решение BOM плохое, потому что оно вызывает проблемы, когда мы, например, получаем sql-файл для MySQL.
Стоит отметить, что мне не удалось заставить работать file_put_contents ($ filename, utf8_encode ($ mystring)); для этой цели.
Если вы не знаете кодировку исходного файла, вы можете перечислить кодировки с помощью PHP:
Это дает такой список:
Я собрал все вместе и получил простой способ конвертировать текстовые файлы ANSI в "UTF-8 No Mark":
Использование: filesToUTF8 ('C: / Temp /', 'C: / Temp / conv_files /', 'php, txt');
Кодировка текста – это схема нумерации символов, в которой каждому символу, цифре или знаку присвоено соответствующее число. Кодировку используют для сохранения и обработки текста на компьютере. Каждый раз при сохранении текста в файл он сохраняется с использованием определенной схемы кодирования, и при открытии этого файла необходимо использовать такую же схему, иначе восстановить исходный текст не получится. Самыми популярными кодировками для кириллицы сейчас являются UTF-8, Windows-1251 (CP1251, ANSI).
Для того чтобы программа смогла правильно открыть текстовый файл, иногда приходится вручную менять кодировку, перекодируя текст из одной схемы в другую. Например, не редко возникают проблемы с открытием файлов CSV, XML, SQL, TXT, PHP.
В этой небольшой статье мы расскажем о том, как изменить кодировку текстового файла на UTF-8, Windows-1251 или любую другую.
Блокнот Windows
Если вы используете операционную систему Windows 10 или Windows 11, то вы можете изменить кодировку текста с помощью стандартной программы Блокнот. Для этого нужно открыть текстовый файл с помощью Блокнота и воспользоваться меню « Файл – Сохранить как ».
В открывшемся окне нужно указать новое название для файла, выбрать подходящую кодировку и нажать на кнопку « Сохранить ».
К сожалению, для подобных задач программа Блокнот часто не подходит. С ее помощью нельзя открывать документы большого размера, и она не поддерживает многие кодировки. Например, с помощью Блокнота нельзя открыть текстовые файлы в DOS 866.
Notepad++
Notepad++ (скачать) является одним из наиболее продвинутых текстовых редакторов. Он обладает подсветкой синтаксиса языков программирования, позволяет выполнять поиск и замену по регулярным выражениям, отслеживать изменения в файлах, записывать и воспроизводить макросы, считать хеш-сумы и многое другое. Одной из основных функций Notepad++ является поддержка большого количества кодировок текста и возможность изменения кодировки текстового файла в UTF-8 или Windows 1251.
Для того чтобы изменить кодировку текста с помощью Notepad++ файл нужно открыть в данной программе. Если программа не смогла правильно определить схему кодирования текста, то это можно сделать вручную. Для этого нужно открыть меню « Кодировки – Кириллица » и выбрать нужный вариант.
После открытия текста можно изменить его кодировку. Для этого нужно открыть меню « Кодировки » и выбрать один из вариантов преобразования. Notepad++ позволяет изменить текущую кодировку текста на ANSI (Windows-1251), UTF-8, UTF-8 BOM, UTF-8 BE BOM, UTF-8 LE BOM.
После преобразования файл нужно сохранить с помощью меню « Файл – Сохранить » или комбинации клавиш Ctrl-S.
Akelpad
Akelpad (скачать) – достаточно старая программа для работы с текстовыми файлами, которая все еще актуальна и может быть полезной. Фактически Akelpad является более продвинутой версией стандартной программы Блокнот из Windows. С его помощью можно открывать текстовые файлы большого размера, которые не открываются в Блокноте, выполнять поиск и замену с использованием регулярных выражений и менять кодировку текста.
Для того чтобы изменить кодировку текста с помощью Akelpad файл нужно открыть в данной программе. Если после открытия файла текст не читается, то нужно воспользоваться меню « Файл – Открыть ».
В открывшемся окне нужно выделить текстовый файл, снять отметку « Автовыбор » и выбрать подходящую кодировку из списка. При этом в нижней части окна можно видеть, как будет отображаться текст.
Для того чтобы изменить текущую кодировку текста нужно воспользоваться меню « Файл – Сохранить как » и сохранить документ с указанием новой схемы кодирования.
В отличие от Notepad++, текстовый редактор Akelpad позволяет сохранить файл в практически любой кодировке. В частности, доступны Windows 1251, DOS 886, UTF-8 и многие другие.
Кодировки… Вопрос, вроде бы, банальный, но, если набрать в поиске фразу типа «что такое кодировка 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().'<br />';
echo 'This is the regular expression coding: '. mb_regex_encoding () . "<br />";
echo "Soon we shall create file. Вскоре мы создадим файл.<br />";
// Устанавливаем кодировку в программе на РНР как UTF-8:
mb_internal_encoding("UTF-8");
// Определяем кодировку программы на РНР по умолчанию:
echo "Custom coding: ". mb_internal_encoding().'<br />';
echo 'This is the regular expression coding: '. mb_regex_encoding () . "<br />";
// Пытаемся создать файл под названием new_file в корневом каталоге сайта:
$input = @fopen($_SERVER['DOCUMENT_ROOT'] . '/new_file.html', "a+") or die('Невозможно создать или открыть файл.');
echo "The file is created. Файл создан.<br />";
?>
Запускаем этот файл в 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. Файл создан.
Открыв созданный файл 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 , в данном случае не влияет на ее отображение браузером. На отображение русскоязычного текста влияет, в какой кодировке сохранена исходная страница. Причем, это имеет значение как для текста, который задан на самой странице (при помощи тега <p> ), так и сформирован при помощи 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 при кодировке виртуального сервера | |
| Windows-1251 | UTF-8 | |||
| - | ANSI as UTF (UTF-8 без BOM) | Нечитаемый | Нечитаемый | Читаемый |
| UTF-8 | Читаемый | Читаемый | Читаемый | |
| Windows-1251 | ANSI as UTF (UTF-8 без BOM) | Нечитаемый | Нечитаемый | Читаемый |
| UTF-8 | Читаемый | Читаемый | Читаемый | |
| UTF-8 | ANSI as UTF (UTF-8 без BOM) | Читаемый | Нечитаемый | Читаемый |
| UTF-8 | Читаемый | Читаемый | Читаемый | |
Вот почему кодировка сервера UTF-8 , в самом деле, видится более удобной, чем Windows-1251 – даже при использовании в операционной системе Windows (седьмой версии).
Как быть с русскоязычным текстом, формируемым на странице, отдаваемой сервером при помощи PHP?
Итак, если кодировкой сервера является UTF-8 – проблем меньше. Можно просто отдавать русскоязычный текст при помощи, например, команды echo. Если же кодировкой сервера является Windows-1251 , то, на самом деле, особенно страшного ничего нет: надо лишь кодировать русскоязычный текст, отдаваемый РНР серверу, который он, в свою очередь, отдает браузеру. Если текст присутствует или формируется в самом файле РНР, то для этой цели наиболее целесообразна команда типа
mb_convert_encoding('Русскоязычный текст', "Windows-1251", "utf-8" );
Однако, бывают случаи, когда русскоязычный текст считывается из файла, например, базы данных. И вот здесь зависит от того, как он закодирован. Например, если в файле – кодировка ANSI ( Windows-1251 ), то это означает, что перекодировать считываемый из него текст НЕ НАДО. Ибо он и так уже закодирован в нужной кодировке. Этот момент может привести, иной раз, к проблемам. Когда, к примеру, разные части баз данных записаны в разных кодировках (о чем свидетельствуют обсуждения на компьютерных форумах). Тем более, что повторное кодирование может привести к нечитаемости некоторых символов (в частности, кириллической буквы И) - даже при последующем обратном (тоже повторном!) перекодировании.
Читайте также: