Data URI Data URI adalah solusi yang ditentukan oleh RFC 2397 untuk menyematkan file kecil langsung ke dalam dokumen. Melalui sintaks berikut, Anda dapat mengubah file kecil menjadi penyandian yang ditentukan dan secara langsung menanamkannya ke halaman:
Data: [<Mime-Type>] [; base64], <data>
- Mime-type: Menentukan MIME dari data tertanam. Bentuknya adalah [tipe]/[subtipe]; Parameter, misalnya, pantomim yang sesuai dengan gambar png adalah gambar/png. Parameter dapat menggunakan informasi tambahan untuk menentukan parameter charset untuk teks/polos dan teks/htm, dll. Standarnya adalah teks/polos; charset = us-ASCII.
- Base64: Deklarasikan pengkodean data selanjutnya adalah basis64, jika tidak data harus dikodekan dengan persentase nomor (yaitu, urlencode konten).
Pada abad terakhir, HTML4.01 memperkenalkan solusi URI data. Sampai hari ini, semua browser arus utama kecuali dukungan IE6 dan IE7, tetapi IE8 masih memiliki batasan pada dukungan data URI, hanya objek pendukung (hanya ketika gambar), IMG, tipe input = gambar, tautan dan CSS, dan volume data tidak dapat lebih besar dari 32k.
keuntungan:- Kurangi jumlah permintaan HTTP, tanpa batasan konsumsi koneksi TCP dan jumlah konkurensi browser dengan nama domain yang sama.
- Untuk file kecil, bandwidth akan dikurangi. Meskipun jumlah data akan meningkat setelah pengkodean, header HTTP berkurang. Ketika jumlah data header HTTP lebih besar dari kenaikan pengkodean file, bandwidth akan dikurangi.
- Untuk situs HTTPS, akan ada petunjuk keamanan untuk mencampur HTTPS dan HTTP, dan HTTPS lebih mahal daripada HTTP, jadi data URI memiliki keunggulan yang lebih jelas dalam hal ini.
- Anda dapat menyimpan seluruh halaman multimedia sebagai file.
Kekurangan :
- Itu tidak bisa digunakan kembali. Jika dokumen yang sama menerapkan konten yang sama beberapa kali, perlu diulang beberapa kali, dan jumlah data meningkat pesat, yang meningkatkan waktu pengunduhan.
- Itu tidak dapat di -cache sendiri, sehingga juga perlu dimuat kembali ketika berisi ulang dokumen.
- Klien perlu melakukan ulang kode dan ditampilkan, yang meningkatkan konsumsi.
- Kompresi data tidak didukung, pengkodean basis64 akan meningkat sebesar 1/3 dari ukurannya, dan jumlah data akan meningkat lebih banyak setelah urlencode.
- Ini tidak kondusif untuk penyaringan perangkat lunak keamanan, tetapi juga memiliki risiko keamanan tertentu.
MHTML MHTML adalah singkatan dari MIME HTML (multiguna Internet Mail Extension HTML), yang didefinisikan oleh RFC 2557 untuk menyimpan semua konten halaman multimedia ke dokumen yang sama. Solusi ini diusulkan oleh Microsoft untuk mendukungnya sejak IE5.0, dan Opera9.0 juga mulai mendukungnya. Safari dapat menyimpan file di .mht (akhiran file MHTML), tetapi tidak mendukung menampilkannya.
MHTML dan data URI serupa, dengan fungsi yang lebih kuat dan sintaks yang lebih kompleks, dan tidak memiliki kelemahan yang tidak dapat digunakan kembali dalam data URI, tetapi MHTML tidak fleksibel dan cukup nyaman untuk digunakan. Misalnya, URL yang dirujuk ke sumber daya dapat berupa alamat relatif dalam file MHT, jika tidak, itu harus menjadi alamat absolut. Solusi Hedger untuk IE di "Cross Browser Base64 gambar yang disandikan yang tertanam dalam HTML" menggunakan jalur relatif karena menyatakan tipe konten: pesan/RFC822 untuk membuat IE parse menurut MHTML. Jika tipe konten tidak dimodifikasi, protokol MHTML diperlukan. Pada saat ini, jalur absolut harus digunakan, seperti "MHTML - saat Anda membutuhkan data: URI di IE7 dan Under".
aplikasi Kombinasi data URI dan MHTML dapat sepenuhnya menyelesaikan semua browser arus utama. Karena cacat di -cache dan digunakan kembali, mereka tidak cocok untuk digunakan di halaman secara langsung. Namun, mereka memiliki keuntungan besar dalam penggunaan gambar yang tepat dalam file CSS dan JavaScript:
- Jumlah permintaan telah sangat berkurang, dan CSS situs web besar sekarang merujuk sejumlah besar sumber daya gambar.
- Baik CSS dan JavaScript dapat di -cache, secara tidak langsung menerapkan caching data.
- Menggunakan CSS dapat menyelesaikan masalah penggunaan kembali data URI
- Ucapkan selamat tinggal pada sprite CSS, sprite CSS tampaknya mengurangi jumlah permintaan, tetapi selain membawa pengecualian dalam situasi yang tidak pasti, sprite CSS juga membutuhkan penggabungan gambar buatan. Bahkan jika ada alat penggabungan, itu masih harus secara artifisial menghabiskan banyak waktu tentang cara membingungkan secara efektif dan membawa kesulitan pemeliharaan. Setelah Anda mengikuti prinsip-prinsip desain tertentu, Anda dapat sepenuhnya meninggalkan sprite CSS untuk menulis CSS, dan akhirnya menggunakan alat untuk mengonversi gambar menjadi data URI dan MHTML selama mengunggah ke server, seperti alat yang diimplementasikan dalam Python dalam "menggunakan data dan gambar gaya gabungan data-URI", yang dapat menghemat banyak waktu.
- Pengkodean Base64 meningkatkan file gambar sebesar 1/3, dan penggunaan data URI dan MHTML pada saat yang sama setara dengan peningkatan 2/3. Namun, CSS dan JavaScript dapat menggunakan kompresi GZIP, yang dapat menghemat 2/3 dari volume data, sehingga volume data akhir setelah menggunakan kompresi GZIP adalah (1 + 1/3) * 2 * (1/3) = 8/9, sehingga lalu lintas akhir dikurangi.
Untuk memfasilitasi implementasi data URI dan MHTML di CSS, saya menulis Data URI & MHTML Generator, yang dapat Anda gunakan untuk menghasilkan data aplikasi aplikasi URI & MHTML.
Saat menggunakan MHTML dalam file CSS, URL harus menggunakan jalur absolut, yang membuatnya sangat tidak fleksibel. Oleh karena itu, Anda dapat mempertimbangkan menggunakan ekspresi CSS untuk memecahkan (demo), seperti:
/*
http://old9.blogsome.com/2008/10/26/css-expression-reloaded/
http://danceWithnet.com/2009/07/27/get-right-url-from-html/
*/
*latar belakang-gambar: ekspresi (fungsi (ele) {
ELE.STYLE.BackgroundImage = 'url (mhtml:' +
document.geteLementById ('data-uri-css'). getAttribute ('href', 4) +
'! 03114501408821761.gif)';
}(ini));
