Um problema que nunca foi resolvido durante o desenvolvimento é que a página usa codificação UTF8, e o cabeçalho e o final usam o método de inclusão de arquivos de modelo. Como resultado, há uma linha extra em branco de cerca de 10px no cabeçalho e no final sem qualquer. razão, e não há nada.
A razão é que todos eles são codificados em utf8. Ao incluir arquivos, o fluxo binário final contém várias tags UTF8 BOM. O IE não pode analisar páginas contendo várias tags UTF8 BOM normalmente e as substitui diretamente pelos retornos de carro reais exibidos. Linhas em branco, mas o Firefox não tem esse problema.
Portanto, se o modelo usa o método de inclusão para conter vários arquivos utf8 e precisa ser salvo com ultraedit, basta selecionar utf8 sem formato BOM ao salvar como função.
Além disso, se a página chinesa colocar a tag de título na frente de <meta http-equiv=”content-type” content=”text/html; em branco.
Portanto, as páginas utf8 devem usar a ordem padrão
<meta http-equiv=”content-type” content=”text/html charset=UTF-8″ />;
<meta http-equiv=”linguagem de conteúdo” content=”zh-CN” />
<meta name=”robôs” content=”index,follow” />
<meta nome=”palavras-chave” conteúdo=”” />
<meta nome=”descrição” conteúdo=”” />
<meta name=”classificação” content=”geral” />
<meta nome=”autor” conteúdo=”” />
<meta nome=”copyright” conteúdo=”” />
<meta nome=”gerador” conteúdo=”” />
<title></title>
Cabeçalho da BOM: xEFxBBxBF PHP4 e 5 ainda ignoram a BOM, então eles são gerados diretamente antes da análise.
Há uma descrição especial deste problema no FAQ padrão do w3.org:
http://www.w3.org/International/questions/qa-utf8-bom
Os detalhes são os seguintes:
Na codificação UCS, há um código chamado de caractere "ZERO WIDTH NO" -BREAK SPACE", sua codificação é FEFF. FFFE é um personagem que não existe no UCS, portanto não deve aparecer na transmissão real. A especificação UCS recomenda que transmitamos os caracteres "ZERO WIDTH NO-BREAK SPACE" antes de transmitir o fluxo de bytes. Desta forma, se o receptor receber FEFF, indica que o fluxo de bytes é Big-Endian; se receber FFFE, indica que o fluxo de bytes é Little-Endian; Portanto, o caractere “ZERO WIDTH NO-BREAK SPACE” também é chamado de BOM.
UTF-8 não requer uma BOM para indicar a ordem dos bytes, mas pode usar a BOM para indicar o método de codificação. A codificação UTF-8 do caractere "ZERO WIDTH NO-BREAK SPACE" é EF BB BF. Portanto, se o receptor receber um fluxo de bytes começando com EF BB BF, ele saberá que está codificado em UTF-8.
Windows é um sistema operacional que usa BOM para marcar o método de codificação de arquivos de texto: WindowsXP Professional, conjunto de caracteres padrão: chinês
1) bloco de notas: pode identificar automaticamente arquivos no formato de codificação UTF-8 sem BOM, mas não pode controlar ao salvar arquivos. adicionar BOM Se o arquivo for salvo, o BOM será adicionado uniformemente.
2)
editplus: não pode reconhecer automaticamente arquivos no formato de codificação UTF-8 sem BOM Ao salvar o arquivo, selecione o formato UTF-8 e não gravará o cabeçalho BOM no cabeçalho do arquivo.
identificar automaticamente arquivos UTF-8 com BOM e sem BOM (pode ser configurado ao salvar, você pode escolher se deseja adicionar BOM através da configuração
(Observação especial é que ao salvar um arquivo recém-criado, você precisa optar por salvar como UTF)
.-8 sem formato bom)
Mais tarde descobri que o Notepad ++ também tem melhor suporte para utf-8 bom e recomendo a todos que o usem.