UTF-8 BOM-problemer å være oppmerksom på i Wordpress
Jeg støtte på et problem veldig tidlig, nemlig at etter installasjon av en bestemt plugin, dukket det opp en hvit skjerm etter å ha klikket for å aktivere. Jeg har aldri funnet ut hva årsaken er, og den forrige løsningen er at hvis det ikke inneholder kinesiske tegn, overføres filen direkte til ASCII-kode, noe som vanligvis kan løses. Da jeg fikk en blogg til broren min i dag, skjedde denne situasjonen igjen. Etter lang research fant jeg endelig svaret.
Det finnes et konsept som BOM i Unicode-spesifikasjonen. BOM - Byte Order, som er byte order. Finn en notis om BOM her:
I UCS-koden finnes det et tegn kalt "ZERO WIDTH NO-BREAK SPACE", som kodes som FEFF. FFFE er en ikke-eksisterende karakter i UCS, så den skal ikke vises i selve overføringen. UCS-spesifikasjonen anbefaler at vi overfører tegnet "ZERO WIDTH NO-BREAK SPACE" før bytestrømmen overføres. På denne måten, hvis mottakeren mottar en FEFF, indikerer det at bytestrømmen er Big-Endian; Hvis FFFE mottas, indikerer det at bytestrømmen er Little-Endian. Derfor kalles tegnet "ZERO WIDTH NO-BREAK SPACE" også BOM.
UTF-8 krever ikke en stykkliste for å angi byterekkefølgen, men kan bruke en stykkliste for å vise hvordan den kodes. UTF-8-kodingen av tegnet "ZERO WIDTH NO-BREAK SPACE" er EF BB BF. Så hvis mottakeren mottar en bytestrøm som starter med EF BB BF, vet de at det er UTF-8-koding.
Windows bruker BOM for å markere hvordan tekstfiler kodes.
I tillegg forklarer FAQ-BOM-en på unicode-nettsiden stykklisten i detalj. Den offisielle naturlige autoriteten, men på engelsk, virker mer arbeidskrevende.
I en UTF-8-kodet fil opptar BOM-en tre byte. Hvis du bruker Notisblokk for å lagre en tekstfil som UTF-8-koding, åpne filen med UE og bytt til heksadesimal redigeringstilstand for å se FFFE i starten. Dette er en god måte å identifisere UTF-8-kodede filer på, programvare bruker BOM for å avgjøre om filen er UTF-8-kodet, og mange programmer krever også at den importerte filen må ha en BOM. Likevel finnes det fortsatt mye programvare som ikke gjenkjenner stykkliste. Da jeg undersøkte Firefox, visste jeg at i tidlige versjoner av Firefox kunne ikke utvidelser ha en listeliste, men Firefox 1.5 og senere versjoner har begynt å støtte stykkliste. Nå har jeg funnet ut at PHP heller ikke støtter BOM.
PHP ble designet uten å ta hensyn til stykklisten, noe som betyr at den ikke ignorerer de tre tegnene i stykklisten i begynnelsen av den UTF-8-kodede filen. Siden den må være i
Som jeg så på Bo-Blog-wikien, er Bo-Blog, som også bruker PHP, også plaget av BOM. Et annet problem nevnes: "På grunn av begrensningen i COOKIE-sendemekanismen, kan ikke COOKIES sendes i filene som allerede har en BOM i starten av disse filene (fordi PHP allerede har sendt filhodet før COOKIE-en sendes), så innloggings- og utloggingsfunksjonene er ugyldige. Alle funksjoner som er avhengige av INFORMASJONSKAPSLER og SESJONER er ugyldige. Dette bør være grunnen til den tomme siden i WordPress-bakgrunnen, fordi alle de kjørte filene inneholder en stykkliste, og alle tre tegnene vil bli sendt ut, noe som fører til at funksjonaliteten som er avhengig av informasjonskapsler og økter feiler.
Løsningen er å lagre filen som ASCII-kode hvis den kun inneholder engelske tegn (eller tegn i ASCII-koding). Hvis du bruker en editor som UE, klikk på File->Convert->UTF-8 til ASCII, eller velg ASCII-koding i Save As (lagre som). Hvis det er en linje som ender i DOS-format, kan du åpne den med Notisblokk, klikke på Lagre som og velge ASCII-koding. Hvis det inneholder kinesiske tegn, kan du bruke UEs save as-funksjon og velge "UTF-8 no BOM". Se bildet nedenfor:
Ifølge instruksjonene i Bo-Blog-wikien: Editplus må lagres som gb og deretter som UTF-8. Men vær forsiktig når du gjør dette, alle tegn som ikke er inkludert i GBK-kodingen vil gå tapt. Hvis det er noen ikke-kinesiske tegn i filen, ikke bruk denne metoden. (Fra dette lille aspektet er UE - UltraEdite-32 faktisk mye bedre enn Editplus, Editplus er for lett)
En annen måte jeg har funnet på, er å bruke fileditoren som Wordpress tilbyr. Denne metoden er ikke begrenset, og det er ikke nødvendig å laste ned en spesiell editor, tross alt bruker alle Wordpress. Først, slå på skrivetillatelsen til filen du vil redigere i FTP, deretter skriv inn WordPress-bakgrunnen – > management-> fileditor, skriv inn stien for å redigere filen, og klikk på Rediger fil. Du vil ikke kunne se de tre første tegnene på redigeringsskjermen som vises, men det er greit, plasser markøren før det første tegnet i hele filen og trykk på tilbakestaste. OK, klikk på Oppdater fil, oppdater den i FTP, du kan se at filen er 3 byte mindre, og så er du ferdig.
Til slutt er dette et stort problem, for alle som ønsker å skrive sine egne plugins, redigere andres plugins for eget bruk, og trenger å endre malen (dette anslås å være nødvendig for alle), er det best å forstå ovennevnte kunnskap, slik at man ikke blir overveldet når det oppstår problemer.
|
Publisert på 30.10.2014 17:38:44
|
|
|
