Проблеми с 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, това означава, че байтовият поток е Little-Endian. Затова знакът "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 вече е изпратил заглавието на файла преди да бъде изпратено), затова функциите за вход и излизане са невалидни. Всички функции, които разчитат на БИСКВИТКИ и СЕСИИ, са невалидни. Това би трябвало да е причината за празната страница във WordPress фоновия режим, защото всеки от изпълнените файлове съдържа BOM и трите знака ще бъдат изпратени, което води до провал на функционалността, зависима от бисквитки и сесии.
Решението е да се запази файлът като ASCII код, ако съдържа само английски знаци (или знаци в ASCII кодирането). Ако използвате редактор като UE, кликнете на File->Convert->UTF-8 в ASCII или изберете ASCII кодиране в Save As. Ако е ред, завършващ в DOS формат, можеш да го отвориш с Notepad, да кликнеш Save As и да избереш ASCII кодиране. Ако съдържа китайски йероглифи, можеш да използваш функцията за запазване на UE и да избереш "UTF-8 no BOM". Моля, вижте изображението по-долу:
Според инструкциите на Bo-Blog wiki: Editplus трябва да се запази като gb, а след това като UTF-8. Въпреки това, бъдете внимателни при това, всички символи, които не са включени в GBK кодирането, ще бъдат загубени. Ако има някои некитайски йероглифи във файла, не използвайте този метод. (От този малък аспект, UE - UltraEdite-32 наистина е много по-добър от Editplus, Editplus е твърде лек)
Друг начин, който открих, е да използвам файловия редактор, предоставен от Wordpress. Този метод не е ограничен и няма нужда да изтегляте специален редактор, все пак всички използват WordPress. Първо включи разрешението за запис на файла, който искаш да редактираш във ftp, след това въведе WordPress background - > редактора на файлове >за управление, въведе пътя за редактиране на файла и кликни върху Редактиране на файла. Няма да можете да видите първите три знака на екрана за редактиране, който се появява, но това е напълно нормално – поставете курсора си преди първия символ от целия файл и натиснете бутона Backspace. Добре, кликни на Update File, обнови го във ftp, виждаш, че файлът е с 3 байта по-малък и си готов.
Накрая, това е голям проблем – всички, които искат да пишат свои собствени плъгини, да редактират чужди плъгини за собствена употреба и трябва да модифицират шаблона (което се смята за необходимост на всички), е най-добре да разберат горните знания, за да не се претоварват при проблем.
|
Публикувано в 30.10.2014 г. 17:38:44 ч.
|
|
|
