데이터 URI와 MHTML은 모든 브라우저_HTML/Xhtml_웹페이지 제작을 완벽하게 해결합니다.

데이터 URI

데이터 URI는 작은 파일을 문서에 직접 삽입하기 위해 RFC 2397에서 정의한 체계입니다. 다음 구문을 통해 작은 파일을 지정된 인코딩으로 변환하고 페이지에 직접 포함할 수 있습니다.

데이터:[][;base64],

1. MIME 유형: 삽입된 데이터의 MIME을 지정합니다. 형식은 [type]/[subtype] 매개변수입니다. 예를 들어 png 이미지에 해당하는 MIME은 image/png입니다. 매개변수는 추가 정보를 지정하는 데 사용될 수 있으며, 더 많은 경우 text/plain 및 text/htm과 같은 텍스트 인코딩 방법을 지정하는 데 사용되는 charset 매개변수입니다. 기본값은 text/plain;charset=US-ASCII입니다.
2. base64: 명령문 뒤의 데이터 인코딩은 base64입니다. 그렇지 않은 경우 데이터는 퍼센트 인코딩되어야 합니다(즉, 콘텐츠를 urlencode해야 합니다).

지난 세기에HTML4.01은 데이터 URI 체계를 도입했습니다IE6 및 IE7을 제외한 모든 주요 브라우저는를 지원하지만 IE8은 지원합니다. 데이터 URI는 여전히 제한되어 있습니다. CSS에서는 개체(그림만 해당), img, 입력 유형=이미지, 링크 및 URL만 지원하며 데이터 크기는 32K를 초과할 수 없습니다.

장점:

1. HTTP 요청 수를 줄입니다. TCP 연결 소비가 없으며 동일한 도메인 이름에서 동시 브라우저 수에 제한이 있습니다.
2. 작은 파일의 경우 대역폭이 줄어듭니다. 인코딩 후에는 데이터 양이 늘어나지만 http 헤더의 데이터 양이 파일 인코딩 증가분보다 커지면 대역폭이 줄어듭니다.
3. HTTPS 사이트의 경우 HTTPS와 HTTP를 함께 사용하면 보안 프롬프트가 표시됩니다. HTTPS는 HTTP보다 비용이 더 많이 들기 때문에 이와 관련하여 데이터 URI가 더 확실한 이점을 갖습니다.
4. 멀티미디어 페이지 전체를 파일로 저장할 수 있습니다.

단점:

1. 재사용할 수 없습니다. 동일한 문서에 동일한 내용을 여러 번 적용하면 여러 번 반복해야 하므로 데이터 양이 늘어나고 다운로드 시간도 늘어납니다.
2. 은 자체적으로 캐시할 수 없으므로 포함된 문서가 다시 로드될 때 다시 로드됩니다.
3. 클라이언트에서 다시 디코딩하여 표시해야 하므로 포인트 소모가 늘어납니다.
4. 데이터 압축은 지원되지 않습니다. base64 인코딩을 사용하면 크기가 1/3로 늘어나고 urlencoding 후에는 데이터 볼륨이 더욱 늘어납니다.
5. 보안 소프트웨어 필터링에 도움이 되지 않으며 특정 보안 위험도 있습니다.

MHTML

MHTML은 MIME HTML(Multi Purpose Internet Mail Extension HTML)의 약어로, 멀티미디어 페이지의 모든 내용을 동일한 문서에 저장하도록 RFC 2557에서 정의한 솔루션입니다. 이 솔루션은 IE5.0부터 지원하기 위해 Microsoft에서 제안했으며 Opera9.0에서도 지원하기 시작했습니다. Safari에서는 파일을 .mht(MHTML 파일 접미사) 형식으로 저장할 수 있지만 표시는 지원하지 않습니다.

MHTML은 상대적으로 데이터 URI와 유사하며 더 강력한 기능과 더 복잡한 구문을 가지고 있으며 데이터 URI에서 "재사용할 수 없다"는 단점이 없습니다. 그러나 MHTML은 다음과 같이 유연하고 사용하기 편리하지 않습니다. 리소스 참조의 URL은 mht 파일의 상대 주소일 수 있으며, 그렇지 않으면 절대 주소여야 합니다. hedger의 《HTML에 포함된 크로스 브라우저 Base64 인코딩 이미지》IE용 솔루션은 Content-type: message/rfc822가 선언되어 IE가 Content가 MHTML에 따라 구문 분석하도록 하기 때문에 상대 경로를 사용합니다. 수정된 유형에는 MHTML 프로토콜을 사용해야 합니다. 이 경우 《MHTML – 데이터가 필요한 경우: IE7 이하의 URI》와 같은 절대 경로를 사용해야 합니다.

신청

데이터 URI와 MHTML의 조합은 모든 주류 브라우저의 문제를 완전히 해결할 수 있습니다. 캐시하고 재사용할 수 없기 때문에 페이지에서 직접 사용하기에는 적합하지 않지만 CSS 및 JavaScript 파일에서 사용하기에는 적합합니다. 사진을 적절하게 사용하면 큰 장점이 있습니다.

1. 요청 횟수를 대폭 줄입니다. 이제 대형 웹사이트의 CSS는 수많은 이미지 리소스를 참조합니다.
2. CSS와 JavaScript 모두 캐시가 가능하여 데이터 캐싱을 간접적으로 구현합니다.
3. CSS를 사용하면 데이터 URI 재사용 문제를 해결할 수 있습니다.
4. 안녕하세요CSS Sprites CSS Sprites는 요청 수를 줄이기 위해 등장했지만 불확실한 상황에서 예외를 가져오는 것 외에도 CSS Sprites에는 인공 이미지가 있더라도 병합이 필요합니다. 은 병합 도구이지만 효과적으로 퍼즐을 맞추는 데 여전히 많은 시간이 필요하고 유지 관리가 어렵습니다. 특정 디자인 원칙을 따르면 CSS Sprite를 완전히 버리고 CSS를 작성할 수 있으며, 마지막으로 서버에 업로드할 때 이미지를 데이터 URI 및 MHTML로 변환하는 도구를 사용할 수 있습니다. 예를 들어 "data-uri를 사용하여 스타일 시트 및 " 그림의 Python으로 구현된 도구를 사용하면 시간을 많이 절약할 수 있습니다.
5. Base64 인코딩을 사용하면 이미지 파일이 1/3 늘어납니다. 데이터 URI와 MHTML을 동시에 사용하면 2/3가 늘어나는 것과 같지만 CSS와 JavaScript는 gzip 압축을 사용하여 2/3를 절약할 수 있습니다. 데이터 용량이므로 gzip 압축 후 최종 데이터 용량을 사용하면 (1 1/3) * 2 * (1/3) = 8/9이므로 최종 트래픽이 줄어듭니다.

CSS에서 데이터 URI와 MHTML을 쉽게 구현하기 위해 데이터 URI 및 MHTML 생성기를 작성했습니다. 생성된 데이터 URI 및 MHTML 적용 예를 볼 수 있습니다.

CSS 파일에서 MHTML을 사용할 때 URL은 매우 유연하지 않은 절대 경로를 사용해야 하므로 다음과 같은 CSS 표현식(DEMO)을 사용하여 문제를 해결할 수 있습니다.

/*
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:'
문서. getElementById('data-uri-css').getAttribute('href',4)