เพิ่มพรีฟิกซ์ URL อัตโนมัติ - รายละเอียดเล็กๆ ที่ช่วยประหยัดเวลาได้หลายนาที

ในฟอร์มสำหรับย่อลิงก์ คุณจะได้ป้อน allegro.pl เครื่องมือย่อลิงก์ส่วนใหญ่จะแจ้งว่านี่ไม่ใช่ URL ที่ถูกต้อง และขอให้ป้อนใหม่โดยเติม https:// ไว้ด้านหน้า แต่ cutty.dev จะเพิ่ม https:// ให้เองและดำเนินการต่อ

นี่ดูเหมือนฟีเจอร์ที่แทบไม่คุ้มค่าที่จะเอ่ยถึง ในทางปฏิบัติ มันคือความแตกต่างระหว่าง:

• "วางลิงก์ ได้ลิงก์สั้นๆ ปิดหน้าต่าง" (2 วินาที)
• "วางลิงก์ เกิดข้อผิดพลาด อ่านข้อความแจ้งเตือน เพิ่ม https ลองอีกครั้ง ได้ลิงก์" (15-20 วินาที)

คูณด้วยจำนวนครั้งที่คุณวาง URL ในหนึ่งเดือน บวกกับความหงุดหงิดจากการอ่านข้อความแสดงข้อผิดพลาด บวกกับช่วงเวลาแห่งความเข้าใจว่า “อ๋อ ใช่แล้ว โปรโตคอล” เรื่องเล็กน้อยที่วัดผลได้เป็นนาทีต่อคนต่อเดือน

Cutty.dev ทำงานอย่างไรอย่างละเอียด

คุณได้วางข้อความลงในแบบฟอร์ม ก่อนที่จะส่งไปยังเซิร์ฟเวอร์ JavaScript จะตรวจสอบว่าข้อความเริ่มต้นด้วยโปรโตคอลใด ๆ (http://, https://, ftp://, mailto: ฯลฯ) หรือไม่ หาก ไม่ เริ่มต้นด้วยโปรโตคอล ระบบจะสันนิษฐานว่าเป็นเพียงโดเมนที่ไม่มีโปรโตคอล และจะเพิ่ม https:// ไว้ด้านหน้า

นั่นคือ:

• allegro.pl → https://allegro.pl
• github.com/twoj-profil/projekt → https://github.com/twoj-profil/projekt
• www.gazeta.pl → https://www.gazeta.pl

และหากโปรโตคอล มีอยู่แล้ว (แม้ว่าจะไม่ถูกต้องก็ตาม) ระบบจะคงไว้ตามเดิมและตรวจสอบต่อไป:

• http://example.com → คงเป็น http://example.com (อนุญาต)
• ftp://example.com → ปฏิเสธ (เฉพาะ http/https)
• javascript:alert(1) → ปฏิเสธ (การป้องกัน XSS)

ทำไมฉันถึงมี แต่คนอื่นไม่มี

เครื่องตัดความยาวลิงก์ส่วนใหญ่มีการตรวจสอบ URL แบบมาตรฐานผ่าน new URL(string) คอนสตรัคเตอร์ URL ในเบราว์เซอร์/JavaScript เป็นแบบ strict — หากไม่มีโปรโตคอลจะเกิดข้อผิดพลาด ผลลัพธ์เริ่มต้นสำหรับ new URL("allegro.pl") คือ TypeError

นี่เป็นพฤติกรรมที่ถูกต้องสำหรับแอปพลิเคชันส่วนใหญ่ แต่สำหรับฟอร์มย่อลิงก์ ซึ่งผู้ใช้จะวาง URL ที่คัดลอกมาจากแถบที่อยู่หรือจากแอปอื่น ความเข้มงวดนี้คือ อุปสรรคแทนที่จะเป็นตัวช่วย

คำตอบใช้เวลาเพียงห้าบรรทัดของ JavaScript:

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalsza walidacja przez new URL(normalized)
}

โค้ดเพียงห้าบรรทัด ลดความหงุดหงิดของผู้ใช้แต่ละคนได้หลายสิบวินาทีต่อวัน ไม่รู้ว่าทำไมตลาดส่วนใหญ่ถึงไม่ทำกัน บางทีเพราะคำว่า “มาตรฐาน” หมายถึง “ตัวสร้าง URL ทำงานแบบนี้”

รายละเอียดเล็กๆ ใน UX มีความสำคัญเกินสัดส่วน

cutty.dev มีฟีเจอร์หลายอย่างที่ไม่ได้ระบุไว้ในรายการฟีเจอร์ใดๆ เพราะเมื่อพิจารณาแต่ละอย่างแยกกัน ดูเหมือนจะเล็กน้อย

• ตัดช่องว่าง (whitespace) ก่อนการตรวจสอบความถูกต้อง — URL ที่วางเข้ามาพร้อมช่องว่างท้ายบรรทัดจะไม่ทำให้เกิดข้อผิดพลาด
• Hash ถูกเก็บไว้ — https://example.com/page#section จะคงค่า #section ไว้หลังจากการย่อลิงก์
• Query strings ถูกเก็บไว้ — ?utm_source=test จะผ่านกระบวนการโดยไม่ถูกตัดออก
• อัปเกรดโปรโตคอลอัตโนมัติ — เปลี่ยน http:// เป็น https: เมื่อ URL ต้นทางรองรับ TLS (อยู่ในแผน ยังไม่เปิดใช้งานจริง)
• โดเมน IDN — źdźbło.pl จะถูกแปลงเป็น Punycode โดยอัตโนมัติ
• อักขระภาษาโปลิชใน slug — จะถูกแปลงเป็น ASCII อัตโนมัติเมื่อสร้างส่วนท้ายของลิงก์เอง (różowy-link → rozowy-link)
• ตรวจจับโปรโตคอลที่เป็นอันตราย — javascript:, data:, file:, mailto: จะถูกปฏิเสธพร้อมข้อความแจ้งเตือนเฉพาะ

รายละเอียดแต่ละส่วนนี้ช่วยประหยัดเวลาให้ใครสักคนได้ 5–30 วินาที และลดความหงุดหงิดในขณะนั้นลง เมื่อรวมกันแล้ว มันคือความแตกต่างระหว่าง “ฉันชอบแอปนี้” กับ “ใช้งานได้ดี”

แล้ว UX ของรายละเอียดจะเป็นอย่างไรต่อ

รายการสิ่งที่อยากทำในอนาคต:

• Smart paste — ตรวจจับเมื่อผู้ใช้วางข้อความที่มี URL อยู่ท่ามกลางคำอื่น ๆ และแยกเฉพาะ URL ออกมา
• Bulk paste — การวางรายการ URL (หนึ่งต่อหนึ่งต่อบรรทัด) จะสร้างลิงก์สั้น ๆ หลายรายการพร้อมกัน
• Suggested slugs — จากชื่อของหน้าปลายทาง ให้เสนอส่วนท้ายแบบมีแบรนด์ 3 แบบให้เลือก
• Auto-OG preview — แสดงตัวอย่างการ์ด Open Graph ทันทีหลังจากวาง URL ก่อนที่จะทำการย่อ

แต่ละอันก็เป็น “ฟังก์ชันห้าบรรทัดที่ดูไร้ค่า” เช่นกัน ทั้งหมดนี้ต่างกันระหว่างเครื่องมือที่ “พอใช้ได้” กับเครื่องมือที่คุณอยากใช้ทุกวัน

ลองทำเอง

วางสิ่งใดสิ่งหนึ่ง — allegro.pl หรือ github.com หรือ news.ycombinator.com ระบบจะเพิ่มโปรโตคอลให้เองและดำเนินการต่อ ไม่ต้องรอ ไม่มีข้อผิดพลาด และไม่ต้องมีข้อความ “ลองอีกครั้ง”

หากคุณสนใจรายละเอียด UX ประเภทนี้ — แจ้งให้เราทราบว่าคุณต้องการให้ไปทางไหนต่อ hello@cutty.dev