Problemas com LISTAS UTF-8 para ficar atento no WordPress
Encontrei um problema bem cedo, ou seja, após instalar um certo plugin, uma tela branca aparecia ao clicar para ativar. Nunca descobri qual é o motivo, e a solução anterior é que, se não contiver caracteres chineses, transferir o arquivo diretamente para código ASCII, o que geralmente pode ser resolvido. Quando ganhei um blog para meu irmão hoje, essa situação aconteceu de novo. Depois de pesquisar por muito tempo, finalmente encontrei a resposta.
Existe o conceito de BOM na especificação Unicode. BOM - Marca de Ordem de Bytes, que é a marca de ordem de bytes. Encontre uma nota sobre a lista de materiais aqui:
No código UCS há um caractere chamado "ZERO WIDTH NO-BREAK SPACE", que é codificado como FEFF. FFFE é um personagem inexistente no UCS, então não deveria aparecer na transmissão real. A especificação UCS recomenda que transfiramos o caractere "ZERO WIDTH NO-BREAK SPACE" antes de transmitir o fluxo de bytes. Dessa forma, se o receptor receber um FEFF, indica que o fluxo de bytes é Big-Endian; Se FFFE for recebido, indica que o fluxo de bytes é Little-Endian. Portanto, o caractere "ZERO WIDTH NO-BREAK SPACE" também é chamado de BOM.
O UTF-8 não requer uma lista de materiais para indicar a ordem dos bytes, mas pode usar uma lista de materiais para indicar como é codificado. A codificação UTF-8 do caractere "ZERO WIDTH NO-BREAK SPACE" é EF BB BF. Então, se o receptor recebe um fluxo de bytes que começa com EF BB BF, ele sabe que é codificação UTF-8.
O Windows usa a lista de materiais para marcar como os arquivos de texto são codificados.
Além disso, o FAQ-BOM no site unicode explica o LIVRO em detalhes. A autoridade natural oficial, mas em inglês, parece ser mais trabalhosa.
Em um arquivo codificado em UTF-8, a lista de materiais ocupa três bytes. Se você usar o Notepad para salvar um arquivo de texto como codificação UTF-8, abra o arquivo com UE e mude para o estado de edição hexadecimal para ver o FFFE no início. Essa é uma boa forma de identificar arquivos codificados em UTF-8, o software usa a lista de materiais para determinar se o arquivo é codificado em UTF-8, e muitos softwares também exigem que o arquivo importado tenha uma lista de materiais (BOM). No entanto, ainda há muitos softwares que não reconhecem a BOM. Quando eu pesquisava sobre o Firefox, sabia que nas versões iniciais do Firefox, extensões não podiam ter uma lista de bolas, mas o Firefox 1.5 e versões posteriores começaram a suportar a BOM. Agora descobri que o PHP também não suporta a lista de materiais (BOM).
O PHP foi projetado sem considerar a lista de materiais (BOM), o que significa que não ignora os três caracteres da LISTA no início do arquivo codificado em UTF-8. Já que deve estar em
Como vi na wiki do Bo-Blog, o Bo-Blog, que também usa PHP, também está preocupado com o BOM. Outro problema é mencionado: "Devido à limitação do mecanismo de envio de COOKIES, nos arquivos que já têm uma BOM no início desses arquivos, COOKIES não podem ser enviados (porque o PHP já enviou o cabeçalho do arquivo antes do COOKIE ser enviado), então as funções de login e logout são inválidas. Todas as funções que dependem de COOKIESs e SESSIONs são inválidas. Essa deve ser a razão da página em branco no fundo do WordPress, porque qualquer arquivo executado contém uma lista de materiais (BOM), e os três caracteres serão enviados, fazendo com que a funcionalidade que depende de cookies e sessões falhe.
A solução é salvar o arquivo como código ASCII se ele contiver apenas caracteres em inglês (ou caracteres na codificação ASCII). Se você estiver usando um editor como UE, clique em File->Convert->UTF-8 para ASCII, ou selecione codificação ASCII em Salvar Como. Se for uma linha terminando no formato DOS, você pode abri-la com o Notepad, clicar em Salvar Como e selecionar codificação ASCII. Se contiver caracteres chineses, você pode usar a função save as do UE e selecionar "UTF-8 no BOM". Por favor, consulte a imagem abaixo:
De acordo com as instruções da wiki do Bo-Blog: o Editplus precisa ser salvo como gb e depois como UTF-8. No entanto, tenha cuidado ao fazer isso, todos os caracteres que não forem incluídos na codificação GBK serão perdidos. Se houver alguns caracteres não chineses no arquivo, não use esse método. (A partir desse pequeno aspecto, UE - UltraEdite-32 é realmente muito melhor que Editplus, Editplus é muito leve)
Outra forma que encontrei foi usar o editor de arquivos fornecido pelo Wordpress. Esse método não é limitado, e não há necessidade de baixar um editor especial, afinal, todo mundo está usando Wordpress. Primeiro, ative a permissão de gravação do arquivo que você quer editar no ftp, depois entre no segundo plano do WordPress - > editor de arquivos gerencial->, insira o caminho para editar o arquivo e clique em Editar arquivo. Você não vai conseguir ver os três primeiros caracteres na tela de edição que aparece, mas tudo bem, posicione o cursor antes do primeiro caractere de todo o arquivo e pressione a tecla Backspace. Ok, clique em Atualizar Arquivo, atualize em ftp, você verá que o arquivo é 3 bytes menor e pronto.
Por fim, esse é um grande problema: todos que querem escrever seus próprios plugins, editar plugins de outras pessoas para uso próprio, e precisam modificar o template (isso é estimado como necessário para todos), é melhor entender o conhecimento acima, para não se sentirem sobrecarregados quando surgir um problema.
|
Publicado em 30/10/2014 17:38:44
|
|
|
