Base64

Канонічний приклад кодування на каналі — і того, чим кодування не є (захистом). Головне відео (як працює Base64) виводить його з першопринципів: народжений з потреби суто текстової пошти передавати бінарні вкладення, він відображає дані на 64 універсально безпечні символи (A-Z, a-z, 0-9, +, /), 6 біт на символ, тож 3 байти стають 4 символами — податок +33% до розміру. Далі — екскурсія родиною: base64url, як у JWT (+ і / замінені на - та _, padding =, завдяки чому «.» безпечна як роздільник), Base32 (нечутливий до регістру і без слешів — добрий для імен файлів; викидає 0/1 як двійники O/l; +60%) і Base16 = hex (CSS #FFFFFF, 2x розміру). Гарне демо: 32 hex-символи UUID декодуються в 16 сирих байтів — удвічі менше місця.

Потім він наживо декодує Base64 у трьох реальних місцях: токени JWT (header і payload може прочитати будь-хто), заголовки HTTP Basic Auth (значення Authorization: Basic декодується в login:password браузерним же atob) і зображення, вбудовані як data URI. Це демо з Basic Auth живить два його питання-пастки з хешування/кодування/шифрування — Base64-кодовані креденшали та JWT-payload — це «те саме, що відкритий текст» — і бойову історію з 3 речей, які роблять програміста кращим про інженера, який стверджував, що Basic Auth «зашифрований, бо це Base64». У Q&A про те, чи захистить вас HTTPS він обґрунтовує, коли +33% варто платити: будь-яка бінарщина всередині текстового формату — значення HTTP-заголовків (переноси рядків заборонені), логи, які можна відкрити текстовим редактором, JSON/XML-пейлоади, CSV без екранування, SMTP-вкладення, PEM-файли SSH-ключів. Серія про повнотекстовий пошук показує цей компроміс наживо: постинги загортаються в base64, щоб пережити рядково-орієнтований текстовий файл (повнотекстовий пошук), а в частині 2 індекс переструктуровано на два файли саме заради того, щоб скинути штраф +33% (повнотекстовий пошук, частина 2).