Probleme legate de BOM UTF-8 de urmărit în Wordpress
Am întâmpinat o problemă foarte devreme, adică după instalarea unui anumit plugin, apărea un ecran alb după ce apăsam pentru activare. Nu am reușit niciodată să înțeleg care este motivul, iar soluția anterioară este că, dacă nu conține caractere chinezești, transferul direct al fișierului în cod ASCII, ceea ce în general poate fi rezolvat. Când am primit astăzi un blog pentru fratele meu, s-a întâmplat din nou această situație. După ce am cercetat mult timp, în cele din urmă am găsit răspunsul.
Există un concept de BOM în specificația Unicode. BOM - Byte Order Mark, care este marcajul ordinii byte. Găsiți o notă despre BOM aici:
În codul UCS există un caracter numit "ZERO WIDTH NO-BREAK SPACE", care este codificat ca FEFF. FFFE este un personaj inexistent în UCS, deci nu ar trebui să apară în transmisia propriu-zisă. Specificația UCS recomandă să transferăm caracterul "ZERO WIDTH NO-BREAK SPACE" înainte de a transmite fluxul de octeți. Astfel, dacă receptorul primește un FEFF, indică faptul că fluxul de octeți este Big-Endian; Dacă FFFE este recepționat, indică faptul că fluxul de octeți este Little-Endian. Prin urmare, caracterul "ZERO WIDTH NO-BREAK SPACE" este numit și BOM.
UTF-8 nu necesită un BOM pentru a indica ordinea octeților, dar poate folosi un BOM pentru a indica modul în care este codificat. Codarea UTF-8 a caracterului "ZERO WIDTH NO-BREAK SPACE" este EF BB BF. Deci, dacă receptorul primește un flux de octeți care începe cu EF BB BF, știe că este codare UTF-8.
Windows folosește BOM-ul pentru a marca modul în care sunt codificate fișierele text.
În plus, FAQ-BOM de pe site-ul unicode explică BOM în detaliu. Autoritatea naturală oficială, dar în engleză, pare să fie mai laborioasă.
Într-un fișier codificat UTF-8, BOM-ul ocupă trei octeți. Dacă folosești Notepad pentru a salva un fișier text ca codare UTF-8, deschide fișierul cu UE și treci la starea de editare hexazecimală pentru a vedea FFFE la început. Aceasta este o metodă bună de a identifica fișierele codificate UTF-8, software-ul folosește BOM-ul pentru a identifica dacă fișierul este codificat UTF-8, iar multe programe cer, de asemenea, ca fișierul importat să aibă un BOM. Totuși, există încă multe programe care nu recunosc BOM-urile. Când am cercetat Firefox, știam că în versiunile timpurii ale Firefox extensiile nu puteau avea o carte de bază, dar Firefox 1.5 și versiunile ulterioare au început să suporte BOM. Acum am aflat că nici PHP nu suportă BOM.
PHP a fost proiectat fără a lua în considerare BOM-ul, ceea ce înseamnă că nu ignoră cele trei caractere ale BOM-ului de la începutul fișierului codificat UTF-8. Deoarece trebuie să fie în
Așa cum am văzut în wiki-ul Bo-Blog, Bo-Blog, care folosește și PHP, este de asemenea îngrijorat de BOM. O altă problemă este menționată: "Din cauza limitării mecanismului de trimitare a COOKIE-urilor, în fișierele care au deja un BOM la începutul acestor fișiere, COOKIE-urile nu pot fi trimise (deoarece PHP a trimis deja antetul fișierului înainte ca COOKIE să fie trimis), astfel că funcțiile de autentificare și delogare sunt invalide. Toate funcțiile care se bazează pe COOKIE-uri și SESSION-uri sunt invalide. Acesta ar trebui să fie motivul pentru care pagina goală este în fundalul WordPress, deoarece oricare dintre fișierele executate conține un BOM, iar toate cele trei caractere vor fi trimise, ceea ce va face ca funcționalitatea care depinde de cookie-uri și sesiuni să eșueze.
Soluția este să salvezi fișierul ca cod ASCII dacă conține doar caractere în engleză (sau caractere în codarea ASCII). Dacă folosești un editor precum UE, apasă pe File->Convert->UTF-8 în ASCII sau selectează codarea ASCII în Save As. Dacă este o linie care se termină în format DOS, o poți deschide cu Notepad, să dai click pe Salvează ca și să selectezi codare ASCII. Dacă conține caractere chinezești, poți folosi funcția save as a UE și selecta "UTF-8 no BOM". Vă rugăm să consultați imaginea de mai jos:
Conform instrucțiunilor wiki-ului Bo-Blog: Editplus trebuie salvat ca gb și apoi ca UTF-8. Totuși, fii atent când faci acest lucru, toate caracterele care nu sunt incluse în codarea GBK vor fi pierdute. Dacă există caractere non-chinezești în fișier, nu folosiți această metodă. (Din acest aspect mic, UE - UltraEdite-32 este într-adevăr mult mai bun decât Editplus, Editplus este prea ușor)
O altă metodă pe care am găsit-o este să folosesc editorul de fișiere oferit de Wordpress. Această metodă nu este limitată și nu este nevoie să descarci un editor special, până la urmă, toată lumea folosește Wordpress. Mai întâi, activează permisiunea de scriere a fișierului pe care vrei să-l editezi în ftp, apoi intră în fundalul WordPress - > editorul de fișiere management->, introduci calea pentru editarea fișierului și apasă pe Editează fișierul. Nu vei putea vedea primele trei caractere din ecranul de editare care apar, dar e în regulă, poziționează cursorul înaintea primului caracter din întregul fișier și apasă tasta Backspace. OK, apasă pe Update File, reîmprospătează-l în ftp, poți vedea că fișierul este cu 3 octeți mai mic și ai terminat.
În cele din urmă, aceasta este o problemă mare, toți cei care doresc să-și scrie propriile pluginuri, să editeze pluginurile altora pentru uz propriu și trebuie să modifice șablonul (se estimează că este necesar pentru toată lumea), cel mai bine este să înțeleagă cunoștințele de mai sus, pentru a nu fi copleșiți când apare o problemă.
|
Postat pe 30.10.2014 17:38:44
|
|
|
