Проблемы UTF-8 BOM, на которые стоит обратить внимание в WordPress
Я столкнулся с проблемой очень рано: после установки определённого плагина появлялся белый экран после нажатия для активации. Я так и не понял, в чём причина, и предыдущее решение — если в нем нет китайских иероглифов, файл напрямую переносится в ASCII-код, что обычно можно решить. Когда сегодня я завёл блог для брата, эта ситуация повторилась. После долгих исследований я наконец нашёл ответ.
В спецификации Unicode есть понятие BOM. BOM — метка порядка байтов, которая является меткой порядка байтов. Примечание о BOM можно найти здесь:
В коде UCS есть символ под названием «ZERO WIDTH NO-BREAK SPACE», который кодируется как FEFF. FFFE — это несуществующий персонаж в UCS, поэтому он не должен появляться в самой передаче. Спецификация UCS рекомендует передать символ «ZERO WIDTH NO-BREAK SPACE» перед передачей потока байтов. Таким образом, если приёмник получает FEFF, это указывает, что поток байтов является Big-Endian; Если получен FFFE, это указывает, что байтстрим является Литтл-Эндиан. Поэтому символ «ZERO WIDTH NO-BREAK SPACE» также называется BOM.
UTF-8 не требует BOM для обозначения порядка байтов, но может использовать BOM для обозначения способа кодирования. UTF-8 кодировка символа «ZERO WIDTH NO-BREAK SPACE» — EF BB BF. Если получатель получает поток байтов, начинающийся с EF BB BF, он знает, что это кодировка UTF-8.
Windows использует BOM для обозначения, как кодируются текстовые файлы.
Кроме того, FAQ-BOM на сайте Unicode подробно объясняет BOM. Официальная естественная власть, но на английском, кажется более трудоёмкой.
В файле, закодированном UTF-8, BOM занимает три байта. Если вы используете Notepad для сохранения текстового файла как кодировку UTF-8, откройте файл через UE и переключитесь на состояние шестнадцатеричного редактирования, чтобы увидеть FFFE в начале. Это хороший способ идентифицировать файлы, закодированные в UTF-8, программное обеспечение использует BOM для определения того, закодирован ли файл UTF-8, а многие программы также требуют, чтобы импортированный файл имел BOM. Однако всё ещё существует множество программ, которые не распознают BOM. Когда я изучал Firefox, я знал, что в ранних версиях Firefox расширения не могли иметь BOM, но Firefox 1.5 и более поздние версии начали поддерживать BOM. Теперь я узнал, что PHP тоже не поддерживает BOM.
PHP был разработан без учёта BOM, что означает, что он не игнорирует три символа BOM в начале закодированного файла UTF-8. Поскольку он должен быть в
Как я видел в вики Bo-Blog, Bo-Blog, который тоже использует PHP, тоже сталкивается с проблемами BOM. Упоминается ещё одна проблема: «Из-за ограничений механизма отправки COOKIE в файлах, у которых уже есть BOM в начале этих файлов, COOKIE нельзя отправлять (потому что PHP уже отправил заголовок файла до отправки COOKIE), поэтому функции входа и выхода из игры недействительны. Все функции, зависящие от COOKIE и SESSION, недействительны. Это должно быть причиной пустой страницы в фоне WordPress, потому что любой из запущенных файлов содержит BOM, и все три символа будут отправлены, что приведёт к сбою функциональности, зависящей от cookie и сессий.
Решение — сохранить файл как ASCII-код, если он содержит только английские символы (или символы в ASCII-кодировании). Если вы используете редактор, например UE, нажмите File->Convert->UTF-8 в ASCII или выберите ASCII-кодирование в разделе Сохранить как. Если это строка, заканчивающаяся в формате DOS, вы можете открыть её в блокноте, нажать «Сохранить как» и выбрать ASCII-кодирование. Если там есть китайские иероглифы, можно использовать функцию сохранения UE и выбрать «UTF-8 no BOM». Пожалуйста, обратитесь к изображению ниже:
Согласно инструкции вики Bo-Blog: Editplus нужно сохранять как gb, а затем как UTF-8. Однако будьте осторожны при этом, все символы, не входящие в кодировку GBK, будут потеряны. Если в файле есть некитайские иероглифы, не используйте этот метод. (С точки зрения этого небольшого аспекта, UE - UltraEdite-32 действительно намного лучше Editplus, Editplus слишком лёгкий)
Ещё один способ, который я нашёл — использовать файловый редактор, предоставленный Wordpress. Этот метод не ограничен, и нет необходимости скачивать специальный редактор — ведь все пользуются WordPress. Сначала включите разрешение на запись файла, который хотите редактировать в FTP, затем введите фон WordPress — > редактор файлов >управления, введите путь для редактирования файла и нажмите Редактировать файл. Вы не сможете увидеть первые три символа на экране редактирования, но это нормально — поставьте курсор перед первым символом всего файла и нажмите клавишу Backspace. Хорошо, нажмите «Обновить файл», обновите его в FTP, вы увидите, что файл на 3 байта меньше, и всё готово.
Наконец, это большая проблема: всем, кто хочет писать собственные плагины, редактировать чужие плагины для собственного использования и нуждается в модифицировании шаблона (что, по оценкам, потребуется всем), лучше понять вышеуказанные знания, чтобы не перегружаться при возникновении проблемы.
|
Опубликовано 30.10.2014 17:38:44
|
|
|
