UTF-8 BOM-problem att hålla koll på i Wordpress
Jag stötte på ett problem väldigt tidigt, nämligen att efter installation av ett visst plugin dök en vit skärm upp efter att ha klickat för att aktivera. Jag har aldrig listat ut orsaken, och den tidigare lösningen är att om det inte innehåller kinesiska tecken, överför filen direkt till ASCII-kod, vilket i allmänhet kan lösas. När jag skaffade en blogg till min bror idag hände den här situationen igen. Efter lång research hittade jag äntligen svaret.
Det finns ett begrepp om BOM i Unicode-specifikationen. BOM - Byte Order Mark, vilket är byteordermarken. Hitta en anmärkning om BOM här:
I UCS-koden finns ett tecken som kallas "ZERO WIDTH NO-BREAK SPACE", som är kodat som FEFF. FFFE är en icke-existerande karaktär i UCS, så den borde inte förekomma i själva överföringen. UCS-specifikationen rekommenderar att vi överför tecknet "ZERO WIDTH NO-BREAK SPACE" innan byteströmmen överförs. På så sätt, om mottagaren får en FEFF, indikerar det att byteströmmen är Big-Endian; Om FFFE tas emot indikerar det att byteströmmen är Little-Endian. Därför kallas tecknet "ZERO WIDTH NO-BREAK SPACE" också för BOM.
UTF-8 kräver inte en styckliste för att ange byteordningen, men den kan använda en stykkliste för att visa hur den är kodad. UTF-8-kodningen av tecknet "ZERO WIDTH NO-BREAK SPACE" är EF BB BF. Så om mottagaren får en byteström som börjar med EF BB BF, vet de att det är UTF-8-kodning.
Windows använder stycklisten för att markera hur textfiler är kodade.
Dessutom förklarar FAQ-BOM på unicode-webbplatsen BOM:en i detalj. Den officiella naturliga auktoriteten, men på engelska, verkar vara mer arbetsam.
I en UTF-8-kodad fil upptar BOM tre byte. Om du använder Anteckningsbok för att spara en textfil som UTF-8-kodning, öppna filen med UE och byt till hexadecimalt redigeringsläge för att se FFFE i början. Detta är ett bra sätt att identifiera UTF-8-kodade filer, mjukvara använder stycklistan för att avgöra om filen är UTF-8-kodad, och många program kräver också att den importerade filen måste ha en stykkara. Det finns dock fortfarande mycket programvara som inte känner igen stycklistor. När jag undersökte Firefox visste jag att i tidiga versioner av Firefox kunde tillägg inte ha en BOM, men Firefox 1.5 och senare versioner har börjat stödja BOM. Nu har jag upptäckt att PHP inte heller stödjer BOM.
PHP designades utan att ta hänsyn till BOM, vilket innebär att det inte ignorerar de tre tecknen i BOM:en i början av den UTF-8-kodade filen. Eftersom den måste vara i
Som jag såg i Bo-Blog-wikin är Bo-Blog, som också använder PHP, också besvärad av BOM. Ett annat problem nämns: "På grund av begränsningen i COOKIE-sändningsmekanismen, i filer som redan har en BOM i början av dessa filer, kan inte COOKIES skickas (eftersom PHP redan har skickat filhuvudet innan COOKIEN skickas), så inloggnings- och utloggningsfunktionerna är ogiltiga. Alla funktioner som förlitar sig på COOKIES och SESSIONs är ogiltiga. Detta borde vara anledningen till den tomma sidan i WordPress-bakgrunden, eftersom alla körda filer innehåller en styckliste, och alla tre tecken skickas ut, vilket gör att funktionaliteten som är beroende av cookies och sessioner misslyckas.
Lösningen är att spara filen som ASCII-kod om den endast innehåller engelska tecken (eller tecken i ASCII-kodning). Om du använder en redigerare som UE, klicka på File->Convert->UTF-8 till ASCII, eller välj ASCII-kodning i Save As. Om det är en radslut i DOS-format kan du öppna den med Notepad, klicka på Spara som och välja ASCII-kodning. Om den innehåller kinesiska tecken kan du använda UE:s sparfunktion och välja "UTF-8 no BOM". Se bilden nedan:
Enligt instruktionerna i Bo-Blog-wikin: Editplus måste sparas som gb och sedan som UTF-8. Var dock försiktig när du gör detta, alla tecken som inte ingår i GBK-kodningen kommer att gå förlorade. Om det finns några icke-kinesiska tecken i filen, använd inte denna metod. (Ur denna lilla aspekt är UE - UltraEdite-32 faktiskt mycket bättre än Editplus, Editplus är för lätt)
Ett annat sätt jag hittade är att använda filredigeraren som Wordpress tillhandahåller. Denna metod är inte begränsad, och det finns inget behov av att ladda ner en speciell redigerare, alla använder ju trots allt Wordpress. Slå först på skrivbehörigheten för filen du vill redigera i ftp, ange sedan WordPress-bakgrunden > hanterings- > filredigerare, ange sökvägen för att redigera filen och klicka på Redigera fil. Du kommer inte kunna se de tre första tecknen i redigeringsskärmen som visas, men det är okej, placera markören före första tecknet i hela filen och tryck på Backspace-knappen. Okej, klicka på Uppdatera fil, uppdatera den i ftp, du kan se att filen är 3 byte mindre, och du är klar.
Slutligen är detta ett stort problem, alla som vill skriva egna plugins, redigera andras plugins för eget bruk och behöver ändra mallen (detta uppskattas vara nödvändigt för alla), det är bäst att förstå ovanstående kunskap för att inte bli överväldigad när det uppstår problem.
|
Publicerad på 2014-10-30 17:38:44
|
|
|
