Data Uri O Data URI é uma solução definida pela RFC 2397 para incorporar pequenos arquivos diretamente nos documentos. Através da sintaxe a seguir, você pode transformar pequenos arquivos em codificações especificadas e incorporá -las diretamente na página:
Dados: [<MIMe-Type>] [; Base64], <Data>
- Tipo MIME: Especifica o MIME de dados incorporados. Sua forma é [tipo]/[subtipo]; Parâmetro, por exemplo, o MIME correspondente à imagem PNG é a imagem/PNG. O parâmetro pode usar informações adicionais para especificar os parâmetros do charset para texto/liso e texto/htm, etc. O padrão é text/plana; charset = US-ascii.
- Base64: Declare a codificação dos dados subsequentes é base64, caso contrário, os dados devem ser codificados com um número percentual (ou seja, urlencode o conteúdo).
No século passado, o HTML4.01 introduziu a solução de URI de dados. Até hoje, todos os navegadores convencionais, exceto o suporte IE6 e IE7, mas o IE8 ainda tem restrições sobre o suporte ao URI de dados, apenas suportando objeto (somente quando imagens), img, tipo de entrada = imagem, link e CSS, e o volume de dados não pode ser maior que 32k.
vantagem:- Reduza o número de solicitações HTTP, sem o limite no consumo de conexão TCP e o número de simultaneidade de navegadores com o mesmo nome de domínio.
- Para arquivos pequenos, a largura de banda será reduzida. Embora a quantidade de dados aumente após a codificação, o cabeçalho HTTP é reduzido. Quando a quantidade de dados do cabeçalho HTTP é maior que o incremento da codificação de arquivos, a largura de banda será reduzida.
- Para sites HTTPS, haverá avisos de segurança para misturar HTTPs e HTTP, e o HTTPS é mais caro que o HTTP, portanto, o Data Uri tem vantagens mais óbvias a esse respeito.
- Você pode salvar toda a página multimídia como um arquivo.
deficiência :
- Não pode ser reutilizado. Se o mesmo documento aplicar o mesmo conteúdo várias vezes, ele precisará ser repetido várias vezes e a quantidade de dados aumenta bastante, o que aumenta o tempo de download.
- Ele não pode ser armazenado em cache sozinho, por isso também precisa ser recarregado quando contém recarregamentos de documentos.
- O cliente precisa redecode e exibir, o que aumenta o consumo.
- A compactação de dados não é suportada, a codificação base64 aumentará em 1/3 do tamanho e a quantidade de dados aumentará mais após o urlencode.
- Não é propício à filtragem do software de segurança, mas também possui certos riscos de segurança.
Mhtml MHTML é a abreviação do MIME HTML (Extensão de Correio da Internet multiuso HTML), que é definido pelo RFC 2557 para salvar todo o conteúdo de uma página multimídia no mesmo documento. Esta solução foi proposta pela Microsoft para apoiá -la desde o IE5.0, e o Opera9.0 também começou a apoiá -la. O Safari pode salvar o arquivo no .mht (o sufixo do arquivo mhtml), mas não suporta exibi -lo.
O MHTML e o URI de dados são semelhantes, com funções mais poderosas e sintaxe mais complexa, e não têm as desvantagens que não podem ser reutilizadas no URI de dados, mas o MHTML não é flexível e conveniente o suficiente para usar. Por exemplo, a URL referenciada a um recurso pode ser um endereço relativo no arquivo MHT, caso contrário, deve ser um endereço absoluto. A solução de Hedger para o IE em "imagens codificadas do navegador cruzado64 incorporadas no HTML" usa caminhos relativos porque declara o tipo de conteúdo: message/rfc822 para fazer o IE Parse de acordo com o MHTML. Se o tipo de conteúdo não for modificado, o protocolo MHTML será necessário. Neste momento, os caminhos absolutos devem ser usados, como "MHTML - quando você precisa de dados: URIs no IE7 e abaixo".
aplicativo A combinação de dados URI e MHTML pode resolver completamente todos os navegadores convencionais. Devido aos defeitos de serem armazenados em cache e reutilização, eles não são adequados para uso diretamente nas páginas. No entanto, eles têm grandes vantagens no uso adequado de imagens em arquivos CSS e JavaScript:
- O número de solicitações foi bastante reduzido e o CSS de sites grandes agora faz referência a um grande número de recursos de imagem.
- Tanto o CSS quanto o JavaScript podem ser armazenados em cache, implementando indiretamente o cache de dados.
- O uso do CSS pode resolver o problema de reutilização do URI de dados
- Diga adeus ao CSS Sprites, o CSS Sprites pareceu reduzir o número de solicitações, mas além de trazer exceções em situações incertas, o CSS Sprites também requer a fusão de imagens artificiais. Mesmo se houver uma ferramenta de mesclagem, ela ainda precisa gastar artificialmente muito tempo em como efetivamente intrigantes e trazer dificuldades de manutenção. Depois de seguir determinados princípios de design, você pode abandonar completamente os sprites CSS para escrever CSS e, finalmente, usar ferramentas para converter imagens em Data URI e MHTML durante o upload para o servidor, como as ferramentas implementadas no Python em "Usando folhas de estilo de mesclagem de dados e imagens", que podem economizar muito tempo.
- A codificação BASE64 aumenta o arquivo de imagem em 1/3, e o uso de Data URI e MHTML ao mesmo tempo é equivalente a um aumento de 2/3. No entanto, o CSS e o JavaScript podem usar a compactação GZIP, que pode salvar 2/3 do volume de dados; portanto, o volume final de dados após o uso da compactação GZIP é (1 + 1/3) * 2 * (1/3) = 8/9, portanto o tráfego final é reduzido.
Para facilitar a implementação de Data URI e MHTML no CSS, escrevi um gerador de dados URI e MHTML, que você pode ver usando para gerar instâncias de aplicativos URI e MHTML de dados.
Ao usar o MHTML nos arquivos CSS, o URL deve usar um caminho absoluto, o que o torna muito inflexível. Portanto, você pode considerar o uso da expressão de CSS para resolver (demonstração), como:
/*
http://old9.blogsome.com/2008/10/26/css-expression-reloaded/
http://dancewithnet.com/2009/07/27/get-tight-url-from-html/
*/
*Imagem de fundo: expressão (função (ele) {
ele.style.backgroundImage = 'URL (MHTML:' +
Document.getElementById ('Data-URI-CSS'). GetAttribute ('HREF', 4) +
'! 03114501408821761.gif)';
}(esse));
