UTF-8 BOM-problemen om op te letten in WordPress
Ik had al heel vroeg een probleem, namelijk dat na het installeren van een bepaalde plugin er een wit scherm verscheen na het klikken om te activeren. Ik heb nooit uitgevonden wat de reden is, en de vorige oplossing is dat als het geen Chinese tekens bevat, het bestand direct naar ASCII-code overzet, wat meestal opgelost kan worden. Toen ik vandaag een blog voor mijn broer aanlegde, gebeurde deze situatie weer. Na lang onderzoek vond ik uiteindelijk het antwoord.
Er is een concept van BOM in de Unicode-specificatie. BOM - Byte Order Mark, wat het byte order mark is. Vind hier een opmerking over de BOM:
In de UCS-code is er een teken genaamd "ZERO WIDTH NO-BREAK SPACE", dat wordt gecodeerd als FEFF. FFFE is een niet-bestaand personage in UCS, dus het zou niet in de daadwerkelijke uitzending moeten voorkomen. De UCS-specificatie raadt aan dat we het teken "ZERO WIDTH NO-BREAK SPACE" overbrengen voordat we de bytestroom verzenden. Op deze manier, als de ontvanger een FEFF ontvangt, geeft dit aan dat de bytestroom Big-Endiaans is; Als FFFE wordt ontvangen, geeft dit aan dat de bytestream Little-Endiaans is. Daarom wordt het teken "ZERO WIDTH NO-BREAK SPACE" ook BOM genoemd.
UTF-8 vereist geen stuklijst om de bytevolgorde aan te geven, maar kan wel een stuklijst gebruiken om aan te geven hoe het gecodeerd is. De UTF-8-codering van het teken "ZERO WIDTH NO-BREAK SPACE" is EF BB BF. Dus als de ontvanger een bytestroom ontvangt die begint met EF BB BF, weten ze dat het UTF-8-codering is.
Windows gebruikt de BOM om aan te geven hoe tekstbestanden worden gecodeerd.
Daarnaast legt de FAQ-BOM op de unicode-website de BOM in detail uit. De officiële natuurlijke autoriteit, maar in het Engels, lijkt meer arbeidsintensief te zijn.
In een UTF-8-gecodeerd bestand beslaat de BOM drie bytes. Als je Notepad gebruikt om een tekstbestand op te slaan als UTF-8-codering, open dan het bestand met UE en schakel over naar de hexadecimale bewerkingstoestand om de FFFE aan het begin te zien. Dit is een goede manier om UTF-8-gecodeerde bestanden te identificeren; software gebruikt de stuklijst om te bepalen of het bestand UTF-8-gecodeerd is, en veel software vereist ook dat het geïmporteerde bestand een stuklijst moet hebben. Er is echter nog steeds veel software die BOM niet herkent. Toen ik onderzoek deed naar Firefox, wist ik dat in vroege versies van Firefox extensies geen lijstlijst konden hebben, maar Firefox 1.5 en latere versies zijn begonnen met het ondersteunen van lijsten. Nu ontdekte ik dat PHP ook geen BOM ondersteunt.
PHP is ontworpen zonder rekening te houden met de BOM, wat betekent dat het de drie tekens van de BOM aan het begin van het UTF-8-gecodeerde bestand niet negeert. Omdat het in moet zijn
Zoals ik zag in de Bo-Blog wiki, heeft Bo-Blog, die ook PHP gebruikt, ook last van BOM. Er wordt een ander probleem genoemd: "Vanwege de beperking van het COOKIE-verzendmechanisme kunnen in de bestanden die al een BOM aan het begin van deze bestanden hebben, COOKIE's niet worden verzonden (omdat PHP de bestandsheader al heeft verzonden voordat de COOKIE wordt verzonden), dus zijn de inlog- en logoutfuncties ongeldig. Alle functies die afhankelijk zijn van COOKIEs en SESSIONs zijn ongeldig. Dit zou de reden moeten zijn voor de lege pagina op de WordPress-achtergrond, omdat alle uitgevoerde bestanden een BOM bevatten en alle drie de tekens worden verzonden, waardoor de functionaliteit die afhankelijk is van cookies en sessies faalt.
De oplossing is om het bestand als ASCII-code op te slaan als het alleen Engelse tekens bevat (of tekens in ASCII-codering). Als je een editor zoals UE gebruikt, klik dan op File->Convert->UTF-8 naar ASCII, of kies ASCII-codering in Save As. Als het een regel is die eindigt in DOS-formaat, kun je het openen met Notepad, op Opgeslagen als klikken en ASCII-codering selecteren. Als het Chinese karakters bevat, kun je de save as-functie van UE gebruiken en "UTF-8 no BOM" selecteren. Zie de onderstaande afbeelding:
Volgens de instructies van de Bo-Blog wiki: Editplus moet opgeslagen worden als gb en daarna als UTF-8. Wees echter voorzichtig bij dit gebruik, alle karakters die niet in de GBK-codering zijn opgenomen, gaan verloren. Als er niet-Chinese tekens in het bestand staan, gebruik deze methode dan niet. (Vanuit dit kleine perspectief is UE - UltraEdite-32 inderdaad veel beter dan Editplus, Editplus is te licht)
Een andere manier die ik heb gevonden is om de bestandseditor van WordPress te gebruiken. Deze methode is niet beperkt, en er is geen noodzaak om een speciale editor te downloaden, want iedereen gebruikt immers WordPress. Schakel eerst de schrijfrechten in van het bestand dat je wilt bewerken in FTP in, voer dan de WordPress-achtergrond in > beheer-> bestandseditor, voer het pad in om het bestand te bewerken en klik op Bestand bewerken. Je zult de eerste drie tekens niet kunnen zien in het bewerkingsscherm dat verschijnt, maar dat is prima, plaats je cursor vóór het eerste teken van het hele bestand en druk op de Backspace-toets. Oké, klik op Bestand bijwerken, ververs het in FTP, je ziet dat het bestand 3 bytes kleiner is, en je bent klaar.
Tot slot is dit een groot probleem; iedereen die zijn eigen plugins wil schrijven, andermans plugins wil aanpassen voor eigen gebruik, en de template moet aanpassen (dit wordt geschat als nodig door iedereen), is het het beste om bovenstaande kennis te begrijpen, zodat je niet overweldigd raakt als er een probleem is.
|
Geplaatst op 30-10-2014 17:38:44
|
|
|
