Буквено-цифровий символ: визначення, використання криптовалюти, безпека
Шістдесят два. Це загальна кількість різних символів, доступних, коли хтось каже «використовуйте лише буквено-цифрові символи». Двадцять шість великих літер, двадцять шість малих літер, десять цифр. Видаліть чутливість до регістру, і кількість зменшиться до тридцяти шести. Обидва числа мають значення, тому що майже кожен цифровий ідентифікатор, який ви коли-небудь вводили — адреса гаманця, пароль Wi-Fi, хеш транзакції, токен GitHub — складається з вибраної підмножини цих шістдесяти двох символів.
Вибір підмножини та чому – це частина, яку більшість пояснень пропускають. Це також частина, яка пов’язує енциклопедичне визначення буквено-цифрового символу з практичною безпекою вашого криптогаманця. У цій статті розглядається підрахунок, стандарт, що стоїть за ним, те, як сучасна криптографія вибирає його підмножини, і що зараз про це каже національний орган США з питань паролів. Деякі з цих рекомендацій змінилися таким чином, що більшість порад щодо безпеки ще не врахували.
Що таке буквено-цифровий символ? Визначення та кількість
Почнемо з визначення. Буквено-цифровий символ — це будь-яка літера A–Z (будь-якого регістру) або будь-яка десяткова цифра від 0 до 9. Це все, що потрібно знати. Далі арифметика очевидна — двадцять шість літер у кожному регістрі плюс десять цифр дають шістдесят два різних символи з чутливістю до регістру, тридцять шість — без. Все інше є «спеціальним». Пунктуація, пробіли, математичні символи, літери з акцентами, емодзі — жоден з них не вважається буквено-цифровим.
Зазвичай інженери знаходять це визначення за допомогою одного з двох скорочень. Інструменти POSIX, такі як grep, sed та awk, розпізнають `[:alnum:]`, що відповідає шістдесяти двом символам вище. Більшість сучасних різновидів регулярних виразів — Python, JavaScript, Java, PCRE — використовують замість нього `\w`. Заковика з `\w` полягає в тому, що він додає символ підкреслення. Підкреслення формально не є буквено-цифровим. Більшість синтаксисів програмування розглядає його як почесне, тому префікс ключа Stripe `sk_live_` та префікс ключа AWS `AKIA` поєднують символи підкреслення та великі літери з цифрами, не моргаючи оком.
Звідки взявся цей термін? З перфокарт, як не дивно. Табуляційне обладнання IBM у 1930-х роках потребувало одного слова для кодів, які змішували літери з цифрами, і слово «буквено-цифровий» прижилося. До IBM 1401 на початку 1960-х років це слово стало стандартним словником у бізнес-обчислювальній техніці. Ця відмінність мала практичне значення — поле, оголошене «буквено-цифровим», приймало будь-яку літеру чи цифру; числове поле повністю відхиляло алфавіт. Звідти слово потрапило в номерні знаки, банківські коди IBAN, мнемоніку телефонних клавіатур, артикули продуктів та сотні інших місць.
Різниця між чутливістю до регістру та без неї важливіша, ніж здається. Ентропія пароля подвоюється, коли дозволено введення великих літер. Адреси Base58 у Bitcoin навмисно зберігають обидва регістри. Bech32 навмисно відкидає регістр. Кожен із цих варіантів – це обмін між виразністю та людською помилкою. Якщо вибрати неправильний варіант, люди втратять гроші на друкарських помилках.
Від ASCII до Unicode: коротка технічна історія
«Буквено-цифровий» сьогодні — це пережиток війни стандартів, яка тривала шістдесят років. Більшість користувачів опинилися десь посередині і нічого не помітили.
ASCII з'явився першим. Він був випущений у 1963 році завдяки Американській асоціації стандартів, а через п'ять років був формалізований як ANSI X3.4-1968. Далі було два перегляди — один у 1977 році, інший у 1986 році. У версії 1968 року велика літера A була прив'язана до числа 65, мала літера a — до числа 97, а цифри від 0 до 9 — до числа від 48 до 57. Відкрийте редактор прямо зараз: байт «A» все ще дорівнює 65. Нічого не змінилося за шістдесят років.
Протягом приблизно чотирьох десятиліть буквено-цифровий набір ASCII був буквено-цифровим набором. Потім з'явилася глобальна мережа. Семи бітів перестало бути достатньо. Режими збоїв були потворними. Спотворені електронні листи. Зламані бази даних. Японські веб-сайти, які чудово працювали в Токіо та виглядали як стіни знаків питання на американському ноутбуці. Unicode з'явився в 1991 році з екстравагантною амбіцією: призначити унікальний номер кожному символу в кожному письмі, який хтось коли-небудь записував. UTF-8 з'явився в 1992 році як кодування, яке фактично переносило Unicode через звичайні мережі. Його хитрість полягала в зворотній сумісності — перші 128 кодових точок UTF-8 — це точно оригінальні 1968 байти ASCII. Англійський текст, що постачався до 1991 року, працював вічно.
Зміщення кодувань відбулося у грудні 2007 року. Того місяця публічна статистика веб-сканування нарешті показала, що UTF-8 випереджає ASCII як найпоширеніше кодування в Інтернеті. Відтоді «буквено-цифровий» перестав означати лише шістдесят два символи ASCII. Тепер Unicode каталогізує буквено-цифрові блоки для кирилиці, грецької, арабської, івриту та письма CJK. Кожен шрифт має свої власні літери та цифри.
Однак на практиці програмне забезпечення, яке має перетинати кордони, все одно за замовчуванням використовує оригінальну підмножину ASCII. Латинські літери A–Z. Арабські цифри 0–9. Нічого більше. Причина банальна. Кожна клавіатура відтворює ASCII. Кожна база даних приймає його. Кожен механізм регулярних виразів знає його. Вийдіть за межі діапазону, і ви успадкуєте портфель помилок неправильного кодування, схожих символів та фішингових атак, до яких я повернуся нижче.
| Клас | Члени | Кількість | Скорочення регулярного виразу | Приклад | |
|---|---|---|---|---|---|
| Алфавітний | А–Я, а–я | 52 | `[А-За-З]` | Просте англійське слово | |
| Числовий | 0–9 | 10 | `[0-9]` або `\d` | Рік, поштовий індекс | |
| Буквено-цифровий | A–Z, a–z, 0–9 | 62 | `[A-Za-z0-9]` або `[:alnum:]` | Ключ API, SKU | |
| Спеціальний / символічний | `!@#$%^&*()_+-=[]{};:'"\ | ,.<>/?` | ~33 (ASCII) | `[^A-Za-z0-9]` | Модифікатор пароля |
Алфавітно-цифрові символи в криптовалюті: адреси, хеші, насіння
Ось той момент, який пропускають більшість загальних пояснень. Системи криптовалют ніколи не використовують повний набір із шістдесяти двох буквено-цифрових символів. Вони ретельно вибирають підбірки . Кожна з них є задокументованим інженерним компромісом, а не довільною естетикою.
Спочатку біткойн. Застаріла адреса біткойна (та, що починається з 1 або 3) закодована в Base58. Алфавіт був розроблений Сатоші Накамото вручну. Рецепт: взяти шістдесятидвозначний буквено-цифровий набір, видалити чотири елементи. Викреслити цифру нуль, велику 0, велику 1, малу l. Чому саме чотири? Написати їх на стікері поганим почерком. Йти геть. Повернутися через п'ять хвилин. Спробувати розрізнити їх. Ви не зможете. Це вся проблема, для вирішення якої був створений Base58. Залишається п'ятдесят вісім символів. Типова застаріла адреса має довжину від двадцяти шести до тридцяти п'яти символів — достатньо коротких, щоб скопіювати їх вручну, якщо дійсно доведеться.
SegWit активувався у серпні 2017 року. Разом з ним з'явився другий формат адреси Bitcoin: Bech32, визначений у BIP-173. Bech32 робить інші ставки. Чутливість до регістру повністю зникає — кожна адреса пишеться в нижньому регістрі. Чотири інші символи пропускаються: цифра 1, плюс b, i, o. Тридцять дві літери та цифри, що залишилися, мають вбудовану контрольну суму. Контрольна сума автоматично виявляє майже кожну односимвольну друкарську помилку. Taproot, який працює з листопада 2021 року, удосконалив формат до Bech32m (BIP-350) після того, як дослідники виявили недолік у використанні кутового регістру в оригінальній математиці.
Ethereum обрав третій шлях. Просто використовуйте шістнадцяткову систему. Адреса Ethereum — це `0x`, за яким йде рівно сорок шістнадцяткових символів; всього сорок два символи. Шістнадцяткова система звужує буквено-цифрову систему до шістнадцяти елементів. Цифри 0–9, літери a–f, нічого більше. Вибір здавався очевидним у 2015 році. До 2026, після років, коли користувачі мружили очі на необроблені шістнадцяткові краплі в MetaMask, це виглядало потворно. EIP-55 вирішив проблему. Вибірково записувати певні літери великими літерами у шаблоні, отриманому з хешу Keccak-256 адреси в нижньому регістрі. Результатом є безкоштовне виявлення друкарських помилок. EIP-55 виявляє друкарські помилки з надійністю близько 99,975 відсотка. Відсоток помилок становить приблизно 0,0247 відсотка. Невеликий. Не нуль.
Хеші – це найпростіший випадок. Вихідний код хешу SHA-256 складається з 256 бітів, що відображається у вигляді 64 шістнадцяткових символів. Keccak-256 Ethereum видає вихідні дані ідентичної довжини. Ідентифікатор транзакції Bitcoin – txid – це хеш SHA-256 самої транзакції, тому txid також складається з 64 буквено-цифрових шістнадцяткових символів. Вони виглядають страхітливо в огляді блоків. Вони є чисто буквено-цифровими.
Насіннєві фрази порушують цей шаблон. Відновлення гаманця BIP-39 – це єдине місце, де криптовалюта виходить за межі буквено-цифрової системи та повертається до суто алфавітної території. Стандарт кодує 128 або 256 біт ентропії як дванадцять або двадцять чотири англійські слова, взяті з фіксованого списку з 2048 слів. Кожне слово складається лише з малих літер — без цифр, без змішаного регістру. Чому? Тому що цільовою метою дизайну є людина, яка пише слова на папері о 3-й годині ночі після того, як її телефон розрядився, а цифри вносять неоднозначність, на відміну від літер.
| Ідентифікатор | Набір символів | Довжина | Приклад (скорочений) |
|---|---|---|---|
| Застаріла адреса Bitcoin | Base58 (58 символів, без 0/O/I/l) | 26–35 | `1A1zP1eP5QGefi2…` |
| Біткойн Bech32 (SegWit) | 32 малі літери, № 1/b/i/o | ~42 | `bc1qar0srrr7xfk…` |
| Адреса Ethereum | шістнадцятковий (0–9, a–f) + `0x` | 42 | `0xde0B295669a91…` |
| SHA-256 / txid | шістнадцятковий | 64 | `e3b0c44298fc1c1…` |
| Слово BIP-39 | лише від a до z | 3–8 на слово | `відмовитися від здатності здатний…` |
Кожна підмножина — це частина людиноцентричного дизайну, що приховується всередині глибоко технічно сформованої системи.
Буквено-цифрові паролі: що насправді каже NIST у 2024 році
Більшість порад щодо паролів у публічній мережі застаріли на кілька років. Використовуйте змішаний регістр літер, додавайте цифри, включайте принаймні один спеціальний символ, змінюйте пароль кожні дев'яносто днів — ці правила були канонічними протягом двох десятиліть. Національний інститут стандартів і технологій США офіційно відмовився від них.
Спеціальна публікація NIST 800-63B, федеральний орган з питань цифрової ідентифікації, завершила четверту редакцію у вересні 2024 року. Нові рекомендації вражають тим, скільки всього вони видаляють. Рекомендація щодо мінімальної довжини для однофакторної автентифікації збільшена до п'ятнадцяти символів. Інструкція щодо правил складання символів сформульована як «не повинна»: сервіси не повинні вимагати певних класів символів. Періодичне закінчення терміну дії пароля, дев'яностоденна ротація, яку всі ненавиділи, також була видалена. Замість цих правил NIST тепер вимагає від сервісів перевіряти надіслані паролі на відповідність списку відомих скомпрометованих облікових даних.
Зсув виправданий математикою ентропії. 62-символьний буквено-цифровий пул видає близько 5,95 біта на символ. Повний 95-символьний друкований ASCII-пул — буквено-цифровий плюс спеціальні символи — видає 6,57. Додавання повного набору спеціальних символів дає 0,62 біта на символ. Додавання ще одного символу довжини дає повний приріст 5,95. Довжина на порядок переважає над складністю.
Звіт Verizon про розслідування витоків даних за 2025 рік показав, що облікові дані становлять 22 відсотки всіх підтверджених точок входу для витоків. Credential stuffing — автоматичне повторне використання витікаючих списків паролів — застосовується в 19 відсотках спроб автентифікації в середньому, досягаючи піку в 44 відсотки. Сорок дев'ять відсотків користувачів повторно використовують паролі в різних сервісах. Жодна з цих проблем не вирішується вимогою використання великої літери.
Довший буквено-цифровий пароль без спеціальних символів складніше зламати, ніж короткий, складений відповідно до контрольного списку складності. Якщо ваш банк все ще змушує вас складати пароль із дванадцяти символів, що включає одну велику літеру, одну цифру та один спеціальний символ, ця політика формально не відповідає федеральному стандарту США.
Де ще з'являються буквено-цифрові символи
Виходьте за межі криптографії, паролі та буквено-цифрові рядки все ще з'являються скрізь, де системі потрібен ідентифікатор, який люди можуть ввести, а комп'ютери можуть проаналізувати без двозначності.
Банківські коди — простий приклад. IBAN може розширюватися до тридцяти чотирьох буквено-цифрових символів і завжди починається з дволітерного коду країни ISO. Коди SWIFT/BIC складаються з восьми або одинадцяти символів. Номерні знаки відрізняються залежно від країни — британський номерний знак зовсім не схожий на німецький — але обидва є буквено-цифровими підмножинами одного й того ж пулу з шістдесяти двох символів. Ідентифікаційні номери транспортних засобів у всьому світі складаються рівно з сімнадцяти символів, а VIN-коди навмисно забороняють літери I, O та Q, щоб візуально відрізняти їх від цифр.
Ключі API – це повсякденні приклади, на які більшість користувачів навіть не звертають уваги. Ключ Stripe live відкриває `sk_live_` плюс буквено-цифровий токен. Ключ доступу AWS відкриває `AKIA` плюс шістнадцять буквено-цифрових символів. Персональний токен доступу GitHub, виданий після 2021 року, відкриває `ghp_`. Ці префікси самі по собі є буквено-цифровими, вибраними таким чином, щоб провайдери могли сканувати публічні репозиторії та журнали на наявність витоків ключів. У багатьох випадках це сканування виявляє промах раніше, ніж це робить будь-який зловмисник.
QR-коди заслуговують на коротку згадку. Стандарт ISO/IEC 18004 визначає спеціальний «алфавітно-цифровий режим», який кодує певний набір із 45 символів — великі літери, цифри, пробіли та кілька розділових знаків — ефективніше, ніж загальний байтовий режим. QR-код, що містить лише великі літери, алфавітно-цифровий вміст, зберігає приблизно в 1,6 раза більше даних на квадрат, ніж той самий вміст, закодований у вигляді необроблених байтів.
Base32, Base58, Base64: Коли криптовалюта вибирає підмножину
Існує кілька стандартів кодування, спеціально призначених для перетворення двійкових чисел на буквено-цифрову підмножину. Посилання на це наведено в RFC 4648, опублікованому IETF у 2006 році. У ньому визначено три кодування.
Шістнадцятковий алфавіт — найпростіший з них. Офіційно Base16. Шістнадцять символів: 0–9, a–f. Використовується для адрес Ethereum, криптографічних хешів, майже будь-якого низькорівневого налагодження, де потрібно зчитувати необроблені байти. Base32 — цікавіший. 32-символьний алфавіт був обраний, щоб не враховувати регістр, а в деяких варіантах — щоб пропустити візуально плутані цифри 0, 1, 8 та 9. Кожен, хто налаштовував двофакторну автентифікацію та вводив секретний код у Google Authenticator, вводив Base32 — здебільшого, не знаючи цього.
Base64 — це робоча конячка. Шістдесят два буквено-цифрові символи плюс два символи `+` та `/`. Варіант, безпечний для URL, замінює їх на `-` та `_`. Base64 передає ваші вкладення електронної пошти, кодує URL-адреси даних всередині HTML та пакує веб-токени JSON для OAuth.
Base58 біткойна знаходиться поза межами RFC 4648. Сатоші Накамото створив його самостійно. Мета була іншою — люди передруковували адреси, а не ефективність байтів на символ — і результатом став власний алфавіт, який ніхто більше не використовує. Base85, який іноді називають Ascii85, працює у протилежному напрямку. Він упаковує чотири байти у п'ять символів і відображається у файлах PDF та PostScript, де додаткова щільність виправдовує втрату читабельності.
Поширені помилки: візуальна плутанина та схожість
Ті ж причини, через які криптовалюта вибирає підмножини буквено-цифрових символів, є причинами помилок усіх. Кілька пар символів спричиняють більшість проблем.
Класичні плутанини: нуль та велика літера O. Цифра один, мала літера l, велика літера I. Мала літера l та велика літера I. Через це Bitcoin Base58 пропускає всі чотири літери. Інші системи використовують інші пом'якшувальні заходи — VIN-номери пропускають I, O та Q, деякі фінансові коди взагалі пропускають O, а також можна знайти національні правила щодо номерних знаків, які забороняють будь-яку літеру, що найбільше схожа на 0 у шрифті країни.
Складнішою та новішою проблемою є атаки з використанням омографів Unicode. Ідея була задокументована в статті 2001 року Євгена Габриловича та Алекса Гонтмахера. Омограф замінює візуально ідентичний символ з іншого алфавіту — наприклад, кириличний «а» (U+0430) на латинський «a» (U+0061). Зареєструйте доменне ім'я з цією заміною, і ви зможете розмістити фішингову сторінку, яка виглядає невідрізним від справжнього банку. Сучасні браузери відображають необроблене представлення Punycode — щось на кшталт `xn--80akhbyknj4f` — щоразу, коли домен змішує скрипти. Такий захист витримує більшість атак. Не всі.
Як створити надійний буквено-цифровий пароль у 2026
Три правила. Усі вони походять безпосередньо з математики NIST.
Перше: довжина переважає клас символів. Прагніть до шістнадцяти або більше символів. Правило діє незалежно від того, чи приймає система лише літери та цифри, чи повний набір ASCII для друку.
Друге: якщо вам доводиться запам'ятовувати його, використовуйте парольну фразу. Чотири випадкові слова з великого списку — список Diceware є канонічним варіантом — перевершують майже будь-який короткий пароль, який людина сяде та вигадає.
По-третє: для всього іншого використовуйте менеджер паролів. Дозвольте менеджеру генерувати довгі буквено-цифрові рядки, які вам ніколи не доведеться читати чи вводити вручну. Щойно менеджер обробляє вивід, читабельність виводу взагалі втрачає значення.
Короткий довідник: буквено-цифрові підрахунки та приклади
Шістдесят два з урахуванням регістру. Тридцять шість без нього. Коди ASCII 48–57 для цифр. 65–90 для верхнього регістру. 97–122 для нижнього регістру. Зіставте весь набір з регулярним виразом `[A-Za-z0-9]` або класом POSIX `[:alnum:]`. Цей пул із шістдесяти двох символів лежить в основі майже кожного цифрового ідентифікатора, до якого ви торкнетеся цього тижня. Паролі. Ключі API. IBAN. Номерні знаки. Ідентифікатори транзакцій. Кожна адреса гаманця, яку ви генеруєте.
