Generator Data URI

Sebuah berkas di dalam alamat

Sebuah data URI adalah berkas utuh yang dituliskan sebagai alamat. Alih-alih menunjuk ke sumber daya yang harus dijemput peramban, ia membawa bitanya sendiri, sehingga sebuah ikon bisa tinggal di dalam lembar gaya yang memakainya dan gambar kecil di dalam HTML yang menampilkannya. RFC 2397 mendefinisikan skema ini pada 1998 dan sejak dua dasawarsa lalu didukung di mana-mana.

Tata bahasanya pendek. Setelah nama skema datang tipe media opsional dengan parameter opsional, lalu penanda base64 opsional, lalu koma, lalu datanya. Semua yang mendahului koma adalah tajuk dan semua yang mengikutinya adalah muatan — itulah sebabnya peramban memisah pada koma pertama, dan itulah sebabnya koma di dalam muatan tidak berbahaya.

data:[<mediatype>][;base64],<data>

data:,hello                          text/plain;charset=US-ASCII
data:text/plain;charset=utf-8,hello  the same bytes, spelled out
data:image/png;base64,iVBORw0KGgo=   binary, Base64 encoded
data:image/svg+xml,%3Csvg%20...      markup, percent-encoded

Tajuk kosong itu sah dan berarti text/plain;charset=US-ASCII, satu-satunya nilai bawaan yang diberikan spesifikasi. Halaman ini melaporkan bahwa ia menerapkannya, alih-alih menampilkan tipe media yang tidak pernah Anda tulis.

Dua penyandian, dan mana yang lebih pendek

RFC mendefinisikan dua cara menuliskan muatan, dan pilihannya bukan soal selera: untuk sebuah berkas tertentu salah satunya jelas lebih pendek, dan yang mana sepenuhnya bergantung pada isi berkas itu.

Base64 menulis ulang setiap tiga bita menjadi empat karakter dari abjad berisi 64 karakter. Biayanya tetap dan dapat diperkirakan: tepat sepertiga lebih banyak, ditambah pengganjal. Ia bekerja untuk apa pun, dan itulah sebabnya orang meraihnya lebih dulu.

Penyandian persen membiarkan setiap karakter yang sah di dalam URL apa adanya dan menghabiskan tiga karakter untuk setiap karakter lain. Untuk muatan yang sebagian besar ASCII biasa — sebuah SVG, lembar gaya kecil, potongan JSON — kebanyakan bita lewat tanpa disentuh dan hasilnya lebih pendek daripada Base64, kerap dua puluh sampai tiga puluh persen. Untuk PNG atau fon, yang hampir setiap bitanya harus dilolos, hasilnya mendekati tiga kali lipat aslinya dan jauh lebih buruk daripada Base64.

Seberapa banyak yang dilolos itu sendiri sebuah keputusan, dan halaman ini menyediakan kedua jawabannya:

• Himpunan ketat melolos setiap bita di luar karakter tak-tercadang RFC 3986 — huruf, angka, tanda hubung, titik, garis bawah, dan tilde. Hasilnya aman di konteks mana pun, dengan ongkos melolos tanda baca yang sebenarnya tidak memerlukannya.
• Himpunan minimal mempertahankan segala yang benar-benar diizinkan tata bahasa data URI, termasuk garis miring, titik dua, tanda sama dengan, tanda kutip, dan tanda kurung yang memenuhi markah. Di sinilah penyandian persen menang, dan itulah sebabnya SVG yang ditulis dengan kutip tunggal di sekeliling atributnya tersandi jauh lebih baik daripada yang memakai kutip ganda.
• Tujuan menambah satu aturan lagi. Di dalam atribut HTML, ampersan telanjang memulai acuan karakter, jadi memilih tujuan img membuatnya ikut dilolos. Selain itu tidak ada yang berubah: kutip ganda, kurung siku sudut, dan garis miring terbalik memang sudah di luar himpunan yang diizinkan dan dilolos pada kedua tingkat.
• Tanda persen selalu dilolos, pada tingkat mana pun. Ia membuka runtunan pelolosan, jadi persen harfiah harus ditulis %25 atau dua karakter berikutnya akan dibaca sebagai heksadesimal.

Alih-alih membiarkan Anda menebak, halaman ini menyandikan muatan dengan kedua cara dan melaporkan dua panjangnya beserta selisihnya. Ambil yang menang, atau tetapkan penyandian secara manual bila Anda punya alasan.

Angka 33% itu angka sebelum pemampatan

Hampir setiap pembahasan tentang data URI mengulang bahwa Base64 menambah sepertiga pada ukuran berkas. Secara aritmetika benar dan dalam praktik menyesatkan, sebab angka itu menggambarkan bita sebelum sampai ke jaringan, dan setiap peladen memampatkan teks saat mengirim.

Base64 tidak menambah informasi; ia menyebar informasi yang sama ke lebih banyak karakter, dan hanya memakai 64 dari 256 nilai yang bisa ditampung sebuah bita. Itu persis jenis kelewahan yang membuat gzip dan Brotli ada. Pada muatan yang sudah termampat — PNG, JPEG, fon WOFF2 — pemampat tidak bisa menyentuh datanya, tetapi bisa memadatkan kembali Base64 hingga sangat dekat dengan ukuran aslinya. Sepertiga yang termasyhur itu sebagian besar lenyap.

Maka halaman ini mengukur alih-alih menyatakan. Ia memampatkan tiga hal dengan implementasi gzip peramban itu sendiri: muatan seperti kalau disajikan sebagai berkas terpisah, dokumen yang membawanya sebagai Base64, dan dokumen yang membawanya dengan penyandian persen. Ketiga angka itu adalah versi jujur dari argumen ukuran, dan sering menunjukkan bahwa biaya sesungguhnya dari penyisipan sama sekali bukan ukuran.

Biaya sesungguhnya ada di tempat lain. Berkas yang disisipkan tidak bisa disinggahkan sendiri, jadi ia diunduh lagi bersama setiap salinan dokumen yang membawanya, dan tidak akan pernah dipakai bersama oleh dua halaman. Ia juga menghambat: sebuah lembar gaya tidak selesai diurai sebelum membaca seluruh URI yang duduk di tengahnya. HTTP/2 sudah menghapus hampir semua denda per permintaan yang dulu membuat penyisipan menarik. Untuk ikon mungil yang muncul di setiap halaman, itu masih pertukaran yang masuk akal; di atas beberapa puluh kilobita biasanya tidak, dan itulah sebabnya halaman ini mulai memperingatkan pada tiga puluh.

Tipe berasal dari bita

Sebuah data URI baru berguna kalau tipe medianya benar. Salah menetapkannya dan peramban akan menolak menampilkan gambar, memakai pengurai yang keliru, atau — untuk apa pun yang disajikan dengan tipe yang tidak dikenalinya — menawarkan unduhan sebagai gantinya.

Saat Anda menjatuhkan berkas, peramban melaporkan tipe versinya sendiri, tetapi laporan itu diturunkan dari ekstensi berkas dan tidak dari apa pun yang lain. Ganti nama JPEG menjadi .png dan peramban akan menyebutnya PNG. Halaman ini justru membaca bita pertamanya. Hampir setiap format biner diawali tanda tangan: PNG diawali bita yang mustahil muncul dalam ASCII lalu huruf PNG, JPEG oleh tiga bita tetap, PDF oleh tanda persen dan kata PDF, sedangkan WOFF dan WOFF2 oleh tag empat karakter masing-masing. Ketika tanda tangan dan ekstensi bertentangan, tanda tangan menang dan pertentangannya dilaporkan.

Daftarnya sengaja pendek — format yang benar-benar disisipkan orang, bukan segala hal yang bisa diendus peramban. Kalau tidak ada yang cocok dan bitanya berupa teks yang sah, tipenya teks, dengan SVG dan XML dipisahkan berdasarkan pembuka markahnya. Kalau sama sekali tidak ada yang cocok, jawabannya application/octet-stream, dan ruasnya tetap bisa disunting, sebab tebakan yang salah lebih buruk daripada ketidaktahuan yang diakui.

Untuk muatan teks, himpunan karakter juga penting. Nilai bawaan spesifikasi adalah US-ASCII, yang bukan maksud siapa pun hari ini, jadi tipe media teks ditawarkan dengan charset=utf-8 terpasang. Menghilangkannya tidak merusak bitanya, tetapi mengubah cara bita itu dibaca kembali.

Membaca satu kembali

Separuh pekerjaan yang lain justru lebih sering muncul: Anda menemukan data: URI di lembar gaya, di salinan DOM, atau di halaman yang tersimpan, dan ingin tahu itu apa. Tempelkan dan halaman ini membongkarnya — tipe medianya, parameternya, penyandian yang dipakai, berapa bita hasil dekodenya berbanding berapa karakter ongkosnya, dan bita itu sebenarnya apa terlepas dari klaim tajuknya. Gambar digambar, teks ditampilkan, dan apa pun selain itu memperoleh bita pertamanya dalam heksadesimal.

Pendekodean bersifat ketat, sebab URI yang ditempel adalah masukan tak tepercaya dan jawaban yang masuk akal tetapi salah lebih buruk daripada galat. Koma yang hilang, tipe media yang cacat, tanda persen tanpa dua digit heksadesimal sesudahnya, karakter di luar abjad Base64: masing-masing gagal dengan posisi masalahnya alih-alih diperbaiki diam-diam.

Dua hal dimaklumi, karena setiap peramban memakluminya dan karena URI yang disalin dari lembar gaya yang dilipat barisnya jika tidak akan mustahil dipakai. Spasi di dalam muatan dibuang, dan pengganjal Base64 yang kurang dilengkapi. Keduanya dilaporkan, sehingga Anda tahu URI yang Anda pegang bukan persis URI yang bekerja di mana-mana.

Satu hal yang tampak serupa ditolak mentah-mentah. Abjad Base64 aman-URL, yang menukar tanda tambah dan garis miring dengan tanda hubung dan garis bawah, adalah yang dipakai JSON Web Token — dan bukan yang diterima data URI. Menerimanya diam-diam berarti mendekode ke bita yang berbeda dari yang akan didekode peramban, jadi ia ditolak dengan namanya, beserta posisi karakter yang menyalahi.

Di mana ini berjalan

Semuanya terjadi di peramban Anda. Berkas yang Anda pilih dibaca dengan antarmuka berkas lokal dan tidak pernah diunggah; penyandian, pengukuran pemampatan, dan pendekodean semuanya berjalan di mesin Anda sendiri, dan tidak ada yang disimpan atau dicatat. Hal itu lebih penting di sini daripada di kebanyakan halaman, sebab berkas yang diubah orang menjadi data URI kerap merupakan aset internal, dan URI yang mereka tempel untuk diperiksa berasal dari halaman produksi.