Mengapa tautan kehilangan data: perbaiki parameter dan fragmen

Halaman yang terbuka belum tentu menerima data yang diharapkan

Anda menyiapkan tautan pencarian kopi dan teh. Halaman terbuka, tetapi hasilnya tidak sesuai niat. Sebelum menyalahkan server atau pemendek tautan, periksa alamat persis yang dibagikan. Dalam contoh fiktif, q=cafe&te tidak mewakili satu nilai cafe&te pada interpretasi umum parameter formulir: & memisahkan entri. Selain itu, #precios menandai fragmen. Ganti example.invalid dengan halaman milik Anda yang mendukung kueri sebelum menguji alamat nyata.

Pisahkan diagnosis menjadi tiga pertanyaan: halaman mana yang ingin dibuka, data apa yang harus diterima dan bagian mana yang ingin ditampilkan setelahnya? Salin URL tautan, bukan hanya label tombol yang terlihat. Simpan versi acuan sebelum mengedit. Panduan ini menyarankan pemeriksaan komponen lalu hasilnya dengan WikiURL; tidak menjanjikan semua situs mengenali q atau bahwa respons berhasil berarti hasil pencarian benar.

https://example.invalid/buscar?q=cafe&te#precios

Jika ampersand bagian dari teks, jangan jadikan pemisah

Untuk mencari cafe & te secara harfiah, ampersand termasuk dalam nilai q. Saat menyusun parameter dengan URLSearchParams, berikan teks yang belum dikodekan; serialisasi mewakili karakter itu sebagai %26. MDN menjelaskan bahwa antarmuka ini menerapkan pengodean formulir ketika mengubah parameter menjadi teks dan mewakili spasi dengan +. Bukan berarti semua ampersand dalam URL harus diganti: sebagian memang memisahkan parameter.

Contoh JavaScript membuat alamat dari basis, menetapkan nilai pencarian dan menambahkan fragmen secara terpisah. Anda dapat menjalankannya secara lokal dalam lingkungan JavaScript untuk melihat hasil tanpa mengirim pencarian ke domain fiktif. Jika tidak memprogram, gunakan tautan yang dihasilkan halaman pencarian Anda daripada menyambungkan teks secara manual. Bandingkan nilai yang diharapkan dengan hasil situs; adanya %26 pada tautan belum menunjukkan cara aplikasi tertentu menafsirkan data.

const url = new URL("https://example.invalid/buscar");
url.searchParams.set("q", "cafe & te");
url.hash = "precios";
console.log(url.href);
// https://example.invalid/buscar?q=cafe+%26+te#precios

Fragmen bukan parameter yang diterima server

MDN mendokumentasikan bahwa fragmen sesudah # diproses oleh klien dan tidak dikirim ke server ketika sumber daya diminta. Halaman dapat memakainya untuk menuju bagian seperti precios atau perilaku aplikasi lain. Karena itu, q=cafe#te tidak membuat te melengkapi nilai yang diterima server dalam permintaan tersebut. Jika # harus menjadi bagian teks pencarian, representasinya di dalam nilai adalah %23, seperti pada alamat ketiga.

Periksa dua efek secara terpisah: pencarian harus menampilkan hasil yang diharapkan dan fragmen harus mencapai tempat yang dituju. Bagian tersebut harus ada atau aplikasi mengenali fragmennya. Pemeriksa yang meminta situs dari server tidak dengan sendirinya memastikan peramban menggulir ke suatu bagian. Jangan pula menghapus semua fragmen sebagai solusi universal: justru bagian yang diperlukan penerima dapat terhapus.

https://example.invalid/buscar?q=cafe%23te#precios

Kodekan nilainya sekali, bukan seluruh alamat

RFC 3986 membedakan karakter pembatas komponen dari data serta memperingatkan agar tidak mengodekan atau mendekodekan string yang sama berulang kali. Jika cafe%26te diberikan sebagai teks yang sudah dikodekan kepada fungsi yang mengharapkan nilai mentah, tanda persen dapat menjadi %25 dan menghasilkan %2526. Anda menambah satu lapisan, bukan otomatis mempertahankan pencarian yang dimaksud. Dua baris contoh membantu mengenali perubahan ini.

Perbaikan bergantung pada asal data. Jika berasal dari teks manusia, berikan tanpa pengodean ke antarmuka penyusun parameter. Jika berasal dari URL lengkap yang valid, jangan anggap seluruh alamat sebagai satu nilai untuk dikodekan ulang. Dokumentasikan masukan setiap fungsi atau formulir. Hindari penggantian global pada %, & atau #: itu dapat mengubah pembatas yang benar, parameter penting atau jalur yang tidak ingin diubah.

q=cafe%26te
q=cafe%2526te

Gunakan WikiURL untuk respons, peramban untuk konten

Setelah memiliki alamat publik nyata, tempelkan ke pemeriksa URL WikiURL. Tinjau status HTTP dan tujuan akhir yang dikembalikan. Implementasinya meminta dari server dan mengikuti pengalihan; pemeriksaan membantu menemukan tujuan tidak terduga. Jangan tempel tautan pengelolaan, kata sandi atau alamat berisi data pribadi. Jangan mencoba memeriksa example.invalid pada contoh: alamat itu berfungsi sebagai tujuan fiktif.

Buka juga versi nyata di peramban dan periksa pencarian serta bagiannya. Respons berhasil dapat memuat halaman tanpa menerapkan filter yang diharapkan. Jika ada pengalihan, bandingkan parameternya dengan acuan dan amati fragmen di peramban. Pemeriksa tidak menafsirkan logika aplikasi, menjamin keamanan atau membuktikan akun pengguna berhak melihat konten. Tujuannya menggabungkan bukti respons dengan pemeriksaan fungsi.

Uji salinan yang akan diterima orang lain

Tempel tautan akhir di saluran tempat Anda membagikannya dan buka salinan tersebut sebelum distribusi luas. Pastikan tidak menyertakan titik akhir kalimat, kehilangan bagian saat menyalin atau menganggap teks terlihat sebagai tujuan. Jika konten harus publik, uji tanpa bergantung pada sesi administrator. Jika mengubahnya menjadi QR, periksa juga alamat yang ditampilkan hasil pemindaian selain berkas sumber.

Simpan catatan kecil: alamat asli, nilai pencarian yang diharapkan, fragmen yang dituju, URL yang dibagikan dan hasil pengamatan. Jika gagal, kembali ke komponen tertentu dan ulangi setelah perbaikan. Terbitkan hanya versi yang diperiksa. Dengan demikian, kesalahan penyusunan parameter dapat dibedakan dari pengalihan yang mengubah tujuan atau perilaku peramban, tanpa menjadikan tautan yang terbuka sebagai jaminan seluruh data tetap tersampaikan.