Base32

Otuz iki karakterle yazılan baytlar ve dışarıda bırakılan rakamlar

Base32, baytları metin olarak, her biri beş biti temsil eden otuz iki karakterle yazar; bu yüzden her beş bayt — kırk bit — sekiz karakter olur. Hello beş bayttır ve JBSWY3DP olarak yazılır. “Çöz” yönünü seçip Base32 yapıştırın; sayfa onun temsil ettiği baytları geri verir: metin olarak ya da “Bayt gösterimi” seçicisini “On altılık” olarak ayarlarsanız on altılık olarak.

Onu tanımlayan RFC 4648, yirmi altı büyük harfi ve 2’den 7’ye kadar rakamları kullanır. RFC, 0 ile 1’in neden eksik olduğunu açıklar: metinle uğraşan biri 0’ı O ile, 1’i de l ya da I ile kolayca karıştırabilir; bu yüzden alfabe harfleri tutar ve bu iki rakamı dışarıda bırakır. Harflerin yanında altı rakama ihtiyacı vardır ve aldığı altı rakam 2’den 7’ye kadardır; bu yüzden 8 ve 9 da alfabede yoktur. Sayfa bu alfabeyle çözerken bir 0’ı O, bir 1’i I olarak okumak yerine 0, 1, 8 ya da 9’u durduğu yerde reddeder: RFC bir çözücünün onları böyle okumasına izin verir ve varsayılan olarak okumaması gerektiğini söyler.

Harf büyüklüğü değerin bir parçası değildir. RFC 4648, Base32’yi harf büyüklüğüne bakılmadan okunması gereken metinler için tasarladı; bu yüzden JBSWY3DP ile jbswy3dp aynı şekilde Hello demektir. RFC alfabesini büyük harfle yazar; siz “küçük harf” seçeneğini açmadıkça bu sayfa da öyle yapar. Okuma ayrıca her yerdeki boşlukları, satır sonları dahil, atlar; bu yüzden gruplara bölünmüş ya da birkaç satıra yayılmış Base32, tek parça hâlinde yazılmış gibi okunur.

Dolgu ve Base32’nin alabileceği uzunluklar

Baytlar nadiren tam beşli gruplar hâlinde gelir. Sonda kalan bir ila dört bayt iki, dört, beş ya da yedi karakter tutar ve RFC 4648 bu son grubu = ile doldurarak sekize tamamlar: altı tane, dört, üç ya da bir. Böylece f, MY====== olur; fo, MZXQ====; foo, MZXW6=== ve foob, MZXW6YQ= olur. Beş bayt olan fooba ise sekiz karakterini tam olarak doldurur: MZXW6YTB.

Demek ki sekizer sekizer sayıldığında, herhangi bir = işaretinden önceki karakterlerden her zaman 0, 2, 4, 5 ya da 7 karakter artar, hiçbir zaman 1, 3 ya da 6 artmaz, çünkü hiçbir bayt sayısı böyle bir kalan bırakmaz; sayfa böyle bir metni daha kısa bir şey olarak okumak yerine son karakterinde reddeder. Dolgu, uzunluğun söylemediği hiçbir şeyi söylemez; bu yüzden sayfa dolgusu atlanmış Base32’yi de okur — JBUQ, tıpkı JBUQ==== gibi Hi olur — ve dolguyu yalnızca orada olup yanlış olduğu yerde reddeder: ortada, ardından metnin devamı gelen bir = ya da sonda yanlış sayıda = — ikincisini reddederken sayfa oraya kaç tane gerektiğini söyler.

Kodlarken = işaretlerinin yazılıp yazılmayacağına “Dolgu” seçeneği karar verir. Bu seçenek açık başlar, çünkü RFC 4648, Base32’yi kullanan belirtim aksini söylemedikçe dolgu ister ve birkaçı da aksini söyler: 2FA QR kodundaki otpauth:// URI’yi tanımlayan Key Uri Format, bir gizli anahtarın dolgusunun atlanması gerektiğini söyler; NSEC3 kayıtları ve IPFS ise hiç dolgu yazmaz. Yanındaki “küçük harf” seçeneği harfleri küçük yazar; rakamların ve = işaretinin değiştirilecek bir harf büyüklüğü yoktur. İki seçenek de yalnızca kodlarken görünür, çünkü okuma bunların her bileşimini kabul eder.

Başka araçlar bu sayfadan daha azını okur. GNU coreutils, Base32’yi base32 ile, ikinci alfabe olan base32hex’i de basenc --base32hex ile yazar; Python’un base64 modülünde her biri için bir işlev vardır. Hepsi bu sayfanın açılışta yazdığını yazar: dolgulu ve büyük harfle. Ama base32 -d, dolgusu eksik ya da harfleri küçük olan Base32’yi reddeder; Python’un b32decode işlevi de ikisini de reddeder ve küçük harfi yalnızca kendisine casefold=True verildiğinde okur:

# Writing: the default Alphabet, then the other one
printf 'Hi' | base32                          # JBUQ====
printf 'Hi' | basenc --base32hex              # 91KG====

# Reading back: padded, then without padding, then in lowercase
printf 'JBUQ====' | base32 -d                 # Hi
printf 'JBUQ' | base32 -d                     # base32: invalid input
printf 'jbuq====' | base32 -d                 # base32: invalid input

# The same in a script
import base64
base64.b32encode(b'Hi')                       # b'JBUQ===='
base64.b32hexencode(b'Hi')                    # b'91KG===='
base64.b32decode('JBUQ')                      # binascii.Error: Incorrect padding
base64.b32decode('jbuq====', casefold=True)   # b'Hi'

İki alfabe: base32 ve base32hex

RFC 4648 ikinci bir alfabe tanımlar: base32hex. Bu alfabede önce 0’dan 9’a kadar rakamlar, ardından A’dan V’ye kadar harfler gelir; böylece karakterleri, temsil ettikleri değerlerin sırasını izler: sıfır için 0’dan otuz bir için V’ye kadar. Bu, ona ilk alfabede olmayan ve RFC’nin de belirttiği bir özellik kazandırır: karakter karakter karşılaştırıldığında metni, temsil ettiği baytların sırasıyla sıralanır. 00 baytı base32’de AA======, base32hex’te 00====== olur; FF baytı ise 74====== ve VS====== olur; metin olarak sıralandığında base32 FF baytını başa koyar, çünkü rakamlar harflerden önce sıralanır; base32hex ise baytları sırasında tutar.

DNSSEC kapsamındaki NSEC3 kayıtları bu alfabeyi kullanır. Böyle bir kaydın adı, bir alan adının base32hex ile dolgusuz yazılmış hash’iyle başlar ve RFC 5155, bu şekilde yazıldığında hash’lenmiş adların, hash’lerin değerce sıralandığı sırayla aynı sırada dizildiğini belirtir. RFC’nin kendi örnek bölgesi, example adının hash’ini 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom olarak verir. Sayfa, base32hex seçiliyken bu 32 karakteri hash’in 20 baytı olarak okur; base32 seçiliyken ise 0’ı reddeder — ve bir bildirim, metnin base32hex ile bütünüyle okunduğunu söyler; yanında da alfabeyi değiştiren bir düğme durur.

Aynı baytlar her birinde farklı bir metin olduğu için — Hi, base32’de JBUQ====, base32hex’te 91KG==== olur — seçtiğiniz alfabe iki yönde de geçerlidir ve sayfa onu sizin yerinize asla değiştirmez. Çözdüğünüz bir metin seçili alfabede olmayan bir karakter içerdiğinde ya da aşağıdaki soruların açıkladığı, sıfır olmayan artık bitlerle bittiğinde, öteki alfabe ise metnin tamamını bir kodlayıcının yazacağı gibi okuduğunda, bir bildirim bunu söyler ve yanında alfabeyi değiştiren bir düğme durur; alfabe yalnızca o düğmeye tıkladığınızda ya da onu kendiniz seçtiğinizde değişir. İkisinin de sorunsuz okuduğu ABCDEFGH gibi bir metin seçili alfabeyle okunur, çünkü içindeki hiçbir şey hangisinin kastedildiğini söylemez.

Base32 nerede karşınıza çıkar: 2FA gizli anahtarları, onion adresleri ve IPFS

Bir kurulum QR kodunun taşıyabileceği otpauth:// URI’yi tanımlayan Key Uri Format belgesinde, bir kimlik doğrulama uygulamasının kodlarının ardındaki gizli anahtar Base32 ile yazılır: URI’nin secret parametresi Base32’dir ve dolgu atlanmalıdır. Böyle bir gizli anahtarı büyük ya da küçük harfle, boşluklarla ayrılmış ya da birkaç satıra yayılmış gruplar hâlinde, = ile ya da = olmadan yapıştırın — gruplar arasındaki bir tire durduğu yerde reddedilir — ya da URI’nin tamamını yapıştırın; sayfa gizli anahtarı içinden okur ve bunu belirtir. URI’nin diğer parametrelerinin ne anlama geldiği ve bir gizli anahtarın bir uygulamanın gösterdiği kodlara nasıl dönüştüğü TOTP / 2FA kod ayıklayıcının konusudur: kılavuzu URI’yi ve parametrelerini açıklar, sayfası da kodları hesaplar. URI’deki etiket ve veren, Key Uri Format belgesinin istediği gibi yüzde kodludur ve URL kodlayıcı / çözücü bunları okur.

Tor’un 3. sürümündeki bir onion adresi de Base32’dir. .onion uzantısından önceki 56 karakteri, 35 baytın Base32 karşılığıdır: hizmetin 32 baytlık genel anahtarı, iki baytlık bir sağlama toplamı ve bir sürüm baytı, 03. Tor’un belirtimi örnek adreslerini küçük harfle yazar ve 35 bayt tam grupları doldurur; bu yüzden atlanacak bir dolgu yoktur. 56 karakteri .onion olmadan yapıştırın, “Bayt gösterimi” seçicisini “On altılık” olarak ayarlayın; son bayt 03 olarak okunur.

IPFS, içerik tanımlayıcılarını, yani CID’leri, 1. sürümden itibaren varsayılan olarak Base32 ile yazar: küçük harfle ve dolgusuz, Base32’nin parçası olmayan ama onu adlandıran tek bir harften, b’den sonra — bu, geri kalanı çözülmeden önce çıkarılan multibase önekidir. Bu yüzden IPFS’in kendi belgelerindeki örnek olan bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi burada bütünüyle, hiçbir bayt dizisinin üretmediği bir uzunluk olarak reddedilir; b olmadan 36 bayt olarak, yani sürümü için 01 ile başlayan ikili CID olarak okunur.

Bir 2FA gizli anahtarı metin değil, baytlardır

Key Uri Format belgesinin örnek gizli anahtarı JBSWY3DPEHPK3PXP olarak verilir ve belge, değerini on bayt olarak tek tek sayar: Hello! karakterleri, ardından DE AD BE EF. İlk sekiz karakteri olan JBSWY3DP tek başına Hello demektir. Burada “Bayt gösterimi” seçicisi sayfanın varsayılanı olan “Metin” iken çözüldüğünde, önce Hello! çıkar, ardından U+07AD — DE AD tesadüfen tek bir karakter oluşturur, Thaana yazısının bir birleştirici işareti — ve ardından, her biri metin olmayan bir diziyi temsil eden iki U+FFFD gelir. Sonucun altındaki bir bildirim değiştirilen dizileri sayar, ilkinin 9. baytta başladığını ve bu baytın bitlerinin 1. satır, 13. sütundaki karakterde, yani 3’te başladığını söyler ve baytların hiç metin olmayabileceğini belirtir.

Gerçek bir gizli anahtar, nadiren metin oluşturan rastgele baytlardır; bu yüzden metin olarak çözüldüğünde, gizli anahtarın doğru olup olmadığı hakkında size hiçbir şey söylemeyen başıboş karakterlerden ve U+FFFD karakterlerinden oluşan bir yığına dönüşür. “Bayt gösterimi” seçicisindeki “On altılık” seçeneği tam da bunun içindir. Onu seçin ya da bildirimin yanındaki düğmeye tıklayın; aynı gizli anahtar bütünüyle 48 65 6C 6C 6F 21 DE AD BE EF olarak gösterilir: baytların kendisi, yani bir sunucunun tuttuğu ve her kodun hesaplandığı şey. Sayfa asla kendiliğinden on altılığa geçmez; bu yüzden ekranda olan her zaman sizin seçtiğinizdir.

Ters yönde de aynı seçim yapılır, bu kez kodlarken. Bir sunucunun on altılık olarak tuttuğu bir anahtar baytlardır: “Kodla” yönünü seçin, “Bayt gösterimi” seçicisini “On altılık” olarak ayarlayın ve anahtarı yapıştırın — boşluklu ya da bitişik, baytların önünde 0x ile, bir sayı dizisi olarak ya da hexdump -C veya xxd programının biçiminde bir on altılık döküm olarak — sayfa bir kimlik doğrulama uygulamasının kabul ettiği Base32’yi yazar. 48656C6C6F21DEADBEEF, yukarıdaki gizli anahtar olan JBSWY3DPEHPK3PXP olarak çıkar; on bayt tam grupları doldurur, doldurmayan bir anahtar ise, örneğin on altı baytlık bir anahtar, siz Key Uri Format belgesinin istediği gibi dolguyu kapatmadıkça ardında = ile çıkar. Çözerken yanlışlıkla yapıştırılmış on altılık rakamlar — çift sayıda on altılık rakam ve boşluk karakterleri dışında başka hiçbir şey, kodlarken bayt olarak okunabilecek şekilde — on altılık rakamlara benzediklerini söyleyen bir bildirim alır; yanında da onları kodlamaya geçen bir düğme durur. Ve çözerken “İndir”, baytların kendisini bytes.bin adlı bir dosya olarak kaydeder.

Base32 mi Base64 mü ve neden Crockford’un alfabesi değil

Base64 aynı işi altmış dört karakterle, her üç bayt için dört karakterle yapar; bu da metnini baytlardan üçte bir daha uzun yapar, Base32’ninki ise beşte üç daha uzundur. Base64’ün bunun karşılığında kaybettiği şey, harf büyüklüğünü yok sayabilmektir: alfabesi büyük ve küçük harfleri farklı değerler olarak tutar, bunlara + ve / da eklenir; bu yüzden SGk= Hi demektir, sgk= ise başka iki bayttır. Base32, harf büyüklüğünü yok sayan bir şeyden geçen ya da bir kişinin bir ekrandan okuyup başka bir ekrana yazdığı metinlere uygundur. Buraya yapıştırılan Base64, hiçbir Base32’nin yazmadığı bir + ya da / içerdiğinde ve baştan sona Base64 biçiminde olduğunda, Base64’e benzediğini söyleyen bir bildirimle ve Base64’ü metin olarak okuyan Base64 aracına giden bir bağlantıyla reddedilir.

Otuz iki karakterli başka alfabeler de vardır ve bu sayfa RFC 4648’in iki alfabesini sunar, başka hiçbirini sunmaz. Bunlardan biri Douglas Crockford’un alfabesidir: on rakamın hepsini tutar, I, L, O ve U harflerini dışarıda bırakır ve ULID biçimi onu kullanır. Crockford onu sayı yazmak için tanımladı ve baytlar üzerine yazıldığında iki cevabı vardır: 00 ile 0F arasındaki on altı bayt, RFC 4648’in baytları paketlediği gibi beşer bit hâlinde paketlendiğinde 000G40R40M30E209185GR38E1W olur; bir ULID değerinin yirmi altı karakteri nasıl okunuyorsa öyle, 128 bitlik bir sayı olarak okunduğunda ise 00041061050R3GG28A1C60T3GF olur. Baytları bu alfabeyle yazan bir sayfa, ikisinden birini sizin yerinize ve siz görmeden seçmiş olurdu.