Data URI Data URI is a solution defined by RFC 2397 to embed small files directly into documents. Through the following syntax, you can turn small files into specified encodings and directly embed them into the page:
data:[<MIME-type>][;base64],<data>
- MIME-type: Specifies the MIME of embedded data. Its form is [type]/[subtype]; parameter, for example, the MIME corresponding to the png image is image/png. The parameter can use additional information to specify the charset parameters for text/plain and text/htm, etc. The default is text/plain;charset=US-ASCII.
- base64: Declare the encoding of the subsequent data is base64, otherwise the data must be encoded with a percentage number (that is, urlencode the content).
In the last century, HTML4.01 introduced the Data URI solution. To this day, all mainstream browsers except IE6 and IE7 support, but IE8 still has restrictions on the support of Data URI, only supporting object (only when images), img, input type=image, link and CSS, and the data volume cannot be greater than 32K.
advantage:- Reduce the number of HTTP requests, without the limit on TCP connection consumption and the concurrency number of browsers under the same domain name.
- For small files, the bandwidth will be reduced. Although the amount of data will increase after encoding, the http header is reduced. When the amount of data of the http header is greater than the increment of file encoding, the bandwidth will be reduced.
- For HTTPS sites, there will be security prompts for mixing HTTPS and HTTP, and HTTPS is more expensive than HTTP, so Data URI has more obvious advantages in this regard.
- You can save the entire multimedia page as a file.
shortcoming :
- It cannot be reused. If the same document applies the same content multiple times, it needs to be repeated multiple times, and the amount of data increases greatly, which increases the download time.
- It cannot be cached alone, so it also needs to be reloaded when its contains document reloads.
- The client needs to redecode and display, which increases the consumption.
- Data compression is not supported, base64 encoding will increase by 1/3 of the size, and the amount of data will increase more after urlencode.
- It is not conducive to the filtering of security software, but also has certain security risks.
MHTML MHTML is the abbreviation of MIME HTML (Multipurpose Internet Mail Extension HTML), which is defined by RFC 2557 to save all contents of a multimedia page to the same document. This solution was proposed by Microsoft to support it since IE5.0, and Opera9.0 also started to support it. Safari can save the file in .mht (the suffix of MHTML file), but does not support displaying it.
MHTML and Data URI are similar, with more powerful functions and more complex syntax, and do not have the disadvantages that cannot be reused in Data URI, but MHTML is not flexible and convenient enough to use. For example, the URL referenced to a resource can be a relative address in the mht file, otherwise it must be an absolute address. Hedger's solution for IE in "Cross Browser Base64 Encoded Images Embedded in HTML" uses relative paths because it declares Content-type:message/rfc822 to make IE parse according to MHTML. If the Content-type is not modified, the MHTML protocol is required. At this time, absolute paths must be used, such as "MHTML - when you need data: URIs in IE7 and under".
application The combination of Data URI and MHTML can completely solve all mainstream browsers. Due to the defects of being cached and reused, they are not suitable for use in pages directly. However, they have great advantages in appropriate use of images in CSS and JavaScript files:
- The number of requests has been greatly reduced, and the CSS of large websites now references a large number of image resources.
- Both CSS and JavaScript can be cached, indirectly implementing data caching.
- Using CSS can solve the reuse problem of Data URI
- Say goodbye to CSS Sprites, CSS Sprites appeared to reduce the number of requests, but in addition to bringing exceptions in uncertain situations, CSS Sprites also requires artificial image merging. Even if there is a merge tool, it still has to artificially spend a lot of time on how to effectively puzzles and bring maintenance difficulties. After you follow certain design principles, you can completely abandon CSS Sprites to write CSS, and finally use tools to convert images into Data URI and MHTML during uploading to the server, such as the tools implemented in Python in "Using Data-uri Merge Style Sheets and Pictures", which can save a lot of time.
- Base64 encoding increases the image file by 1/3, and the use of Data URI and MHTML at the same time is equivalent to an increase of 2/3. However, CSS and JavaScript can use gzip compression, which can save 2/3 of the data volume, so the final data volume after using gzip compression is (1 + 1/3) * 2 * (1/3) = 8/9, so the final traffic is reduced.
To facilitate implementation of Data URI and MHTML in CSS, I wrote a Data URI & MHTML generator, which you can see using to generate Data URI & MHTML application instances.
When using MHTML in CSS files, the URL must use an absolute path, which makes it very inflexible. Therefore, you can consider using CSS expression to solve (DEMO), such as:
/*
http://old9.blogsome.com/2008/10/26/css-expression-reloaded/
http://dancewithnet.com/2009/07/27/get-right-url-from-html/
*/
*background-image:expression(function(ele){
ele.style.backgroundImage = 'url(mhtml:' +
document.getElementById('data-uri-css').getAttribute('href',4) +
'!03114501408821761.gif)';
}(this));
