The classic alphabet. Percent-encode it before putting it in a URL.
Isinusulat muli ng Base64 ang kahit anong bytes gamit ang 64 na naipapakitang karakter, para makadaan sila sa isang bagay na teksto lamang ang dala — isang URL, email header, JSON string, o HTML attribute.
Ginagawa munang UTF-8 bytes ang teksto, at ang bytes ang siyang ini-encode. Iyon ang ibig sabihin ng bawat ibang implementasyon sa "Base64 ng isang string", at iyon ang dahilan kung bakit ligtas dito ang tandang piso, ang ñ at ang emoji. Ang function ng browser na pinagpapatungan ng karamihan sa online na tool ay Latin-1 lamang: nagkakamali ito sa anumang lampas sa U+00FF, at ang ₱ ay U+20B1.
Pabaligtad ding tumatakbo ang pag-decode, may isang pagtanggi. Kapag hindi wastong UTF-8 ang bytes — dahil larawan o compressed na file ang idinikit mo — hindi ito ipapakita ng pahina bilang teksto. Ginagawa itong hanay ng replacement character ng mapagbigay na decoder, na parang sagot pero hindi. Bilang ng bytes at hex preview ang makukuha mo sa halip.
Hindi, at ito ang pagkakamaling mahalaga. Ang Base64 ay paraan ng pagsulat ng bytes gamit ang 64 na naipi-print na karakter para makaligtas sila sa daluyang teksto lang ang dala — header ng email, data URL, string ng JSON. Kayang i-decode ito ninuman sa isang segundo, pati rito sa pahinang ito. Huwag itong gamitin para itago ang password, API key o anumang hindi mo ilalathala.
Dahil naka-encode ito bilang Latin-1 at hindi UTF-8. Isang karakter ang ₱ pero tatlong byte, at tinatanggihan agad ng browser function na pinagbatayan ng karamihan sa mga tool ang anumang lampas 255. Ini-encode nito ang UTF-8 na bytes, kaya buo ang ₱, ñ, Baybayin at emoji pagkatapos ng balikan.
Ang huling dalawang karakter lamang. Gumagamit ang karaniwang Base64 ng + at /, na pareho may kahulugan sa loob ng URL at kailangang i-escape. Gumagamit ang URL-safe na alphabet ng - at _ para maipasok ang resulta sa link o pangalan ng file nang walang binabago. Wala nang ibang nagbabago, at nade-decode ng pahinang ito ang alinman nang hindi sinasabi kung alin.
Dahil ang tatlong byte ay isinusulat na apat na karakter. 33% na pagtaas iyon, dagdag ang hanggang dalawang padding na karakter. Iyon ang kapalit ng paggamit lamang ng mga karakter na hindi nasisira kapag kinopya, ni-paste at ipinadala sa email.
Oo. Binabalot ng email attachment ang Base64 sa 76 karakter kada linya, at nagdaragdag ng sariling putol ang pagkopya mula sa terminal. Hindi pinapansin ang espasyo sa pag-decode, at sinasabi ng pahina kapag may hindi nitong pinansin.
May na-decode kang hindi kailanman teksto — larawan, PDF, naka-compress na file. Sa halip na ipakita sa iyo ang hanay ng mga pamalit na karakter na mukhang sirang sagot, ipinapakita ng pahina ang bilang ng byte at ang mga unang byte sa hex para makita mo kung ano talaga ito.
Hindi nahahati nang pantay ang anim na bit sa walo, kaya ang habang hindi multiplo ng tatlo ay nag-iiwan ng bahagyang grupo. Sinasabi ng padding kung ilang byte talaga ang laman ng huling grupo: isang = ay dalawang byte, dalawa ay isa. May mga sistemang inaalis ito, kaya nagde-decode ang pahina mayroon man o wala.
Ang unang tatlo ay ang test vectors ng RFC 4648. Ang pang-apat ay isang karakter at tatlong byte, at ito ang sumisira sa Latin-1 na encoder.
Ang Base64 ay encoding, hindi encryption — mababasa ninumang makakita ang anumang ini-encode mo rito. Walang ipinapadala sa mga server namin ang tina-type mo rito — sa browser mo tumatakbo nang buo ang pagkuwenta.
