Оберіть «Кодувати» або «Декодувати», виберіть схему та натисніть кнопку дії. Уся обробка залишається у вашому браузері.
Що таке Base32 і Base58?
Це дві відповіді на одне запитання: канал, що переносить текст, мусить переносити байти. Base32 і Base58 — не шифрування і не хешування: вони нічого не приховують і нічого не скорочують. Вони переписують рядок байтів, використовуючи фіксований набір читабельних символів, і будь-хто, хто знає, який набір було використано, може одразу повернути все назад. Єдина причина віддати перевагу одному перед іншим — те, що робить із символами приймальний бік.
Дві родини виконують це переписування зовсім по-різному, і різниця пояснює майже кожен сюрприз на цій сторінці:
- Пакування бітів — Base32, Base32 Hex, Crockford Base32, z-base-32. Байти нарізаються на фіксовані групи, і кожні п'ять біт стають одним символом. Довжина виводу передбачувана з довжини вхідних даних, а остання, частково заповнена група або позначається символами доповнення, або лишається коротшою.
- Перетворення великих чисел — кожна таблиця Base58. Увесь рядок байтів читається як одне величезне число в основі 256 і записується знову в основі 58. Немає груп і немає доповнення; довжина ні на що не ділиться, а кожен провідний нульовий байт стає одним провідним нульовим символом.
Куди йдуть шість бітів даних: Base32 витрачає п'ять біт на символ, тож потрібно вісім символів на кожні п'ять вхідних байтів — приблизно на 60% більше. Base58 витрачає близько 5,86 біта на символ, тож результат приблизно на 37% більший. Base64 вміщує шість біт на символ і дає 33%. Більші алфавіти коротші, але важче читаються вголос — саме такий компроміс робить кожен із них.
Сім алфавітів на цій сторінці
Кожен алфавіт виведено повністю, а не описано, бо два інструменти, які друкують різні символи під однією назвою, не погодяться між собою, що б не писала етикетка. Рядки RFC 4648 є нормативними; рядки Crockford і z-base-32 відповідають тому, що опублікував автор формату; три рядки Base58 — поширені конвенції, а не стандарти, тому вони перелічені окремо.
Crockford Base32 і контрольний символ за модулем 37
Алфавіт пропускає I, L, O і U, щоб жоден символ не можна було прочитати як інший. Що лишилося, нечутливе до регістру на вході: i і l читаються як цифра 1, o читається як цифра 0, а дефіси існують лише для зручності читання довгого рядка. Крім того, формат визначає необов'язковий контрольний символ — значення рядка символів, прочитаного як число в основі 32, за модулем 37, записане з п'ятьма додатковими символами для значень від 32 до 36.
Контрольний символ обчислюється за рядком символів, а не за байтами: оскільки кодувальник доповнює останню групу нулями, декодування тих самих символів завжди повертає те саме значення. Тому контрольне значення з таблиці можна відтворити вручну лише з закодованого стовпця. П'ять додаткових символів — *, ~, $, = і U — для значень 32, 33, 34, 35 і 36, тож контрольний символ не завжди є цифрою чи літерою.
z-base-32
z-base-32 зберігає пакування по п'ять біт, як у RFC 4648 Base32, і змінює лише порядок тридцяти двох символів. Порядок обрано так, щоб символи, які людині найімовірніше доведеться записувати, були найлегшими для написання і найменш схожими між собою. Доповнення немає, тож читачеві треба знати, скільки символів мало б бути в значенні; це ціна формату, створеного передусім для читання вручну.
Base58Check: один байт версії, корисне навантаження, чотири байти контрольної суми
Сам по собі Base58 не має способу відрізнити рядок із помилкою від правильного, бо майже будь-яка комбінація його п'ятдесяти восьми символів є дійсним числом. Base58Check вирішує це, поміщаючи дані в обгортку: один байт версії, потім навантаження, потім перші чотири байти SHA-256, застосованого двічі поспіль до перших двох частин. Програма-приймач перераховує ці чотири байти і відхиляє рядок, якщо вони відрізняються. Байт версії й повідомляє гаманцю, чи він бачить адресу платежу, адресу скрипта чи приватний ключ.
Генератор під конвертером приймає байт версії та навантаження в шістнадцятковому вигляді й записує рядок Base58Check; перевіряльник зчитує рядок назад, відокремлює чотири байти контрольної суми, перераховує їх і повідомляє і знайдені, і очікувані. Невірна контрольна сума означає, що рядок набрано з помилкою або змінено — вона ніколи не означає, що навантаження невірне, оскільки навантаження ніколи не інтерпретується.
Поширені хибні уявлення
- "Base64 — це шифрування." Ні. Немає ключа і немає секрету; вивід може бути оборотний будь-ким. Base32 і Base58 у тому самому становищі, і протягування значення через усі три також не додає захисту.
- "Рядок Base58 — це адреса Bitcoin." Лише тоді, коли він також проходить перевірку контрольної суми Base58Check і має байт версії, який розпізнає програмне забезпечення-одержувач. Рядки Base58 трапляються в багатьох інших місцях, зокрема у звичайних ідентифікаторах без жодної контрольної суми.
- "Три алфавіти Base58 взаємозамінні." Вони використовують ті самі п'ятдесят вісім символів у трьох різних порядках, тож ті самі байти дають три різні рядки. Інструмент треба вказати, який використовувати, і ця сторінка завжди показує, який саме використала.
- "Доповнення — частина значення." Символи
= позначають лише останню групу. Два рядки Base32, які відрізняються лише доповненням, описують ті самі байти, тому декодер приймає рядок з відрізаним доповненням. - "Будь-які символи підходять." Кожен алфавіт — фіксований набір. Символ поза ним не має значення, тож декодер зупиняється і називає символ та його позицію, а не вгадує.
Поширені запитання
Чому Base32 використовує 2-7, а не 0-9? Тому що RFC 4648 обрав алфавіт, який залишається в межах символів, допустимих у доменних іменах, і легко читається вголос. Base32 Hex натомість використовує 0-9 A-V, коли важливіше природне сортування.
Чому рядок Base58 так часто починається з 1? Кожен провідний нульовий байт вхідних даних стає одним провідним 1 (першим символом алфавітів Bitcoin і Flickr). Байт версії 0x00 — це один нульовий байт, тож більшість адрес мейннету Bitcoin починаються з рівно однієї 1.
Що завантажує кнопка «Приклад»? Приклад, що належить до схеми та напрямку, які зараз на екрані, ніколи не фіксований текст. Кодувальнику передається текст власного прикладу схеми — вектори RFC 4648 розділ 10 для Base32 і Base32 Hex, 12345 зі специфікації Crockford, рядки z-base-32, надруковані вище — а декодувальнику передається закодований рядок для обраного алфавіту, що й робить приклад придатним в обидва боки. Три рядки Base58 навмисно мають той самий текст, тож перемикання схеми і повторне натискання «Приклад» показує три порядки тих самих п'ятдесяти восьми символів поруч. Коли позначено контрольний символ Crockford, декодувальник отримує значення з символом у кінці — єдиний спосіб побачити, як перевіряльник приймає такий рядок.
Чи надсилає ця сторінка мої дані кудись? Ні. Кожне перетворення відбувається в цій вкладці браузера, і сторінка не містить жодних мережевих викликів. Тому вона працює і з файлом, відкритим безпосередньо з диска.
Яку з них використовувати для секрету? Секрети автентифікаторів TOTP і HOTP зазвичай подаються у Base32 за алфавітом RFC 4648, бо секрет має вводитися вручну. Використовуйте той, який просить ваше програмне забезпечення-одержувач, і ніколи не покладайтеся на саме кодування для конфіденційності.
