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
  • Trong các quy trình con người đọc và truyền đạt ID như báo lỗi, nhập mã giảm giá, theo dõi giao hàng, sự mơ hồ về mặt thị giác như O/0, I/l/1/7 rất dễ dẫn đến lỗi nhập liệu
  • Mức độ nhầm lẫn tăng lên tùy theo phông chữ và chữ viết tay; các cặp khó phân biệt như 5/S, 2/Z, 8/B, 6/G, 9/q/g xuất hiện lặp lại
  • Với các ID do con người trực tiếp xử lý như hỗ trợ khách hàng, ID lỗi, ID sản phẩm, việc chọn tập ký tự dễ đọc quan trọng hơn đối với chất lượng sử dụng thực tế so với việc mù quáng dùng một tập ký tự lớn
  • Nếu phân biệt chữ hoa/thường, ID 5 ký tự có thể tạo 418,195,493 tổ hợp, nhưng nếu không phân biệt thì giảm xuống 5,153,632, nên cần đánh đổi giữa độ dài và tính an toàn
  • ID phân biệt chữ hoa/thường dễ tạo ngắn hơn, nhưng một số hệ thống hoặc giao thức bên thứ ba có thể hoạt động theo kiểu không phân biệt chữ hoa/thường, gây vấn đề ở bước tích hợp

Nhầm lẫn ký tự trong ID do con người đọc

  • Khi viết hoặc truyền đạt ID trong các tương tác hệ thống như báo cáo lỗi, nhập mã giảm giá, theo dõi giao hàng, những nhầm lẫn ký tự có thể tránh được có thể làm hỏng trải nghiệm người dùng
  • Các nhóm ký tự mơ hồ về mặt thị giác tiêu biểu như sau
    • O / 0: với số 0 không có gạch chéo hoặc dấu chấm, chữ O và số 0 có thể trông giống nhau
    • I / l / 1 / 7: chữ hoa I, chữ thường l, số 1, số 7 khó phân biệt trong nhiều bản in và chữ viết tay
    • 5 / S, 2 / Z, 8 / B, 6 / G, 9 / q / g: có thể bị nhầm lẫn trong một số phông chữ, phông chữ cách điệu hoặc chữ viết tay
  • Chuỗi ví dụ 9qg6G8B2Z5SIl170O được dùng làm đối tượng so sánh trong nhiều phông chữ hệ thống như Arial, Helvetica, Courier, Times, Verdana, Georgia, Tahoma, Impact, Comic Sans
  • Một số cặp như I và l có thể tiếp tục trông mơ hồ trong nhiều phông chữ, và cũng có những tổ hợp như 9qg còn dễ nhầm hơn khi viết tay trực tiếp

    • Các loại ID đặc biệt dễ gặp vấn đề

    • Mã giảm giá được trao đổi trong hỗ trợ khách hàng
    • Mã theo dõi dùng trong giao hàng hoặc logistics
    • ID lỗi cần thiết để tái hiện vấn đề và xử lý yêu cầu hỗ trợ
    • ID sản phẩm dùng để nhận diện sản phẩm

Đánh đổi giữa phân biệt chữ hoa/thường và tập ký tự

  • Việc ID có coi abc và ABC là cùng một giá trị hay không cần được quyết định cùng lúc khi đặt quy tắc sinh ID
  • Nếu phân biệt chữ hoa/thường và loại trừ các ký tự mơ hồ về mặt thị giác, số ký tự có thể chọn là 53
  • Nếu không phân biệt chữ hoa/thường, số ký tự có thể chọn giảm xuống còn 22
  • Số tổ hợp có thể có theo độ dài ID như sau
    • 5 ký tự, phân biệt chữ hoa/thường: 53^5 = 418,195,493
    • 5 ký tự, không phân biệt chữ hoa/thường: 22^5 = 5,153,632
    • 8 ký tự, phân biệt chữ hoa/thường: 53^8 = 62,259,690,411,361
    • 8 ký tự, không phân biệt chữ hoa/thường: 22^8 = 54,875,873,536
  • Cuối cùng, lựa chọn là cân bằng giữa ID ngắn nhưng có khả năng gây nhầm lẫn cao và ID dài nhưng dễ đọc
  • Nếu dùng cả chữ hoa và chữ thường, một lúc nào đó bạn có thể gặp hành vi ngoài dự kiến trong hệ thống hoặc giao thức bên thứ ba không phân biệt chữ hoa/thường
    • Một hệ thống thương mại từng cho phép người dùng chọn iD và id làm hai ID khác nhau, nhưng khi tra cứu một ID không tồn tại, hệ thống lại thực hiện đối sánh không phân biệt chữ hoa/thường và trả về dữ liệu sai
    • Phản hồi cho lỗi đó là đây là hành vi vì “tiện lợi”

Có thể cần tránh cả tổ hợp, không chỉ từng ký tự

  • Bản thân tổ hợp ký tự cũng có trường hợp trông giống ký tự khác
    • rn có thể trông giống m
    • vv có thể trông giống w
  • Nếu chỉ vì những lý do này mà loại bỏ hàng loạt ký tự, tập ký tự có thể chọn sẽ bị thu hẹp quá nhiều, nên cách thực tế hơn có thể là chỉ tránh một số tổ hợp cụ thể ở bước sinh ID
  • Trong tình huống truyền đạt bằng lời nói, cũng có thể cân nhắc sự tương đồng về âm thanh
    • Ví dụ b và p có thể nghe giống nhau khi đọc thành tiếng

Các phương pháp hiện có đáng tham khảo

  • Base32 của Crockford giải mã các ký tự mơ hồ thành cùng một giá trị và cũng cân nhắc vấn đề vô tình tạo ra từ ngữ tục tĩu
  • Open Location Code sử dụng tập ký tự 23456789CFGHJMPQRVWX
    • Tập ký tự này được chọn để tránh các ký tự mơ hồ về mặt thị giác và cũng tránh cách viết thành từ trong ngôn ngữ thông thường
    • Tuy nhiên, nó bao gồm cả 6 và G, cũng như 9 và Q

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

  • Ở chỗ làm, chúng tôi từng xuất xưởng hàng triệu thiết bị có gắn số sê-ri, nhưng hoàn toàn không loại trừ các chữ cái hay chữ số dễ gây nhầm lẫn, khiến khách hàng rất vất vả mới đọc đúng được
    Tôi đã phải viết một script regex tạo ra mọi tổ hợp lỗi gõ có thể có dựa trên giá trị khách hàng nói, rồi chỉ hiển thị những tổ hợp khớp với cơ sở dữ liệu nhà máy; sau đó đối chiếu thêm các thông tin khác như ngày tháng để suy đoán số sê-ri thật
    Điều mỉa mai hơn là một vài vị trí thì không bao giờ thay đổi, còn có vị trí chỉ cần dùng 0, 1, 2 để phân biệt nhà máy, nên ngay từ đầu đã không cần toàn bộ tập ký tự. Cứ như thể họ tin rằng mình sẽ sản xuất 8 triệu tỷ thiết bị vậy

    • Trong nhiều trường hợp, việc ngăn rò rỉ thông tin kinh doanh qua số sê-ri là có ích, hoặc ít nhất được xem là có ích
      Ví dụ, nếu đánh số sản phẩm tuần tự như 1, 2, 3, chỉ với một mẫu nhỏ cũng có thể ước tính khá dễ tổng doanh số. Làm cho số sê-ri hợp lệ khó đoán cũng có lúc giúp ngăn những việc như lạm dụng hoàn tiền
      Dĩ nhiên, dù có những lo ngại như vậy thì vẫn có thể đồng thời tránh các ký tự khó đọc; và nếu điều đó cho thấy có ai đó đang suy nghĩ về việc dùng hệ thống số nào, thì lẽ ra họ phải nhận ra vấn đề này rõ hơn. Trên thực tế, có vẻ rất có thể ai đó đã nghĩ khoảng 30 giây rồi nói “dùng chừng này chữ số thì không bao giờ hết đâu, xong”
    • Nghĩ lại thì lý do số sê-ri của Apple không có nguyên âm cũng có thể là vì điều này, hoặc ít nhất là một trong các yếu tố
      Có vẻ số sê-ri thiết bị chỉ dùng phụ âm và chữ số

  • Cách mã hóa nên phụ thuộc vào người dùng. Base32, đặc biệt là Crockford và RFC 4648, rất phù hợp để biểu diễn ngắn gọn và có bảng chữ cái không mơ hồ cùng lý do rõ ràng
    Nhưng nếu người dùng phải đọc thành tiếng, thì cách biểu diễn bằng danh sách từ như s/key RFC 1751, chẳng hạn “TIDE ITCH SLOW REIN RULE MOT”, có thể tốt hơn
    Đừng tự tạo danh sách từ. Có vô số cạm bẫy ẩn như thành ngữ, từ đồng âm, phương ngữ, v.v. Đừng vô tình tạo ra một thảm họa kiểu “wet clam butterfly”

    • Đáng tiếc là ví dụ đó cũng có thể nghe thành “TIED HITCH SLOE REIGN RULE MOW”. Chỉ với 2 bit parity thì cũng không thể chắc chắn cách giải mã này là sai
      RFC 1751 [0], nơi ví dụ này xuất hiện, không giả định mã hóa để truyền đạt bằng lời nói, mà nhằm giúp người dùng “đọc, ghi nhớ và nhập” dễ hơn
      Nếu các chuyên gia truyền miệng cho nhau, lựa chọn hợp lý là chỉ dùng 26 chữ cái viết hoa và dựa vào bảng chữ cái phiên âm NATO. Nhưng việc lấy mã từ người dùng chưa được huấn luyện trong môi trường nói có nhiều nhiễu vẫn là một vấn đề chưa được giải quyết
      [0] https://datatracker.ietf.org/doc/html/rfc1751
    • Vì nó ra đời năm 1994 nên cũng nên thông cảm phần nào, nhưng đây vẫn là một RFC tệ đến mức khá buồn cười
      Ngay từ đoạn “phải dùng thuật toán message digest có khóa MD5, và nó đủ mạnh” đã buồn cười rồi
      Đến “khó đọc, khó nhớ và khó nhập với hầu hết mọi người” thì vẫn ổn, nhưng rồi lại chuyển thành “từ tiếng Anh dễ nhớ và dễ nhập hơn nhiều đối với mọi người”. Vấn đề là hầu hết mọi người không biết tiếng Anh; tôi đã nghĩ hay là thay danh sách từ, nhưng tài liệu lại nói “vì tính tương tác, không nên có từ điển riêng cho từng ngôn ngữ”
      Rốt cuộc lập luận kiểu cả thế giới đã học 26 chữ cái tiếng Anh rồi thì thêm vài từ cũng ổn, nhưng trong char Wp[2048][4] = […] không phải là những từ phổ biến phù hợp cho người mới học, mà là những thứ như “WAD, BESS, MERT…”. Thậm chí còn có “ORR? AGEE EGAN HAAS!!”, “GAUL FLAM! DRAB!” nữa
    • Tôi tò mò không biết loại ID như thế này được gọi là gì

  • Chuyện này làm tôi nhớ lại một việc cũ. Một ngày bị ốm, để quên đi cảm giác đau nhức, tôi đã làm một mô-đun đồ chơi thực hiện số học với cơ số tùy ý, và vì nó đơn giản nên đưa lên CPAN
    Mô-đun đó là https://metacpan.org/pod/Math::Fleximal
    Trong số những thứ lặt vặt tôi làm, tôi nghĩ thứ này chắc chắn sẽ không bao giờ có yêu cầu hỗ trợ, nhưng thực tế lại có. Lý do là tôi đã đưa vào một ví dụ chuyển hệ thập lục phân thành mã chữ-số, và ai đó đã có ý tưởng tuyệt vời là dùng nguyên xi nó để biến các số dài thành mã dễ đọc
    Mô-đun hoạt động tốt, nhưng việc nó lọt vào production ở đâu đó thì khá khó tin

  • Bài viết nhấn mạnh nên tránh các ký tự khó phân biệt cả khi viết tay, nhưng trong bảng ví dụ lại có chữ số 7. Tôi đã gặp vô số trường hợp khó phân biệt số 7 của ai đó với số 1
    Gạch ngang số 7 thì có ích, nhưng nhiều người không viết như vậy, nên đôi khi khó chắc đó là số 7 hay số 1 có chân serif

    • Bài viết cũng nhắc đến “B” (Bravo) và “P” (Papa) là khó phân biệt bằng âm thanh, nhưng lại bỏ sót “F” (Foxtrot) và “S” (Sierra), vốn nghe giống nhau hơn nhiều
      Có lúc hai chữ này gần như không phân biệt được. Có thể dùng bảng chữ cái chuẩn NATO/hàng không (Alpha, Bravo, Charlie, Delta...), nhưng nếu nhóm khách hàng không bị giới hạn rất chặt thì cũng không giúp được nhiều. Tốt hơn là nên tránh cả những tổ hợp như vậy
      Dù chuỗi ID có dài hơn một chút, tối đa hóa khả năng đọc, nói và nghe ký tự vẫn tốt hơn nhiều, và tiết kiệm được rất nhiều thời gian lẫn bực bội
    • Tôi chưa từng gặp trường hợp số 1 trông giống số 7 trong chữ viết tay. Thường thì I hoặc l mới bị nhầm với 1
      Tôi tò mò kiểu chữ viết tay nào khiến 1 giống 7. Chỉ riêng nét ngang trên của 7 có lẽ đã đủ phân biệt rồi
    • Ở phần đầu thì bị bỏ sót, nhưng trong mục “từ điển mơ hồ về mặt thị giác” thì cả 1 và 7 đều không có

  • Nếu dùng cả chữ hoa và chữ thường, sớm muộn gì cũng có khả năng bị một hệ thống hoặc giao thức bên thứ ba không phân biệt hoa thường làm hại
    Tôi từng thấy một hệ thống thương mại cho phép người dùng chọn ID có phân biệt hoa thường, chấp nhận iD và id là hai giá trị khác nhau, nhưng khi tra cứu một ID không tồn tại thì lại khớp không phân biệt hoa thường và trả về dữ liệu sai
    Khi tôi báo lỗi này, họ trả lời đó là “tính năng để tiện dụng”

  • Khi nhập số sê-ri DLC trên Nintendo Switch, các phím ký tự dễ gây nhầm lẫn đã bị vô hiệu hóa trên bàn phím ảo, và tôi thấy đó là một trải nghiệm người dùng khá tốt
    Điều này có nghĩa là ngay từ đầu số sê-ri đã được tạo ra mà không có các ký tự dễ gây nhầm lẫn. Tôi không rõ UX này được tích hợp sẵn trong hệ điều hành, hay chỉ có trong trò Mario + Rabbids Sparks of Hope mà tôi đang chơi

  • Trình quản lý mật khẩu mã nguồn mở KeepassXC dùng màu sắc để giúp mật khẩu dễ đọc hơn. Cách làm là dùng màu khác nhau cho từng loại ký tự như chữ hoa, chữ thường, chữ số và ký hiệu
    Đây là một ý tưởng rất đơn giản, nhưng đặc biệt với mật khẩu ngẫu nhiên thì nó giúp ích rất nhiều, ngay cả khi đã dùng phông chữ dễ đọc

    • Bitwarden cũng dùng phông chữ không mơ hồ và ba màu. Ký tự dùng màu mặc định, chữ số màu xanh dương, ký hiệu màu đỏ; cách này thật sự rất tốt
      Thật khó hiểu khi phần mềm tập trung vào mật khẩu lại cho phép hiển thị ký tự bằng phông chữ mơ hồ mà không có bất kỳ phân biệt màu sắc nào
    • Trong trình tạo mật khẩu của KeepassXC, cũng có thể dễ dàng thêm danh sách ký tự loại trừ
      Cảm giác đang nhập một mật khẩu dài bằng giao diện như điều khiển TV rồi nhận ra mình đã nhầm l1|I thật sự rất bực, nên tôi tự loại trừ chúng
    • Với tư cách là người bị rối loạn nhận biết màu sắc, tôi không thích ý tưởng này

  • Đây là bài viết nói về một vấn đề tôi thường gặp nên đọc rất thú vị
    Mỗi lần ghi mã dự phòng xác thực hai bước ra giấy, tôi lại thấy bất an khi gặp các ký tự như o/0, v/u, 5/S. Vì vậy tôi cố ý viết chúng hơi cách điệu để trông khác nhau
    Phần “tương đồng về âm thanh” làm tôi nhớ đến lúc chọn mật khẩu Wi‑Fi. Tôi muốn một từ phổ biến, có thể chia sẻ bằng một câu mà không mơ hồ, học sinh lớp 3 cũng đánh vần được, và có nhiều phụ âm; cuối cùng tôi chọn “vacation”

    • Quy tắc của tôi là chấm một dấu dưới mọi chữ số. Như vậy sẽ giải quyết các vấn đề như 5/S, 0/O, 8/B. Trên thực tế, các cặp gây vấn đề sẽ khác nhau tùy theo chữ viết tay của mỗi người
      Nếu thật sự không chắc, tôi còn ghi thêm bảng chữ cái NATO/hàng không [1]. Ví dụ nếu có U, tôi bắt đầu từ U rồi viết chéo ra Uniform
      Chỉ cần một chút kỷ luật. Tôi đã làm vậy hơn 10 năm và chưa từng làm mất mã xác thực hai bước lần nào
      [1] Mọi bắt bẻ về khác biệt thực tế giữa mã NATO và mã hàng không có thể an toàn gửi vào /dev/null
    • Thật khó tin là vẫn có người viết tay những thứ như thế ra giấy
      Cái đầu mới là nút thắt cổ chai

  • Tôi thích những cuộc thảo luận như thế này. Có thể đây không phải chủ đề tiên tiến hay hấp dẫn, nhưng nó rất có ý nghĩa và sức mạnh trong việc giúp cuộc sống của cả con người lẫn máy móc dễ dàng hơn
    Những thứ này cũng thuộc vùng best practice mà khi làm tốt thì ngược lại chẳng ai nhận ra. Thật tiếc là sự tận tâm và chân thành trong từng chi tiết lại bị xem như “đương nhiên phải thế” và không được khen ngợi đặc biệt

  • Nếu chỉ ra lỗi trong bài, ở 9qg6G8B2Z5SIl170O (ariel), tên phông chữ không phải Ariel mà là Arial. Nàng tiên cá không có ở đây

    • Đúng vậy. Và có lẽ phần đó nên dùng ảnh chụp màn hình hoặc web font thì tốt hơn
      Trên Linux, hầu hết các dòng trông giống hệt nhau
    • Bài viết là mã nguồn mở nên có thể đóng góp sửa đổi
      https://github.com/gajus/gajus-com/blob/main/src/blogPosts/2...
      Tôi đã sửa lỗi chính tả rồi