URL yang menyandikan karakter spasi: + atau% 20?

Kapan ruang dalam URL disandikan +, dan kapan ruang itu disandikan %20?

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 %20data formulir di URL adalah dalam bentuk yang dimodifikasi yang menggunakan +. Jadi, Anda kemungkinan besar hanya melihat +di URL dalam string kueri setelah ?.

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: [email protected]: 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:[email protected]: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 %20sebelum ?dan +sesudah.

Sumber

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+'

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.