Ký tự chữ và số: Định nghĩa, Sử dụng trong mật mã, Bảo mật

Ký tự chữ và số: Định nghĩa, Sử dụng trong mật mã, Bảo mật

Sáu mươi hai. Đó là tổng số ký hiệu khác nhau có sẵn khi ai đó nói "chỉ sử dụng ký tự chữ và số". Hai mươi sáu chữ cái viết hoa, hai mươi sáu chữ cái viết thường, mười chữ số. Bỏ qua phân biệt chữ hoa chữ thường, số lượng giảm xuống còn ba mươi sáu. Cả hai con số đều quan trọng, bởi vì hầu hết mọi định danh kỹ thuật số mà bạn từng nhập - địa chỉ ví, mật khẩu Wi-Fi, mã băm giao dịch, mã thông báo GitHub - đều được tạo thành từ một tập hợp con được chọn lọc trong số sáu mươi hai ký hiệu đó.

Việc lựa chọn tập hợp con nào và tại sao lại là phần mà hầu hết các bài giải thích thường bỏ qua. Đây cũng là phần liên kết định nghĩa mang tính bách khoa về ký tự chữ số với tính bảo mật thực tế của ví tiền điện tử của bạn. Bài viết này sẽ đi sâu vào việc đếm số lượng, tiêu chuẩn đằng sau nó, cách thức mật mã hiện đại lựa chọn các tập hợp con của nó, và những gì cơ quan quản lý mật khẩu quốc gia của Hoa Kỳ hiện nay nói về vấn đề này. Một số hướng dẫn đó đã thay đổi theo những cách mà hầu hết các lời khuyên về bảo mật vẫn chưa theo kịp.

Ký tự chữ số là gì? Định nghĩa và số lượng

Hãy bắt đầu với định nghĩa. Ký tự chữ số là bất kỳ chữ cái nào từ A đến Z (viết hoa và viết thường) hoặc bất kỳ chữ số thập phân nào từ 0 đến 9. Chỉ đơn giản vậy thôi. Từ đó, phép tính trở nên rõ ràng — 26 chữ cái cho mỗi kiểu chữ cộng với 10 chữ số tạo ra 62 ký tự khác nhau nếu phân biệt chữ hoa và chữ thường, 36 ký tự nếu không phân biệt. Bất cứ thứ gì khác đều được coi là "đặc biệt". Dấu chấm câu, khoảng trắng, ký hiệu toán học, chữ cái có dấu, biểu tượng cảm xúc — không cái nào được tính là ký tự chữ số.

Các kỹ sư thường đáp ứng định nghĩa này thông qua một trong hai cách viết tắt. Các công cụ POSIX như grep, sed và awk nhận ra `[:alnum:]`, khớp với sáu mươi hai ký tự ở trên. Hầu hết các loại biểu thức chính quy hiện đại — Python, JavaScript, Java, PCRE — sử dụng `\w` thay thế. Vấn đề với `\w` là nó chèn thêm dấu gạch dưới. Dấu gạch dưới không chính thức là ký tự chữ số. Hầu hết cú pháp lập trình coi nó như một ký tự danh dự, đó là lý do tại sao tiền tố khóa Stripe `sk_live_` và tiền tố khóa AWS `AKIA` kết hợp dấu gạch dưới, chữ cái viết hoa và chữ số mà không ai nhận ra.

Thuật ngữ này bắt nguồn từ đâu? Từ thẻ đục lỗ, thật bất ngờ. Thiết bị tính toán của IBM vào những năm 1930 cần một từ duy nhất cho các mã kết hợp cả chữ cái và số, và "alphanumeric" (chữ và số) đã được sử dụng rộng rãi. Đến máy IBM 1401 vào đầu những năm 1960, từ này đã trở thành từ vựng tiêu chuẩn trong lĩnh vực điện toán doanh nghiệp. Sự khác biệt này có hiệu lực trong thực tế — một trường được khai báo là "alphanumeric" chấp nhận bất kỳ chữ cái hoặc chữ số nào; một trường chỉ chứa số thì hoàn toàn từ chối bảng chữ cái. Từ đó, thuật ngữ này lan rộng sang biển số xe, mã ngân hàng IBAN, mã ghi nhớ bàn phím điện thoại, mã sản phẩm (SKU) và hàng trăm nơi khác.

Sự khác biệt giữa phân biệt chữ hoa chữ thường và không phân biệt chữ hoa chữ thường quan trọng hơn vẻ bề ngoài của nó. Độ phức tạp của mật khẩu tăng gấp đôi khi cho phép chữ hoa. Địa chỉ Base58 của Bitcoin giữ cả hai kiểu chữ hoa và chữ thường một cách có chủ đích. Bech32 lại loại bỏ kiểu chữ hoa và chữ thường một cách có chủ đích. Mỗi lựa chọn đó đều là sự đánh đổi giữa tính biểu đạt và lỗi của con người. Chọn sai và mọi người sẽ mất tiền vì lỗi đánh máy.

Ký tự chữ số

Từ ASCII đến Unicode: Lịch sử kỹ thuật tóm lược

Ngày nay, "hệ thống chữ số" là tàn dư của một cuộc chiến tiêu chuẩn kéo dài sáu mươi năm. Hầu hết người dùng đều bị mắc kẹt ở đâu đó giữa cuộc chiến và không hề nhận ra điều đó.

ASCII xuất hiện đầu tiên. Nó được đưa vào sử dụng năm 1963, nhờ Hiệp hội Tiêu chuẩn Hoa Kỳ, và được chính thức hóa năm năm sau đó với tên gọi ANSI X3.4-1968. Hai phiên bản sửa đổi tiếp theo đã được phát hành — một vào năm 1977, và một vào năm 1986. Phiên bản năm 1968 quy định chữ A viết hoa ở vị trí 65, chữ a viết thường ở vị trí 97, và các chữ số từ 0 đến 9 ở vị trí 48 đến 57. Mở trình soạn thảo của bạn ngay bây giờ: byte 'A' vẫn là 65. Không có gì thay đổi trong sáu mươi năm.

Trong khoảng bốn thập kỷ, bộ ký tự chữ số ASCII là bộ ký tự chữ số duy nhất. Rồi mạng internet toàn cầu xuất hiện. Bảy bit không còn đủ nữa. Các lỗi phát sinh rất nghiêm trọng. Email bị lỗi. Cơ sở dữ liệu bị hỏng. Các trang web tiếng Nhật hoạt động hoàn hảo ở Tokyo nhưng lại trông như một loạt dấu chấm hỏi trên máy tính xách tay của Mỹ. Unicode ra đời năm 1991 với một tham vọng lớn lao: gán một số duy nhất cho mỗi ký tự trong mọi hệ chữ viết mà con người từng viết ra. UTF-8 ra đời năm 1992, là hệ mã hóa thực sự giúp truyền tải Unicode qua các mạng thông thường. Điểm mạnh của nó là khả năng tương thích ngược — 128 điểm mã đầu tiên của UTF-8 chính xác là 1968 byte ASCII gốc. Văn bản tiếng Anh được gửi trước năm 1991 vẫn hoạt động mãi mãi.

Sự chuyển đổi diễn ra vào tháng 12 năm 2007. Tháng đó, số liệu thống kê thu thập dữ liệu web công khai cuối cùng đã cho thấy UTF-8 vượt qua ASCII trở thành mã hóa phổ biến nhất trực tuyến. Từ đó trở đi, "chữ số" không còn chỉ giới hạn ở 62 ký hiệu ASCII nữa. Unicode hiện lập danh mục các khối chữ số cho bảng chữ cái Cyrillic, Hy Lạp, Ả Rập, Do Thái và các bảng chữ cái CJK. Mỗi bảng chữ cái đều có các chữ cái và chữ số riêng.

Tuy nhiên, trên thực tế, phần mềm cần hoạt động xuyên biên giới vẫn mặc định sử dụng tập hợp con ASCII gốc. Các chữ cái Latinh A–Z. Các chữ số Ả Rập 0–9. Không có gì khác. Lý do rất đơn giản. Mọi bàn phím đều tạo ra ASCII. Mọi cơ sở dữ liệu đều chấp nhận nó. Mọi công cụ biểu thức chính quy đều biết nó. Nếu vượt ra ngoài phạm vi này, bạn sẽ phải đối mặt với hàng loạt lỗi mã hóa sai, các ký tự trông giống nhau và các cuộc tấn công lừa đảo mà tôi sẽ đề cập đến bên dưới.

Lớp học Thành viên Đếm viết tắt biểu thức chính quy Ví dụ
Bảng chữ cái A–Z, a–z 52 `[A-Za-z]` Từ tiếng Anh đơn giản
Số 0–9 10 `[0-9]` hoặc `\d` Một năm, một mã bưu điện
Chữ và số A–Z, a–z, 0–9 62 `[A-Za-z0-9]` hoặc `[:alnum:]` Khóa API, SKU
Đặc biệt / mang tính biểu tượng `!@#$%^&*()_+-=[]{};:'"\ ,.<>/?` ~33 (ASCII) `[^A-Za-z0-9]` Công cụ sửa đổi mật khẩu

Các ký tự chữ và số trong mật mã: Địa chỉ, hàm băm, mã hạt giống

Đây là phần mà hầu hết các bài giải thích chung chung thường bỏ qua. Hệ thống tiền điện tử không bao giờ sử dụng toàn bộ bộ ký tự chữ và số gồm sáu mươi hai ký tự. Chúng chọn lọc các tập hợp con được thiết kế cẩn thận. Mỗi tập hợp con đều là một sự thỏa hiệp về mặt kỹ thuật đã được ghi nhận, chứ không phải là một yếu tố thẩm mỹ tùy ý.

Trước tiên là Bitcoin. Một địa chỉ Bitcoin cũ (bắt đầu bằng 1 hoặc 3) được mã hóa bằng Base58. Bảng chữ cái này được Satoshi Nakamoto tự tay thiết kế. Công thức: lấy tập hợp 62 ký tự chữ và số, xóa đi 4 ký tự. Loại bỏ chữ số 0, chữ O viết hoa, chữ I viết hoa, chữ l viết thường. Tại sao lại là bốn ký tự đó? Viết chúng lên một tờ giấy nhớ bằng chữ viết xấu. Đi ra chỗ khác. Quay lại sau 5 phút. Thử phân biệt chúng xem. Bạn không thể. Đó chính là toàn bộ vấn đề mà Base58 được tạo ra để giải quyết. Còn lại 58 ký tự. Một địa chỉ cũ điển hình sẽ có độ dài từ 26 đến 35 ký tự — đủ ngắn để sao chép bằng tay nếu thực sự cần thiết.

SegWit được kích hoạt vào tháng 8 năm 2017. Cùng với đó là định dạng địa chỉ Bitcoin thứ hai: Bech32, được định nghĩa trong BIP-173. Bech32 đưa ra những đánh giá khác biệt. Tính phân biệt chữ hoa chữ thường biến mất hoàn toàn — mọi địa chỉ đều viết thường. Bốn ký tự khác nhau bị loại bỏ: chữ số 1, cộng với b, i, o. Ba mươi hai chữ cái và chữ số còn lại mang một mã kiểm tra tích hợp. Mã kiểm tra này tự động phát hiện hầu hết mọi lỗi chính tả một ký tự. Taproot, hoạt động từ tháng 11 năm 2021, đã tinh chỉnh định dạng thành Bech32m (BIP-350) sau khi các nhà nghiên cứu tìm thấy một lỗi hiếm gặp trong phép toán ban đầu.

Ethereum đã chọn một hướng đi thứ ba. Chỉ cần sử dụng hệ thập lục phân. Một địa chỉ Ethereum được viết là `0x` theo sau là chính xác bốn mươi ký tự thập lục phân; tổng cộng bốn mươi hai ký tự. Hệ thập lục phân thu hẹp chuỗi ký tự chữ và số xuống còn mười sáu thành phần. Các chữ số từ 0 đến 9, các chữ cái từ a đến f, không có gì khác. Lựa chọn này có vẻ gọn gàng vào năm 2015. Nhưng đến năm 2026, sau nhiều năm người dùng phải nheo mắt nhìn những khối thập lục phân thô trong MetaMask, nó trông thật xấu xí. EIP-55 là giải pháp khắc phục. Nó chọn lọc viết hoa một số chữ cái nhất định theo một mẫu được tạo ra từ hàm băm Keccak-256 của địa chỉ viết thường. Kết quả là khả năng phát hiện lỗi chính tả miễn phí. EIP-55 phát hiện lỗi chính tả với độ tin cậy khoảng 99,975%. Tỷ lệ bỏ sót chỉ khoảng 0,0247%. Nhỏ. Không phải là bằng không.

Mã băm là trường hợp đơn giản nhất. Đầu ra của mã băm SHA-256 là 256 bit, được hiển thị dưới dạng 64 ký tự thập lục phân. Keccak-256 của Ethereum tạo ra đầu ra có độ dài tương tự. Mã định danh giao dịch Bitcoin — txid — là mã băm SHA-256 của chính giao dịch đó, vì vậy txid cũng là 64 ký tự chữ và số thập lục phân. Chúng trông khá phức tạp trên trình khám phá khối. Chúng hoàn toàn là các ký tự chữ và số.

Cụm từ hạt giống phá vỡ quy tắc. Khôi phục ví BIP-39 là nơi duy nhất mà tiền điện tử bước ra khỏi phạm vi chữ số và quay trở lại lãnh địa chữ cái thuần túy. Tiêu chuẩn này mã hóa 128 hoặc 256 bit entropy thành mười hai hoặc hai mươi bốn từ tiếng Anh được chọn từ một danh sách cố định gồm 2.048 từ. Mỗi từ chỉ gồm các chữ cái viết thường — không có chữ số, không có chữ hoa chữ thường lẫn lộn. Tại sao? Bởi vì mục tiêu thiết kế là một người viết chữ trên giấy lúc 3 giờ sáng sau khi điện thoại hết pin, và các chữ số gây ra sự mơ hồ mà các chữ cái không gây ra.

Mã định danh Bộ ký tự Chiều dài Ví dụ (đã rút gọn)
Địa chỉ kế thừa Bitcoin Hệ cơ số 58 (58 ký tự, không có 0/O/I/l) 26–35 `1A1zP1eP5QGefi2…`
Bitcoin Bech32 (SegWit) 32 chữ thường, không có 1/b/i/o ~42 `bc1qar0srrr7xfk…`
Địa chỉ Ethereum hex (0–9, a–f) + `0x` 42 `0xde0B295669a91…`
SHA-256 / txid thập lục phân 64 `e3b0c44298fc1c1…`
BIP-39 word chỉ a–z 3–8 từ `từ bỏ khả năng…`

Mỗi tập hợp con là một phần của thiết kế lấy con người làm trung tâm, ẩn mình bên trong một hệ thống kỹ thuật phức tạp.

Mật khẩu chữ số: NIST thực sự nói gì vào năm 2024

Hầu hết các lời khuyên về mật khẩu trên mạng internet đều đã lỗi thời vài năm. Sử dụng chữ hoa và chữ thường, thêm số, bao gồm ít nhất một ký tự đặc biệt, thay đổi mật khẩu sau mỗi chín mươi ngày — những quy tắc đó đã được chấp nhận trong hai thập kỷ. Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST) đã chính thức từ bỏ chúng.

Ấn phẩm đặc biệt NIST 800-63B, cơ quan liên bang về hướng dẫn nhận dạng kỹ thuật số, đã hoàn thiện Bản sửa đổi 4 vào tháng 9 năm 2024. Hướng dẫn mới này gây chú ý bởi việc loại bỏ nhiều quy định. Khuyến nghị về độ dài tối thiểu được nâng lên mười lăm ký tự đối với xác thực một yếu tố. Hướng dẫn về quy tắc cấu tạo ký tự được diễn đạt dưới dạng "không được phép": các dịch vụ không được yêu cầu các lớp ký tự cụ thể. Việc hết hạn mật khẩu định kỳ, chu kỳ chín mươi ngày mà mọi người đều ghét, cũng đã bị loại bỏ. Thay vào đó, NIST hiện yêu cầu các dịch vụ phải kiểm tra mật khẩu được gửi đến so với danh sách chặn các thông tin đăng nhập đã bị xâm phạm.

Sự thay đổi này được chứng minh bằng toán học entropy. Một tập hợp ký tự chữ và số gồm 62 ký tự tạo ra khoảng 5,95 bit mỗi ký tự. Toàn bộ tập hợp ký tự ASCII có thể in được gồm 95 ký tự — chữ và số cộng với các ký tự đặc biệt — tạo ra 6,57 bit. Thêm toàn bộ tập hợp các ký tự đặc biệt sẽ tăng thêm 0,62 bit mỗi ký tự. Thêm một ký tự có độ dài nhất định sẽ tăng thêm toàn bộ 5,95 bit. Độ dài chi phối độ phức tạp với tỷ lệ chênh lệch gấp mười lần.

Báo cáo Điều tra Vi phạm Dữ liệu năm 2025 của Verizon cho thấy thông tin đăng nhập chiếm 22% tổng số điểm xâm nhập được xác nhận. Tấn công nhồi nhét thông tin đăng nhập — tự động sử dụng lại danh sách mật khẩu bị rò rỉ — chiếm trung bình 19% số lần xác thực, đạt đỉnh điểm ở mức 44%. Bốn mươi chín phần trăm người dùng sử dụng lại mật khẩu trên nhiều dịch vụ. Không vấn đề nào trong số đó được giải quyết bằng cách yêu cầu viết hoa chữ cái đầu tiên.

Mật khẩu dài gồm cả chữ và số mà không có ký tự đặc biệt sẽ khó bị bẻ khóa hơn mật khẩu ngắn được tạo ra để đáp ứng danh sách kiểm tra độ phức tạp. Nếu ngân hàng của bạn vẫn yêu cầu bạn tạo mật khẩu mười hai ký tự với một chữ cái viết hoa, một chữ số và một ký tự đặc biệt, thì chính sách đó hiện đã chính thức không phù hợp với tiêu chuẩn liên bang của Hoa Kỳ.

Các ký tự chữ và số xuất hiện ở những vị trí khác

Ngoài lĩnh vực mật mã, mật khẩu và chuỗi ký tự chữ số vẫn xuất hiện ở bất cứ nơi nào hệ thống cần một mã định danh mà con người có thể nhập và máy tính có thể phân tích mà không gây nhầm lẫn.

Mã ngân hàng là một ví dụ dễ hiểu. Mã IBAN có thể dài tới ba mươi bốn ký tự chữ và số, và luôn bắt đầu bằng mã quốc gia ISO gồm hai chữ cái. Mã SWIFT/BIC có tám hoặc mười một ký tự. Biển số xe khác nhau tùy quốc gia — biển số xe ở Anh hoàn toàn khác với biển số xe ở Đức — nhưng cả hai đều là tập hợp con chữ và số của cùng một nhóm sáu mươi hai ký hiệu. Mã số nhận dạng xe (VIN) có chính xác mười bảy ký tự trên toàn thế giới, và VIN cố tình cấm các chữ cái I, O và Q để phân biệt chúng rõ ràng với các chữ số.

Khóa API là những ví dụ thường ngày mà hầu hết người dùng không bao giờ để ý đến. Khóa Stripe Live có dạng `sk_live_` cộng với một mã token chữ và số. Khóa truy cập AWS có dạng `AKIA` cộng với mười sáu ký tự chữ và số. Mã token truy cập cá nhân GitHub được cấp sau năm 2021 có dạng `ghp_`. Bản thân các tiền tố này cũng là chữ và số, được chọn để các nhà cung cấp có thể quét các kho lưu trữ và nhật ký công khai để tìm các khóa bị rò rỉ. Trong nhiều trường hợp, quá trình quét đó phát hiện ra sơ hở trước khi bất kỳ kẻ tấn công nào thực hiện được.

Mã QR cũng cần được đề cập ngắn gọn. Tiêu chuẩn ISO/IEC 18004 định nghĩa một "chế độ chữ số" chuyên dụng, mã hóa một tập hợp 45 ký tự cụ thể — bao gồm chữ cái viết hoa, chữ số, khoảng trắng và một số dấu chấm câu — hiệu quả hơn so với chế độ byte thông thường. Một mã QR chỉ chứa nội dung chữ số viết hoa sẽ lưu trữ lượng dữ liệu nhiều hơn khoảng 1,6 lần trên mỗi ô vuông so với cùng nội dung đó được mã hóa dưới dạng byte thô.

Base32, Base58, Base64: Khi nào mật mã chọn một tập con?

Một số tiêu chuẩn mã hóa tồn tại đặc biệt để ánh xạ dữ liệu nhị phân thành một tập hợp con chữ số. Tài liệu tham khảo là RFC 4648, được IETF công bố năm 2006. Nó định nghĩa ba phương pháp mã hóa.

Hệ thập lục phân (Hex) là hệ đơn giản nhất. Chính thức là hệ cơ số 16 (Base16). Mười sáu ký tự: 0–9, a–f. Được sử dụng cho địa chỉ Ethereum, hàm băm mật mã, hầu hết mọi thao tác gỡ lỗi cấp thấp cần đọc các byte thô. Hệ cơ số 32 (Base32) thú vị hơn. Bảng chữ cái 32 ký tự được chọn để không phân biệt chữ hoa chữ thường và, trong một số biến thể, để loại bỏ các chữ số dễ gây nhầm lẫn về mặt thị giác như 0, 1, 8 và 9. Bất cứ ai đã thiết lập xác thực hai yếu tố và nhập mã bí mật vào Google Authenticator đều đã nhập Base32 — hầu hết thời gian mà không hề hay biết.

Base64 là công cụ chủ lực. Nó bao gồm 62 ký tự chữ và số cộng với hai ký hiệu `+` và `/`. Một biến thể an toàn cho URL sẽ thay thế chúng bằng `-` và `_`. Base64 được sử dụng để truyền tải các tệp đính kèm email, mã hóa URL dữ liệu bên trong HTML và đóng gói JSON Web Token cho OAuth.

Hệ thống mã hóa Base58 của Bitcoin nằm ngoài RFC 4648. Satoshi Nakamoto đã tự xây dựng nó. Mục tiêu khác biệt — việc con người nhập lại địa chỉ, chứ không phải hiệu quả về số byte trên mỗi ký tự — và kết quả là một bảng chữ cái tùy chỉnh mà không ai khác sử dụng. Hệ thống Base85, đôi khi được gọi là Ascii85, hoạt động theo hướng ngược lại. Nó nén bốn byte vào năm ký tự và xuất hiện trong các tệp PDF và PostScript, nơi mật độ cao hơn bù đắp cho sự giảm khả năng đọc.

Ký tự chữ số

Những lỗi thường gặp: Nhầm lẫn hình ảnh và các đối tượng trông giống nhau

Những lý do khiến mật mã chọn các tập con của ký tự chữ và số cũng chính là những lý do khiến mọi người đều mắc lỗi. Một số ít cặp ký tự gây ra hầu hết các sự cố.

Những ký tự dễ gây nhầm lẫn kinh điển: số 0 và chữ O viết hoa. Chữ số một, chữ l viết thường, chữ I viết hoa. Chữ l viết thường và chữ I viết hoa. Hệ thống mã hóa Base58 của Bitcoin loại bỏ cả bốn ký tự này vì lý do đó. Các hệ thống khác sử dụng các biện pháp giảm thiểu khác nhau — số VIN loại bỏ I, O và Q, một số mã tài chính loại bỏ hoàn toàn O, và bạn có thể tìm thấy các quy định về biển số xe quốc gia cấm bất kỳ chữ cái nào trông giống số 0 nhất trong phông chữ của quốc gia đó.

Một vấn đề phức tạp hơn và mới hơn là các cuộc tấn công bằng ký tự đồng âm Unicode. Ý tưởng này đã được ghi nhận trong một bài báo năm 2001 của Evgeniy Gabrilovich và Alex Gontmakher. Một ký tự đồng âm hoán đổi một ký tự giống hệt nhau về mặt hình ảnh từ một hệ chữ viết khác — ví dụ, chữ Cyrillic 'а' (U+0430) thay cho chữ Latin 'a' (U+0061). Đăng ký một tên miền với sự thay thế đó và bạn có thể lưu trữ một trang web lừa đảo trông không thể phân biệt được với trang web ngân hàng thật. Các trình duyệt hiện đại hiển thị biểu diễn Punycode thô — chẳng hạn như `xn--80akhbyknj4f` — bất cứ khi nào một tên miền trộn lẫn các hệ chữ viết. Biện pháp phòng vệ đó bắt được hầu hết các cuộc tấn công. Nhưng không phải tất cả.

Cách tạo mật khẩu chữ số mạnh trong 2026

Ba quy tắc. Tất cả đều được rút ra trực tiếp từ toán học của NIST.

Thứ nhất: Độ dài quan trọng hơn loại ký tự. Hãy nhắm đến mười sáu ký tự trở lên. Quy tắc này đúng cho dù hệ thống chỉ chấp nhận chữ cái và chữ số hay toàn bộ tập hợp ký tự ASCII có thể in được.

Thứ hai: nếu bạn phải nhớ mật khẩu, hãy sử dụng cụm mật khẩu. Bốn từ ngẫu nhiên từ một danh sách lớn — danh sách của Diceware là lựa chọn chuẩn mực — hiệu quả hơn hầu hết mọi mật khẩu ngắn mà con người có thể tự nghĩ ra.

Thứ ba: đối với mọi thứ khác, hãy sử dụng trình quản lý mật khẩu. Hãy để trình quản lý tạo ra các chuỗi ký tự chữ và số dài mà bạn sẽ không bao giờ phải đọc hoặc gõ bằng tay. Một khi trình quản lý xử lý đầu ra, khả năng đọc hiểu của đầu ra không còn quan trọng nữa.

Hướng dẫn tham khảo nhanh: Số lượng ký tự chữ và số cùng các ví dụ.

Sáu mươi hai ký tự có phân biệt chữ hoa chữ thường. Ba mươi sáu ký tự không phân biệt chữ hoa chữ thường. Mã ASCII 48–57 dành cho chữ số. 65–90 dành cho chữ hoa. 97–122 dành cho chữ thường. Hãy so khớp toàn bộ tập hợp với biểu thức chính quy `[A-Za-z0-9]` hoặc lớp POSIX `[:alnum:]`. Tập hợp sáu mươi hai ký tự đó là nền tảng của hầu hết mọi định danh kỹ thuật số mà bạn sẽ sử dụng trong tuần này. Mật khẩu. Khóa API. IBAN. Biển số xe. ID giao dịch. Mọi địa chỉ ví bạn tạo ra.

Bất kỳ câu hỏi?

Bởi vì Satoshi Nakamoto đã ngồi xuống và xóa bỏ mọi ký tự dễ gây xung đột về mặt hình ảnh trong các phông chữ thông dụng. Số 0 xung đột với chữ O viết hoa. Chữ l viết thường xung đột với chữ I viết hoa. Người dùng Bitcoin khi gõ lại địa chỉ từ bản sao lưu giấy sẽ bị nhầm lẫn. Sự nhầm lẫn đó khiến mọi người mất tiền thật. Loại bỏ bốn ký tự gây lỗi này và tỷ lệ lỗi chính tả sẽ giảm mạnh.

Không. Dấu câu, ký hiệu toán học, ký hiệu tiền tệ, khoảng trắng — mọi thứ không phải là chữ cái hoặc chữ số đều nằm ngoài tập hợp chữ số. Bạn có thể thêm chúng vào mật khẩu và thu được một phần nhỏ độ phức tạp cho mỗi ký tự. Thêm một ký tự dài hơn thường mang lại cho bạn nhiều hơn đáng kể.

Mật khẩu được tạo từ chữ cái và chữ số, không có ký hiệu. Tiêu chuẩn NIST SP 800-63B Rev 4 — được xuất bản tháng 9 năm 2024 — đã ngừng yêu cầu các ký tự đặc biệt trong phiên bản hiện tại. Khuyến nghị hiện hành là tối thiểu mười lăm ký tự cộng với kiểm tra danh sách chặn đối với các thông tin đăng nhập đã bị xâm phạm. Hầu hết các chính sách mật khẩu của doanh nghiệp vẫn còn chậm hơn hướng dẫn này vài năm.

Đúng vậy, nhưng không bao giờ là toàn bộ tập hợp ký tự. Địa chỉ Bitcoin truyền thống sử dụng hệ mã Base58, loại bỏ các ký tự 0, O, I và l. Địa chỉ Bech32 SegWit sử dụng một tập hợp con gồm 32 ký tự chữ thường, loại bỏ các ký tự 1, b, i và o. Lý do đằng sau cả hai lựa chọn đều giống nhau — mọi người thường nhầm lẫn các ký tự trông giống nhau khi gõ lại, và những người gõ lại nhầm lẫn sẽ mất tiền.

Không. Khoảng trắng thuộc lớp whitespace, một nhóm hoàn toàn riêng biệt. Hãy chạy bất kỳ bài kiểm tra nào — POSIX `[:alnum:]`, regex `[A-Za-z0-9]`, `isalnum()` của Python, regex `\w` của JavaScript — và tất cả chúng đều từ chối khoảng trắng, tab và xuống dòng.

Sáu mươi hai nếu xét đến chữ hoa chữ thường. Hai mươi sáu chữ hoa, hai mươi sáu chữ thường, mười chữ số. Tắt chế độ phân biệt chữ hoa chữ thường thì bạn sẽ có ba mươi sáu ký tự. Sự phân chia này bắt nguồn từ tiêu chuẩn ASCII năm 1968 và không thay đổi kể từ đó.

Ready to Get Started?

Create an account and start accepting payments – no contracts or KYC required. Or, contact us to design a custom package for your business.

Make first step

Always know what you pay

Integrated per-transaction pricing with no hidden fees

Start your integration

Set up Plisio swiftly in just 10 minutes.