4 คะแนน โดย GN⁺ 2024-04-24 | 3 ความคิดเห็น | แชร์ทาง WhatsApp

ทำความเข้าใจอักขระที่กำกวมทางสายตาใน ID

  • อักขระที่กำกวมทางสายตาหมายถึงอักขระที่แยกแยะได้ยากในฟอนต์บางแบบหรือลายมือ
    • เช่น O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g
  • อักขระเหล่านี้อาจก่อให้เกิดข้อผิดพลาดและความสับสนระหว่างการป้อนข้อมูล
    • เช่น ผู้ใช้แยกไม่ออกระหว่าง 'O' กับ '0' จึงกรอกรหัสผิด ส่งผลให้ประสบการณ์ผู้ใช้ไม่ดี
  • เรื่องนี้สำคัญเป็นพิเศษในสถานการณ์ที่ต้องสื่อสาร ID ด้วยวาจาหรือเขียนด้วยมือ
    • เช่น ฝ่ายบริการลูกค้า, โค้ดส่วนลด, รหัสติดตาม, error ID, product ID เป็นต้น

การตัดสินใจว่าจะให้แยกตัวพิมพ์เล็ก-ใหญ่หรือไม่

  • ต้องตัดสินใจก่อนว่า ID จะต้องแยกตัวพิมพ์เล็ก-ใหญ่หรือไม่
    • หากแยกตัวพิมพ์เล็ก-ใหญ่ และตัดอักขระที่กำกวมทางสายตาออก จะเหลืออักขระให้เลือก 53 ตัว
    • หากไม่แยกตัวพิมพ์เล็ก-ใหญ่ จะเหลืออักขระให้เลือก 22 ตัว
  • หาก ID มีความยาว 5 ตัว จำนวน ID ที่เป็นไปได้คือ:
    • แยกตัวพิมพ์เล็ก-ใหญ่: 53^5 = 418,195,493 แบบ
    • ไม่แยกตัวพิมพ์เล็ก-ใหญ่: 22^5 = 5,153,632 แบบ
  • อย่างไรก็ตาม เมื่อความยาวของ ID เพิ่มขึ้น จำนวน ID ที่เป็นไปได้จะเพิ่มขึ้นแบบทวีคูณ
  • ดังนั้นจึงต้องหาจุดสมดุลระหว่างความยาวของ ID กับโอกาสเกิดความกำกวมทางสายตา
  • นอกจากนี้ หากใช้ทั้งตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ อาจเกิดปัญหาที่คาดไม่ถึงกับระบบของ third-party ที่ไม่แยกตัวพิมพ์เล็ก-ใหญ่

ชุดอักขระที่มองเห็นชัดเจน

  • หากให้ความสำคัญกับความอ่านง่ายเป็นอันดับแรก แนะนำให้ใช้ชุดอักขระดังต่อไปนี้:
    • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

ข้อพิจารณาเพิ่มเติม

  • ชุดอักขระบางแบบเมื่อวางติดกันอาจดูเหมือนเป็นอักขระอื่นได้ (เช่น rn ดูเหมือน m, 3 ดูเหมือน w)
    • จึงควรหลีกเลี่ยงชุดดังกล่าวตั้งแต่ขั้นตอนสร้าง ID
  • ควรหลีกเลี่ยงอักขระที่ออกเสียงคล้ายกันด้วย (เช่น b กับ p)
    • สำคัญเป็นพิเศษเมื่อมีการสื่อสาร ID ด้วยวาจา

กรณีศึกษาที่มีอยู่แล้ว

  • Crockford's Base32: ถอดรหัสอักขระที่กำกวมให้เป็นค่าเดียวกัน และยังคำนึงถึงคำหยาบที่อาจเกิดขึ้นโดยไม่ตั้งใจ
  • Open Location Code: ใช้ชุดอักขระ 23456789CFGHJMPQRVWX โดยตั้งใจหลีกเลี่ยงทั้งความกำกวมทางสายตาและการเกิดเป็นคำในภาษาทั่วไป แม้จะยังมี 6/G, 9/Q รวมอยู่ด้วย

ความเห็นของ GN⁺

  • ในการสร้าง ID ควรให้ความสำคัญกับการใช้งานและความอ่านง่ายเป็นอันดับแรก โดยเฉพาะเมื่อมีกรณีที่ต้องสื่อสาร ID ด้วยวาจาหรือจดบันทึกด้วยมืออยู่บ่อยครั้ง
  • ควรเลือกชุดอักขระที่ช่วยลดความกำกวมทางสายตาให้มากที่สุด พร้อมหาจุดสมดุลที่เหมาะสมระหว่างความยาวของ ID กับจำนวนชุดค่าที่เป็นไปได้
  • อีกทั้งการเชื่อมต่อกับระบบ third-party อาจทำให้เกิดปัญหาที่ไม่คาดคิดได้ จึงควรตัดสินใจเรื่องการแยกตัวพิมพ์เล็ก-ใหญ่ให้รอบคอบ
  • นอกจากนี้ยังควรพิจารณาเพิ่มเติม เช่น การตัดชุดอักขระบางแบบออกจากตรรกะการสร้าง ID หรือหลีกเลี่ยงอักขระที่ออกเสียงคล้ายกัน
  • การอ้างอิงกรณีอย่าง Crockford's Base32 หรือ Open Location Code เพื่อนำมาออกแบบชุดอักขระที่เหมาะกับความต้องการของโปรเจกต์ ถือเป็นแนวทางที่เหมาะสม

3 ความคิดเห็น

 
roxie 2025-01-29

อันนี้ก็ดูน่าสนใจเหมือนกันครับ : https://stackoverflow.com/a/58098360/8556340

 
roxie 2025-01-29

น่าทึ่งจริง ๆ ที่คำนึงถึงแม้กระทั่งการออกเสียง

 
GN⁺ 2024-04-24
ความเห็นจาก Hacker News
  • มีกรณีใช้งานจริงที่ใช้หมายเลขซีเรียลซึ่งมีอักขระกำกวมกับอุปกรณ์หลายล้านเครื่อง จนสร้างความลำบากอย่างมากให้กับฝ่ายซัพพอร์ตลูกค้า เคยเจอประสบการณ์เหมือนฝันร้ายที่ต้องสร้างรูปแบบการพิมพ์ผิดด้วย regex แล้วนำไปเทียบกับฐานข้อมูลเพื่อเดาหมายเลขซีเรียลจริง
  • ควรใช้วิธีเข้ารหัสให้ต่างกันตามผู้ใช้ Base32 เหมาะสมเพราะมีชุดอักขระที่ชัดเจน และเมื่อสื่อสารด้วยปากเปล่าก็ควรใช้การแทนด้วยรายการคำ (เช่น "TIDE ITCH SLOW REIN RULE MOT") แต่ต้องระวังกับดักอย่างสำนวน คำพ้องเสียง และภาษาถิ่น ดังนั้นอย่าสร้างรายการคำใช้เอง
  • เคยได้รับคำขอซัพพอร์ตแบบไม่คาดคิดจากโมดูลคำนวณเลขฐานตามใจที่อัปขึ้น CPAN เล่น ๆ (Math::Fleximal) สาเหตุคือมีคนนำโค้ดเดโมที่แปลงเลขฐานสิบหกเป็นโค้ดตัวอักษรและตัวเลขไปใช้ในโปรดักชัน
  • ในหน้าจอกรอกหมายเลขซีเรียล DLC ของ Nintendo Switch มีการปิดใช้งานปุ่มของอักขระที่กำกวมเพื่อปรับปรุง UX
  • ควรหลีกเลี่ยงอักขระที่แยกแยะได้ยากเมื่อเขียนด้วยลายมือด้วย โดยเฉพาะ '7' กับ '1' ที่สับสนกันได้ง่าย
  • ถ้าใช้ทั้งตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก วันหนึ่งคุณอาจเจอปัญหาจากระบบหรือโปรโตคอลที่ไม่แยกตัวพิมพ์ใหญ่เล็กภายหลัง และยังมีระบบเชิงพาณิชย์ที่ไม่ถือว่านี่เป็นบั๊กด้วยเหตุผลด้านความสะดวกของผู้ใช้
  • ทุกครั้งที่จดโค้ดสำรอง 2FA ลงบนกระดาษก็จะรู้สึกกังวลกับอักขระบางคู่เสมอ เช่น o/0, v/u, 5/S จึงมักเติมเครื่องหมายตกแต่งให้ตัวอักษรเพื่อหลีกเลี่ยงปัญหา
  • เลือกรหัสผ่าน Wi‑Fi เป็นคำทั่วไปในชีวิตประจำวันอย่าง "vacation" ที่แม้แต่เด็กประถมปี 3 ก็สะกดได้ถูกต้อง
  • KeepassXC ใช้สีต่างกันตามประเภทอักขระ (ตัวพิมพ์ใหญ่ ตัวพิมพ์เล็ก ตัวเลข สัญลักษณ์ ฯลฯ) ทำให้อ่านได้ง่ายขึ้นมาก
  • ที่อยู่ Bitcoin ใช้การเข้ารหัส Base58 แบบดัดแปลง
  • ในบทความเขียนชื่อฟอนต์ Arial ผิดเป็น Ariel