UTF-8 BOM-problemer at være opmærksom på i Wordpress
Jeg stødte på et problem meget tidligt, nemlig at efter installation af et bestemt plugin dukkede en hvid skærm op efter at have klikket for at aktivere. Jeg har aldrig fundet ud af, hvad grunden er, og den tidligere løsning er, at hvis den ikke indeholder kinesiske tegn, overføres filen direkte til ASCII-kode, hvilket generelt kan løses. Da jeg fik en blog til min bror i dag, skete denne situation igen. Efter lang research fandt jeg endelig svaret.
Der findes et begreb om BOM i Unicode-specifikationen. BOM - Byte Order Mark, som er byte order mark. Find en note om stykklisten her:
I UCS-koden findes der et tegn kaldet "ZERO WIDTH NO-BREAK SPACE", som er kodet som FEFF. FFFE er en ikke-eksisterende karakter i UCS, så den bør ikke optræde i selve transmissionen. UCS-specifikationen anbefaler, at vi overfører tegnet "ZERO WIDTH NO-BREAK SPACE" før bytestrømmen overføres. På denne måde, hvis modtageren modtager en FEFF, indikerer det, at bytestrømmen er Big-Endian; Hvis FFFE modtages, indikerer det, at bytestrømmen er Little-Endian. Derfor kaldes tegnet "ZERO WIDTH NO-BREAK SPACE" også BOM.
UTF-8 kræver ikke en BOM for at angive byteordenen, men den kan bruge en BOM til at angive, hvordan den kodes. UTF-8-kodningen af tegnet "ZERO WIDTH NO-BREAK SPACE" er EF BB BF. Så hvis modtageren modtager en bytestrøm, der starter med EF BB BF, ved de, at det er UTF-8-kodning.
Windows bruger BOM til at markere, hvordan tekstfiler kodes.
Derudover forklarer FAQ-stykklisten på unicode-hjemmesiden stykklisten i detaljer. Den officielle naturlige autoritet, men på engelsk, synes at være mere arbejdsom.
I en UTF-8-kodet fil optager BOM'en tre bytes. Hvis du bruger Notepad til at gemme en tekstfil som UTF-8-kodning, åbn filen med UE og skift til hexadecimal redigeringstilstand for at se FFFE i starten. Dette er en god måde at identificere UTF-8-kodede filer på, software bruger stykklisten til at afgøre, om filen er UTF-8-kodet, og mange programmer kræver også, at den importerede fil skal have en stuklist. Der er dog stadig meget software, der ikke genkender BOM. Da jeg undersøgte Firefox, vidste jeg, at i de tidlige versioner af Firefox kunne udvidelser ikke have en stukliste, men Firefox 1.5 og senere versioner er begyndt at understøtte stukliste. Nu har jeg fundet ud af, at PHP heller ikke understøtter stukliste.
PHP blev designet uden at tage højde for stykkladen, hvilket betyder, at den ikke ignorerer de tre tegn i stykklisten i begyndelsen af den UTF-8-kodede fil. Da det skal være i
Som jeg så på Bo-Blog wikien, er Bo-Blog, som også bruger PHP, også plaget af BOM. Et andet problem nævnes: "På grund af begrænsningen i COOKIE-afsendelsesmekanismen kan COOKIES ikke sendes i filer, der allerede har en BOM i starten af disse filer (fordi PHP allerede har sendt filheaderen, før COOKIE'en sendes), så login- og logout-funktionerne er ugyldige. Alle funktioner, der er afhængige af COOKIES og SESSIONs, er ugyldige. Dette burde være grunden til den tomme side i WordPress-baggrunden, fordi alle de udførte filer indeholder en stukliste, og alle tre tegn vil blive sendt ud, hvilket får funktionaliteten, der er afhængig af cookies og sessioner, til at fejle.
Løsningen er at gemme filen som ASCII-kode, hvis den kun indeholder engelske tegn (eller tegn i ASCII-kodning). Hvis du bruger en editor som UE, klik på File->Convert->UTF-8 til ASCII, eller vælg ASCII-kodning i Save As. Hvis det er en linjeafslutning i DOS-format, kan du åbne den med Notepad, klikke på Gem som og vælge ASCII-kodning. Hvis den indeholder kinesiske tegn, kan du bruge UE's gem som-funktion og vælge "UTF-8 no BOM". Se venligst billedet nedenfor:
Ifølge instruktionerne i Bo-Blog wiki: Editplus skal gemmes som gb og derefter som UTF-8. Vær dog forsigtig, når du gør dette, for alle tegn, der ikke er inkluderet i GBK-kodningen, vil gå tabt. Hvis der er nogle ikke-kinesiske tegn i filen, så brug ikke denne metode. (Set fra dette lille perspektiv er UE - UltraEdite-32 faktisk meget bedre end Editplus, Editplus er for letvægts)
En anden måde, jeg har fundet på, er at bruge fileditoren, som WordPress stiller til rådighed. Denne metode er ikke begrænset, og der er ikke behov for at downloade en særlig editor, trods alt bruger alle Wordpress. Først aktiverer du skrivetilladelsen for den fil, du vil redigere i ftp, indtast derefter WordPress-baggrunden – > management-> fileditor, indtast stien for at redigere filen og klik på Rediger fil. Du vil ikke kunne se de første tre tegn på redigeringsskærmen, der vises, men det er okay, placer din markør før det første tegn i hele filen og tryk på Backspace-tasten. OK, klik på Opdater fil, opdater den i ftp, du kan se, at filen er 3 bytes mindre, og så er du færdig.
Endelig er dette et stort problem; alle dem, der ønsker at skrive deres egne plugins, redigere andres plugins til eget brug og har brug for at ændre skabelonen (det forventes at være nødvendigt for alle), er det bedst at forstå ovenstående viden, så man ikke bliver overvældet, når der opstår et problem.
|
Opslået på 30/10/2014 17.38.44
|
|
|
