Направление: кодирование и декодирование
Главная «настройка» — это выбор направления. Кодирование превращает текст или файл в Base64-строку, декодирование — возвращает исходные данные из строки. Перепутать их легко: если вставить обычный текст в декодер, вы получите ошибку, а не результат.
Правило простое: видите читаемый текст — кодируйте; видите длинную строку из букв, цифр, «+», «/» и «=» в конце — декодируйте. Инструмент CubTools держит оба режима на одной странице, переключаться можно мгновенно.
Новички часто пытаются «декодировать» обычный текст в надежде получить что-то осмысленное — так не работает. Декодер ожидает именно Base64-алфавит, и любой посторонний символ для него — повод сообщить об ошибке, а не фантазировать.
Переносы строк и пробелы в строке
Классический Base64 разбивает длинные строки на куски по 76 символов с переносами — так требует стандарт MIME для электронных писем. Но для вставки в JSON, URL или код переносы вредны: их придётся удалять вручную.
Если результат нужен для кода или API, выбирайте режим без переносов — сплошную строку. Если готовите вложение для письма по стандарту MIME, переносы, наоборот, оставьте: почтовые серверы их ожидают.
Откуда вообще взялись эти 76 символов? Из эпохи терминалов с фиксированной шириной строки: длинные строки рвали старые почтовые программы. Сегодня это анахронизм, но стандарт жив, и почтовые клиенты до сих пор его соблюдают.
URL-safe вариант алфавита
Обычный Base64 содержит символы «+» и «/», которые в адресах страниц имеют специальное значение. Вставленная как есть строка может быть обрезана или искажена сервером.
URL-safe режим заменяет «+» на «-», а «/» на «_» — такая строка безопасно живёт в параметрах адреса. Используйте его всегда, когда результат попадёт в ссылку, и убедитесь, что принимающая сторона понимает именно этот вариант алфавита.
Типичный пример — токены в ссылках для сброса пароля: они часто кодируются в URL-safe Base64, чтобы ссылка не ломалась в письме. Если ваш бэкенд ожидает обычный алфавит, а вы прислали URL-safe — декодирование упадёт на первом же дефисе.
Кодировка исходного текста
Перед кодированием текст превращается в байты, и от кодировки зависит результат. CubTools использует UTF-8 — современный стандарт, в котором корректно представлены кириллица, иероглифы и эмодзи.
Проблемы возникают, когда исходный файл сохранён в другой кодировке, например Windows-1251. Тогда русские буквы закодируются неверно. Решение: пересохраните файл в UTF-8 в любом текстовом редакторе перед кодированием.
Как понять, что дело в кодировке? После декодирования вместо русских букв — «кракозябры», а латиница в порядке. Это фирменный почерк несовпадения кодировок: пересохраните исходник и повторите.
Шпаргалка: какие настройки для какой задачи
Запомнить все опции проще через ситуации. Строка идёт в код или JSON — сплошная строка без переносов, обычный алфавит. Строка идёт в ссылку — URL-safe алфавит с дефисом и подчёркиванием. Готовите вложение для письма — переносы по 76 символов по стандарту MIME.
Текст с кириллицей — проверьте, что исходник в UTF-8, иначе получите «кракозябры». Не уверены, что ждёт принимающая сторона, — спросите или протестируйте на одном значении: дешевле потратить минуту на тест, чем переделывать партию.
Распечатайте эту шпаргалку мысленно: «куда — как». Куда идёт строка, диктует все настройки сразу. Через пару недель вы будете выставлять опции автоматически, даже не задумываясь, — как опытный водитель переключает передачи.
Частые вопросы
Что выбрать: строку с переносами или без?
Для кода, JSON и URL — без переносов, сплошной строкой. С переносами по 76 символов — только если готовите данные для электронной почты по стандарту MIME.
Чем URL-safe Base64 отличается от обычного?
Только двумя символами: «+» заменён на «-», а «/» на «_». Длина и смысл те же, но строка не ломается при вставке в адрес страницы.
Нужно ли что-то настраивать для русских букв?
Нет, если исходник в UTF-8 — а это кодировка по умолчанию почти везде. Проблемы бывают лишь со старыми файлами в Windows-1251: их нужно пересохранить в UTF-8.