Hiểu và tránh các ký tự dễ gây nhầm lẫn về mặt thị giác trong ID

 (gajus.com)
4 điểm bởi GN⁺ 2024-04-24 | 3 bình luận | Chia sẻ qua WhatsApp

Hiểu các ký tự dễ gây nhầm lẫn về mặt thị giác trong ID

  • Ký tự dễ gây nhầm lẫn về mặt thị giác là những ký tự khó phân biệt trong một số phông chữ hoặc chữ viết tay nhất định
    • O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g là các ví dụ điển hình
  • Những ký tự này có thể gây ra lỗi và sự nhầm lẫn khi nhập dữ liệu
    • Ví dụ, người dùng khó phân biệt giữa 'O' và '0' nên nhập sai mã, dẫn đến trải nghiệm người dùng kém
  • Điều này đặc biệt quan trọng trong các tình huống ID được truyền đạt bằng lời nói hoặc phải viết tay
    • như hỗ trợ khách hàng, mã giảm giá, mã theo dõi, error ID, product ID, v.v.

Quyết định có phân biệt chữ hoa chữ thường hay không

  • Cần quyết định liệu ID có phân biệt chữ hoa chữ thường hay không
    • Nếu phân biệt chữ hoa chữ thường và loại bỏ tính mơ hồ thị giác, số ký tự có thể chọn là 53
    • Nếu không phân biệt chữ hoa chữ thường, số ký tự có thể chọn là 22
  • Nếu độ dài ID là 5 ký tự, số lượng ID có thể có là:
    • Phân biệt chữ hoa chữ thường: 53^5 = 418,195,493
    • Không phân biệt chữ hoa chữ thường: 22^5 = 5,153,632
  • Tuy nhiên, khi độ dài ID tăng lên, số lượng ID khả dụng cũng tăng theo cấp số nhân
  • Vì vậy cần tìm điểm cân bằng giữa độ dài ID và khả năng xảy ra mơ hồ thị giác
  • Ngoài ra, nếu dùng cả chữ hoa lẫn chữ thường, có thể phát sinh những vấn đề ngoài dự kiến với các hệ thống bên thứ ba không phân biệt chữ hoa chữ thường

Tập ký tự rõ ràng về mặt thị giác

  • Nếu ưu tiên khả năng đọc, nên dùng tập ký tự sau:
    • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

Các điểm cần cân nhắc thêm

  • Một số tổ hợp ký tự có thể trông giống ký tự khác (ví dụ: rn trông như m, 3 trông như w)
    • Tốt nhất nên tránh các tổ hợp này ở bước tạo ID
  • Cũng nên tránh các ký tự có cách phát âm giống nhau (ví dụ: b và p)
    • Điều này đặc biệt quan trọng khi ID được truyền đạt bằng lời nói

Các trường hợp thực tế hiện có

  • Crockford's Base32: giải mã các ký tự mơ hồ thành cùng một giá trị, đồng thời cũng cân nhắc việc vô tình tạo ra từ ngữ tục tĩu
  • Open Location Code: sử dụng tập ký tự 23456789CFGHJMPQRVWX. Mục tiêu là tránh mơ hồ thị giác đồng thời tránh tạo thành từ trong các ngôn ngữ phổ biến. Tuy nhiên vẫn bao gồm 6/G và 9/Q.

Ý kiến của GN⁺

  • Khi tạo ID, cần ưu tiên hàng đầu cho tính dễ dùng và khả năng đọc, đặc biệt nếu ID thường xuyên phải được truyền miệng hoặc ghi chép bằng tay.
  • Nên chọn tập ký tự giúp giảm tối đa sự mơ hồ thị giác, đồng thời tìm được điểm cân bằng hợp lý giữa độ dài ID và số lượng tổ hợp có thể tạo ra.
  • Ngoài ra, khi tích hợp với hệ thống bên thứ ba, có thể phát sinh những vấn đề ngoài dự kiến, vì vậy cần cân nhắc cẩn thận việc có phân biệt chữ hoa chữ thường hay không.
  • Cũng cần xem xét thêm việc loại trừ một số tổ hợp ký tự nhất định trong logic tạo ID, hoặc tránh các ký tự có cách phát âm gần giống nhau.
  • Nên tham khảo các ví dụ như Crockford's Base32 hoặc Open Location Code để thiết kế tập ký tự tối ưu phù hợp với yêu cầu của dự án.

Bài viết liên quan

3 bình luận

 
roxie 2025-01-29

Cái này cũng có vẻ hay: https://stackoverflow.com/a/58098360/8556340
 
roxie 2025-01-29

Việc còn tính cả cách phát âm nữa thì thật sự quá kinh ngạc.
 
GN⁺ 2024-04-24
Ý kiến trên Hacker News
  • Có trường hợp ngoài thực tế đã dùng số sê-ri chứa các ký tự mơ hồ trên hàng triệu thiết bị, gây ra khó khăn rất lớn cho bộ phận hỗ trợ khách hàng. Họ đã trải qua cơn ác mộng là tạo ra các biến thể lỗi gõ bằng regex rồi đối chiếu với DB để suy đoán số sê-ri thực.
  • Cần dùng cách mã hóa khác nhau tùy theo người dùng. Base32 phù hợp vì có tập ký tự rõ ràng, và khi truyền đạt bằng lời nói thì nên dùng biểu diễn bằng danh sách từ (ví dụ: "TIDE ITCH SLOW REIN RULE MOT"). Tuy nhiên, có những cạm bẫy như thành ngữ, từ đồng âm và phương ngữ, nên đừng tự tạo danh sách từ riêng.
  • Từng nhận được yêu cầu hỗ trợ ngoài dự kiến vì một mô-đun tính toán cơ số tùy ý (Math::Fleximal) được đăng lên CPAN cho vui. Nguyên nhân là ai đó đã dùng mã demo chuyển đổi hệ thập lục phân sang mã chữ-số trong môi trường production.
  • Trong màn hình nhập số sê-ri DLC của Nintendo Switch, các phím ký tự gây mơ hồ được vô hiệu hóa để cải thiện UX.
  • Cũng nên tránh các ký tự khó phân biệt khi viết tay theo kiểu chữ thảo. Đặc biệt, '7' và '1' rất dễ bị nhầm.
  • Nếu dùng cả chữ hoa lẫn chữ thường, về sau bạn có thể gặp bất ngờ do những hệ thống hoặc giao thức không phân biệt hoa thường. Cũng có những hệ thống thương mại không coi đó là bug với lý do tiện cho người dùng.
  • Mỗi khi chép mã dự phòng 2FA ra giấy, cảm giác bất an lại ập đến với một số ký tự nhất định (o/0, v/u, 5/S, v.v.). Để tránh điều này, người ta đôi khi thêm nét trang trí vào ký tự.
  • Chọn từ thông dụng làm mật khẩu Wi‑Fi mà cả trẻ lớp 3 cũng có thể đánh vần chính xác, như "vacation".
  • KeepassXC dùng màu khác nhau cho từng loại ký tự (chữ hoa, chữ thường, số, ký hiệu, v.v.), giúp tăng đáng kể khả năng đọc.
  • Địa chỉ Bitcoin dùng mã hóa Base58 đã được chỉnh sửa.
  • Bài viết đã ghi nhầm phông chữ Arial thành Ariel.