Terkadang spasi mendapatkan URL yang disandikan ke +tanda, kadang-kadang untuk %20. Apa perbedaannya dan mengapa ini harus terjadi?
Jawaban:
+berarti spasi hanya dalam application/x-www-form-urlencodedkonten, seperti bagian permintaan URL:
http://www.example.com/path/foo+bar/path?query+name=query+value
Dalam URL ini, nama parameter query namedengan spasi dan nilainya query valuedengan spasi, tetapi nama folder di jalur secara harfiah foo+bar, bukan foo bar .
%20adalah cara yang valid untuk menyandikan spasi di salah satu dari konteks ini. Jadi, jika Anda perlu menyandikan URL string untuk disertakan di bagian URL, selalu aman untuk mengganti spasi dengan %20dan ditambah dengan %2B. Inilah yang misalnya. encodeURIComponent()lakukan dalam JavaScript. Sayangnya bukan itu yang dilakukan urlencode di PHP ( rawurlencode lebih aman).
Lihat Juga Aplikasi spesifikasi HTML 4.01 / x-www-form-urlencoded
query+name=query+valueparameter dari formulir dengan <input name="query name" value="query value">. Itu tidak akan dibuat query%20namedari formulir, tapi itu benar-benar aman untuk menggunakannya, misalnya. jika Anda menempatkan pengiriman formulir bersama diri Anda untuk XMLHttpRequest. Jika Anda memiliki URL dengan spasi di dalamnya, seperti <a href="http://www.example.com/foo bar/">, maka browser akan menyandikannya %20untuk Anda memperbaiki kesalahan Anda, tetapi itu mungkin sebaiknya tidak diandalkan.
foo barke foo+bar?
encodeURIComponent(s).replace(/%20/g, '+')jika Anda benar-benar membutuhkannya+
http://www.example.com/some/path/to/resource?param1=value1
Bagian sebelum tanda tanya harus menggunakan% encoding (jadi %20untuk spasi), setelah tanda tanya Anda bisa menggunakan salah satu %20atau +untuk spasi. Jika Anda membutuhkan yang aktual +setelah penggunaan tanda tanya %2B.
decodeURIComponentjangan memecahkan kode itu.
+adalah karakter yang dilindungi undang - undang itu akan dipertahankan oleh browser.
+secara default ( { foo: 'bar bar'}.to_query=> foo=bar+bar)
Jadi, jawaban di sini agak tidak lengkap. Penggunaan '% 20' untuk menyandikan spasi di URL secara eksplisit didefinisikan dalam RFC3986 , yang mendefinisikan bagaimana URI dibangun. Tidak disebutkan dalam spesifikasi ini menggunakan '+' untuk ruang penyandian - jika Anda hanya mengikuti spesifikasi ini, spasi harus disandikan sebagai '% 20'.
Penyebutan menggunakan '+' untuk ruang pengkodean berasal dari berbagai inkarnasi spesifikasi HTML - khususnya di bagian yang menggambarkan tipe konten 'application / x-www-form-urlencoded'. Ini digunakan untuk memposting data formulir.
Sekarang, Spesifikasi HTML 2.0 (RFC1866) secara eksplisit mengatakan, di bagian 8.2.2, bahwa bagian Permintaan dari string URL permintaan GET harus dikodekan sebagai 'application / x-www-form-urlencoded'. Ini, secara teori, menunjukkan bahwa menggunakan '+' di URL dalam string kueri adalah sah (setelah '?').
Tapi ... benarkah itu? Ingat, HTML sendiri merupakan spesifikasi konten, dan URL dengan string kueri dapat digunakan dengan konten selain HTML. Lebih lanjut, sementara versi selanjutnya dari spesifikasi HTML terus mendefinisikan '+' sebagai legal dalam konten 'application / x-www-form-urlencoded', mereka sepenuhnya menghilangkan bagian yang mengatakan bahwa string permintaan permintaan GET didefinisikan sebagai tipe itu. Sebenarnya, tidak disebutkan apa pun tentang pengkodean string kueri apa pun setelah spesifikasi HTML 2.0.
Yang meninggalkan kita dengan pertanyaan - apakah itu valid? Tentu saja ada BANYAK kode lawas yang mendukung '+' dalam string kueri, dan banyak kode yang menghasilkannya juga. Jadi peluangnya bagus Anda tidak akan putus jika Anda menggunakan '+'. (Dan, pada kenyataannya, saya melakukan semua penelitian tentang hal ini baru-baru ini karena saya menemukan situs utama yang gagal menerima '% 20' dalam kueri GET sebagai spasi. Mereka benar-benar gagal memecahkan kode APA PUN persen karakter yang disandikan. Jadi layanan yang Anda lakukan Sedang menggunakan mungkin juga relevan.)
Tetapi dari pembacaan spesifikasi yang murni, tanpa bahasa dari spesifikasi HTML 2.0 dibawa ke versi yang lebih baru, URL sepenuhnya ditanggung oleh RFC3986, yang berarti spasi harus dikonversi ke '% 20'. Dan tentunya itu yang seharusnya terjadi jika Anda meminta sesuatu selain dokumen HTML.
%20( <a href="?q=a b">), tetapi ketika Anda mengirim formulir, ia menggunakan +tanda. Anda bisa menimpanya dengan menggunakan +tanda ( <a href="?q=a+b">), atau dengan mengirimkan formulir menggunakan XMLHTTPRequest.
Lebih baik untuk selalu menyandikan spasi sebagai% 20, bukan sebagai "+".
Itu adalah RFC-1866 (spesifikasi HTML 2.0), yang menetapkan bahwa karakter spasi harus dikodekan sebagai "+" dalam "application / x-www-form-urlencoded" pasangan-nilai kunci tipe-tipe konten. (lihat paragraf 8.2.1. sub-paragraf 1.). Cara pengkodean data formulir ini juga diberikan dalam spesifikasi HTML nanti, cari paragraf yang relevan tentang aplikasi / x-www-form-urlencoded.
Berikut adalah contoh dari string dalam URL di mana RFC-1866 memungkinkan ruang pengkodean sebagai plus: "http://example.com/over/there?name=foo+bar". Jadi, hanya setelah "?", Spasi dapat diganti dengan plus, menurut RFC-1866. Dalam kasus lain, spasi harus dikodekan ke% 20. Tetapi karena sulit untuk menentukan konteksnya, itu praktik terbaik untuk tidak pernah menyandikan spasi sebagai "+".
Saya akan merekomendasikan untuk meng-encode semua karakter kecuali "unreserved" yang didefinisikan dalam RFC-3986, hal.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Apa bedanya: Lihat jawaban lain.
Kapan digunakan, +bukan %20? Gunakan +jika, karena alasan tertentu, Anda ingin membuat string kueri URL ( ?.....) atau fragmen hash ( #....) lebih mudah dibaca. Contoh: Anda sebenarnya dapat membaca ini:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B= +)
Tetapi yang berikut ini jauh lebih sulit dibaca: (setidaknya bagi saya)
Saya pikir +tidak akan merusak apa pun, karena Google menggunakan +(lihat tautan 1 di atas) dan mereka mungkin sudah memikirkan hal ini. Saya akan menggunakan +diri saya hanya karena dapat dibaca + Google berpikir tidak apa-apa.