Kapan ruang dalam URL disandikan +
, dan kapan ruang itu disandikan %20
?
Kapan ruang dalam URL disandikan +
, dan kapan ruang itu disandikan %20
?
Jawaban:
Dari Wikipedia (penekanan dan tautan ditambahkan):
Ketika data yang telah dimasukkan ke dalam formulir HTML dikirimkan, nama dan nilai bidang formulir dikodekan dan dikirim ke server dalam pesan permintaan HTTP menggunakan metode GET atau POST, atau, secara historis, melalui email. Pengkodean yang digunakan secara default didasarkan pada versi yang paling awal dari aturan pengkodean persen URI umum, dengan sejumlah modifikasi seperti normalisasi baris baru dan penggantian spasi dengan "+" alih-alih "% 20". Jenis data MIME yang disandikan dengan cara ini adalah application / x-www-form-urlencoded, dan saat ini didefinisikan (masih dalam cara yang sangat ketinggalan zaman) dalam spesifikasi HTML dan XForms.
Jadi, persentase pengkodean yang sebenarnya menggunakan %20
data formulir di URL adalah dalam bentuk yang dimodifikasi yang menggunakan +
. Jadi, Anda kemungkinan besar hanya melihat +
di URL dalam string kueri setelah ?
.
multipart/form-data
menggunakan penyandian MIME; application/x-www-form-urlencoded
menggunakan +
dan menggunakan URI yang disandikan dengan benar %20
.
http://www.bing.com/search?q=hello+world
dan sumber daya dengan ruang dalam namahttp://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
mailto:support@example.org?subject=I%20need%20help
,. Jika Anda mencobanya dengan +, email akan terbuka dengan + bukan spasi.
Kebingungan ini karena URL masih 'rusak' hingga hari ini.
Ambil " http://www.google.com " misalnya. Ini adalah URL. URL adalah Uniform Resource Locator dan benar-benar penunjuk ke halaman web (dalam kebanyakan kasus). URL sebenarnya memiliki struktur yang didefinisikan dengan sangat baik sejak spesifikasi pertama pada tahun 1994.
Kami dapat mengekstrak informasi terperinci tentang URL " http://www.google.com ":
+---------------+-------------------+
| Part | Data |
+---------------+-------------------+
| Scheme | http |
| Host | www.google.com |
+---------------+-------------------+
Jika kita melihat URL yang lebih kompleks seperti:
" https: // bob: bobby@www.lunatech.com: 8080 / file; p = 1? q = 2 # third "
kami dapat mengekstrak informasi berikut:
+-------------------+---------------------+
| Part | Data |
+-------------------+---------------------+
| Scheme | https |
| User | bob |
| Password | bobby |
| Host | www.lunatech.com |
| Port | 8080 |
| Path | /file;p=1 |
| Path parameter | p=1 |
| Query | q=2 |
| Fragment | third |
+-------------------+---------------------+
https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third
\___/ \_/ \___/ \______________/ \__/\_______/ \_/ \___/
| | | | | | \_/ | |
Scheme User Password Host Port Path | | Fragment
\_____________________________/ | Query
| Path parameter
Authority
Karakter yang dipesan berbeda untuk setiap bagian.
Untuk HTTP URL, spasi di bagian fragmen path harus dikodekan ke "% 20" (tidak, sama sekali bukan "+"), sedangkan karakter "+" di bagian fragmen path dapat dibiarkan tidak disandi.
Sekarang di bagian permintaan, spasi dapat dikodekan ke "+" (untuk kompatibilitas mundur: jangan mencoba mencarinya dalam standar URI) atau "% 20" sedangkan karakter "+" (sebagai akibat dari ambiguitas ini ) harus diloloskan ke "% 2B".
Ini berarti bahwa string "biru + biru muda" harus dikodekan secara berbeda di jalur dan bagian permintaan:
" http://example.com/blue+light%20blue?blue%2Blight+blue ".
Dari sana Anda dapat menyimpulkan bahwa pengkodean URL yang dibangun sepenuhnya tidak mungkin dilakukan tanpa kesadaran sintaksis terhadap struktur URL.
Ini bermuara pada:
Anda harus memiliki %20
sebelum ?
dan +
sesudah.
key1=value1&key1=value2
mana kunci dan nilai dikodekan dengan aturan apa pun yang encodeURIComponent
mengikuti tetapi AFAIK konten bagian permintaan sepenuhnya 100% hingga aplikasi. Selain itu hanya pergi ke yang pertama #
tidak ada pengkodean resmi.
Saya akan merekomendasikan %20
.
Apakah Anda mengkodekan mereka?
Ini tidak terlalu konsisten di semua bahasa. Jika saya tidak salah, dalam PHP urlencode()
memperlakukan spasi sebagai +
sedangkan Python urlencode()
memperlakukannya sebagai %20
.
EDIT:
Sepertinya saya salah. Python urlencode()
(setidaknya dalam 2.7.2) menggunakan quote_plus()
alih-alih quote()
dan dengan demikian mengkodekan spasi sebagai "+". Tampaknya juga bahwa rekomendasi W3C adalah "+" seperti di sini: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
Dan faktanya, Anda dapat mengikuti debat menarik tentang pelacak masalah Python sendiri tentang apa yang harus digunakan untuk menyandikan spasi: http://bugs.python.org/issue13866 .
EDIT # 2:
Saya mengerti bahwa cara paling umum untuk menyandikan "" adalah sebagai "+", tetapi hanya sebuah catatan, mungkin hanya saya, tetapi saya merasa ini agak membingungkan:
import urllib
print(urllib.urlencode({' ' : '+ '})
>>> '+=%2B+'
URLEncoder.encode()
metode di Jawa mengubahnya +
juga.
Ruang hanya dapat disandikan ke "+" di bagian "permintaan-jenis-tipe-nilai-pasangan" dari aplikasi / x-www-form-urlencoded "dari suatu URL. Menurut pendapat saya, ini MUNGKIN, bukan HARUS. Di sisa URL, itu dikodekan sebagai% 20.
Menurut pendapat saya, lebih baik untuk selalu menyandikan spasi sebagai% 20, bukan sebagai "+", bahkan di bagian permintaan URL, karena itu adalah spesifikasi HTML (RFC-1866) yang menentukan bahwa karakter spasi harus dikodekan sebagai " + "in" application / x-www-form-urlencoded "pasangan nilai kunci tipe konten (lihat paragraf 8.2.1. subparagraf 1.)
Cara pengkodean data formulir ini juga diberikan dalam spesifikasi HTML yang lebih baru. Misalnya, cari paragraf yang relevan tentang aplikasi / x-www-form-urlencoded di Spesifikasi HTML 4.01, dan seterusnya.
Berikut ini contoh string dalam URL di mana spesifikasi HTML memungkinkan ruang penyandian sebagai nilai tambah: " http://example.com/over/there?name=foo+bar ". Jadi, hanya setelah "?", Spasi dapat diganti dengan plus . Dalam kasus lain, spasi harus dikodekan ke% 20. Tapi karena sulit untuk menentukan konteks dengan benar, 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 / "-" / "." / "_" / "~"
Implementasinya tergantung pada bahasa pemrograman yang Anda pilih.
Jika URL Anda berisi karakter nasional, pertama-tama kodekan untuk UTF-8 dan kemudian persen-kodekan hasilnya.