URL Query String คืออะไร? ถอดรหัส ? และ & ที่คุณเห็นทุกวันแต่ไม่เคยสนใจ

ลองนึกภาพว่าคุณเปิด Shopee ค้นหาคำว่า "หูฟังบลูทูธ" แล้วกรองราคา 0–500 บาท เรียงจากน้อยไปมาก แถบ URL ด้านบนเบราว์เซอร์จะกลายเป็นขยะยาวเหยียดแบบนี้:

https://shopee.co.th/search?keyword=%E0%B8%AB%E0%B8%B9%E0%B8%9F%E0%B8%B1%E0%B8%87%E0%B8%9A%E0%B8%A5%E0%B8%B9%E0%B8%97%E0%B8%B9%E0%B8%98&priceMin=0&priceMax=500&sortBy=price_asc

คุณอาจไม่เคยอ่านมัน แต่เว็บไซต์อ่าน และนั่นคือจุดเริ่มต้นของเรื่องที่เราจะเล่ากันวันนี้

URL Query String คืออะไร และทำไมต้องมี ?

พูดง่ายที่สุด URL query string คือ ส่วนที่ใช้ส่งข้อมูลเพิ่มเติมไปยังเซิร์ฟเวอร์ โดยเริ่มต้นด้วยเครื่องหมาย ? แล้วตามด้วยคู่ key=value คั่นด้วย &

ดูตัวอย่างง่ายๆ:

https://example.com/search?q=python&page=2

แยกส่วนได้ดังนี้:

• q=python → ค้นหาคำว่า python
• page=2 → หน้า 2

เครื่องหมาย ? ทำหน้าที่เหมือน "ประตู" บอกว่าหลังจากนี้ไม่ใช่ path ของหน้าเว็บแล้ว แต่เป็นพารามิเตอร์ที่จะส่งไปให้เซิร์ฟเวอร์ ส่วน & คือ "จุลภาค" คั่นแต่ละพารามิเตอร์ไม่ให้ปนกัน

ทำไมต้องใช้ ? และ & ไม่ใช่ตัวอักษรอื่น?

เพราะ URL ถูกออกแบบมาตั้งแต่ปี 1994 (RFC 1738) ให้ใช้ ASCII เท่านั้น อักขระพิเศษถูกจองไว้ทำหน้าที่เฉพาะ เช่น / คือ path, # คือ fragment, : คือ port ส่วน ? และ & ก็ถูกเลือกมาเป็นตัวคั่นพารามิเตอร์ มันไม่ใช่อะไรที่สวยงาม แต่มันทำงานได้และเป็นมาตรฐานเดียวที่เบราว์เซอร์ทุกตัวเข้าใจ

URL Encoding — ทำไมภาษาไทยกลายเป็น %E0%B8%

กลับมาที่ตัวอย่าง Shopee ทำไมคำว่า "หูฟัง" ถึงกลายเป็น %E0%B8%AB%E0%B8%B9%E0%B8%9F%E0%B8%B1%E0%B8%87?

เพราะ URL รองรับเฉพาะ ASCII ภาษาไทย อิโมจิ หรืออักขระพิเศษจึงต้องถูก "เข้ารหัส" (percent-encoding) ก่อนส่ง โดยแปลงเป็น UTF-8 ก่อน แล้วเขียนแต่ละ byte ในรูป %XX

ตัวอย่าง:

• อักษร "ห" → UTF-8 bytes คือ E0 B8 AB → กลายเป็น %E0%B8%AB
• ช่องว่าง → %20 หรือบางครั้งเบราว์เซอร์แสดงเป็น +
• & ถ้าอยู่ในค่าพารามิเตอร์ → %26 (ไม่งั้นจะถูกตีความเป็นตัวคั่น)

นี่คือเหตุผลที่ URL ที่มีภาษาไทยดูยาวและน่ากลัว แต่จริงๆ แล้วเบราว์เซอร์และเซิร์ฟเวอร์ถอดรหัสกลับได้โดยอัตโนมัติ

ทดลองเองใน 30 วินาที

ลองเปิด console ในเบราว์เซอร์ (F12) แล้วพิมพ์:

encodeURIComponent("หูฟังบลูทูธ")
// ผล: "%E0%B8%AB%E0%B8%B9%E0%B8%9F%E0%B8%B1%E0%B8%87%E0%B8%9A%E0%B8%A5%E0%B8%B9%E0%B8%97%E0%B8%B9%E0%B8%98"

decodeURIComponent("%E0%B8%AB%E0%B8%B9%E0%B8%9F")
// ผล: "หูฟัง"

เข้าใจแล้วใช่ไหมว่าทำไม URL ภาษาไทยถึงดูเป็นรหัสลับ

API Endpoint และ RESTful URL แบบเข้าใจง่าย

ถ้าคุณเคยเรียก API คุณจะเจอ URL แบบนี้:

GET https://api.example.com/v1/users/123/posts?status=published&limit=10

อ่านออกมาเป็นภาษาคนได้ว่า: "ดึงโพสต์ของ user id 123 ที่มีสถานะ published จำกัด 10 รายการ"

นี่คือแนวคิดของ RESTful URL ที่พยายามทำให้ URL อ่านได้เหมือนประโยค โดยแบ่งเป็น:

• Path parameter (/users/123) → ระบุ resource เฉพาะเจาะจง
• Query string (?status=published&limit=10) → กรอง/ควบคุมผลลัพธ์

กฎทอง: ใช้ path บอกว่า "อะไร" ใช้ query string บอกว่า "อย่างไร"

สิ่งที่อยากทำ	วางไว้ที่ไหน	ตัวอย่าง
ระบุ resource	path	/users/123
กรองข้อมูล	query	?role=admin
จำกัดจำนวน	query	?limit=10
เรียงลำดับ	query	?sort=created_at
แบ่งหน้า	query	?page=2

วิธีอ่าน URL แล้วรู้ว่าเว็บกำลังส่งข้อมูลอะไร

มาฝึกกันจริงๆ ลองอ่าน URL นี้แล้วบอกได้ว่าเว็บกำลังทำอะไร:

https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=43s&list=PLrAXtmRdnEQy6nuLMHjMZOz59Oq8B9k1F

แยกส่วน:

• watch → หน้าดูวิดีโอ
• v=dQw4w9WgXcQ → วิดีโอ ID (ใครๆ ก็รู้ว่าคลิปอะไร)
• t=43s → เริ่มเล่นที่วินาทีที่ 43
• list=PLrAXtm... → เล่นในเพลย์ลิสต์นี้

เพียงแค่อ่าน query string คุณก็รู้ว่าเว็บกำลังจะแสดงอะไรให้คุณ โดยไม่ต้องกดเข้าไป

ฝึกอีกตัวอย่าง

https://github.com/facebook/react/issues?q=is:issue+is:open+label:"good first issue"

อ่านได้ว่า: ค้นหา issue ที่เปิดอยู่ และมี label "good first issue" ใน repo react ของ facebook

นี่คือพลังของ query string — มันทำให้ URL กลายเป็น "สถานะ" ที่แชร์ต่อได้ คุณสามารถ copy ส่งให้เพื่อน แล้วเพื่อนเห็นหน้าเว็บเหมือนกันทุกประการ

ความปลอดภัย — ข้อมูลที่ไม่ควรอยู่ใน URL

นี่คือส่วนที่หลายคนมองข้าม และอันตรายมาก

เพราะ URL ถูกบันทึกในหลายที่:

• ประวัติเบราว์เซอร์
• Log ของเซิร์ฟเวอร์ (access log)
• Referer header ที่ส่งไปเว็บอื่นเวลาคลิกลิงก์ออก
• Bookmark ที่ซิงค์ข้ามอุปกรณ์
• ส่งต่อในแชตได้โดยไม่รู้ตัว

ดังนั้น อย่าใส่ข้อมูลเหล่านี้ใน query string เด็ดขาด:

1. รหัสผ่าน — ดูจะชัดเจน แต่ยังมี API เก่าๆ ที่ทำ ?password=abc123
2. Token ยืนยันตัวตน — เช่น ?token=eyJhbGci... ถ้ามีคนเห็น URL ก็ใช้ token นั้นได้
3. ข้อมูลส่วนบุคคล — เช่น ?id=1101234567890 (เลขบัตรประชาชน)
4. ข้อมูลการเงิน — เช่น ?creditCard=4111111111111111
5. Session ID — บางระบบเก่ายังส่ง session ผ่าน URL ทำให้ถูกขโมย session ได้ (session hijacking)

กรณีศึกษา: รหัสยืนยันใน URL

เคยเห็นอีเมลยืนยันสมัครที่ลิงก์เป็นแบบนี้ไหม?

https://app.example.com/verify?token=abc123secret456

ดูสะดวก แต่ถ้าผู้ใช้คลิกลิงก์นั้นแล้วเว็บโหลดรูปจาก domain อื่น (เช่น tracking pixel) header Referer จะส่ง URL เต็มๆ ไป รวมถึง token ด้วย ทำให้ token รั่วไหลโดยไม่ตั้งใจ

วิธีที่ปลอดภัยกว่า:

• ใช้ POST แทน GET สำหรับข้อมูลละเอียดอ่อน
• เก็บ token ใน HTTP-only cookie
• ใช้ short-lived token ที่หมดอายุใน 15 นาที
• ใช้ PKCE flow สำหรับ OAuth

สรุป: URL ไม่ใช่แค่ที่อยู่ แต่เป็นข้อความ

ทุกครั้งที่คุณเห็น ? ใน URL ให้นึกถึงประโยค "ส่งข้อมูลนี้ไปด้วย" ทุกครั้งที่เห็น & ให้นึกถึงจุลภาคคั่นรายการ และทุกครั้งที่เห็น %E0%B8% ให้รู้ว่านั่นคือภาษาไทยที่ถูกแปลงเพื่อให้ URL ทำงานได้

เข้าใจ query string แล้ว คุณจะอ่าน URL ออก เขียน API ได้ถูกต้อง และหลีกเลี่ยงการรั่วไหลของข้อมูลโดยไม่ตั้งใจ

ลองฝึกกันเลย

เปิดเว็บที่คุณใช้บ่อยๆ (Google, YouTube, GitHub) แล้วสังเกต URL ลองเปลี่ยนค่า query string ด้วยมือ ดูว่าเว็บตอบสนองยังไง นี่คือวิธีเรียนรู้ที่เร็วที่สุด

หรือถ้าคุณกำลังเขียนเว็บ ลองใช้ URLSearchParams ใน JavaScript:

const params = new URLSearchParams(window.location.search)
console.log(params.get('q'))        // ค่าพารามิเตอร์ q
console.log(params.has('page'))     // มี page อยู่ไหม
params.set('page', '3')             // เปลี่ยนค่า
console.log(params.toString())      // ได้ string พร้อมส่ง

ง่ายกว่าที่คิดใช่ไหม?

คำถามชวนคุย: คุณเคยเจอ URL ที่ยาวจนน่ากลัวที่สุดเป็นเว็บอะไร และคุณคิดว่ามันส่งข้อมูลอะไรไปบ้าง? มาแชร์กันในคอมเมนต์ได้เลย