Kodowanie jest przydatne tylko wtedy, gdy oba końce się na to zgadzają. Najmniejsza reprezentacja niekoniecznie jest najlepszym wyborem, gdy odbiorca potrzebuje znanego alfabetu, ładunek musi zostać wpisany przez osobę lub otaczająca składnia traktuje pewne znaki w specjalny sposób. Zacznij od protokołu odbioru.
Hex jest gadatliwy, ale łatwy do sprawdzenia
W trybie szesnastkowym każdy bajt jest zapisywany jako dwie cyfry. Sekwencja bajtów FF 00 41 staje się ff0041. Każda para ma widoczną granicę bajtów, co pomaga podczas sprawdzania podpisów plików, sum kontrolnych i pakietów protokołów. Podwaja liczbę znaków, ale jego mały alfabet zwykle łatwo mieści się w dziennikach i narzędziach do debugowania.
Base64 równoważy rozmiar i interoperacyjność
Base64 reprezentuje trzy bajty z czterema znakami. Jest to powszechne dopasowanie pól binarnych w formatach tekstowych. Standard Base64 zawiera plus i ukośnik; Base64URL zastępuje te znaki, gdy protokół wymaga innego alfabetu. Zasady dopełniania i białych znaków nadal wymagają uzgodnienia. Żadna z form nie informuje odbiorcy, czy zdekodowane bajty są tekstem, obrazem, czy skompresowaną treścią.
Kodowanie procentowe należy do komponentów URL
Kodowanie procentowe zapisuje bajt ucieczki jako %HH. Nie jest to po prostu masowy zamiennik Base64. Komponent określa, które znaki muszą zostać zmienione, a tekst powinien zostać najpierw zakodowany jako UTF-8. Ukośnik może oddzielić segmenty ścieżki, podczas gdy znak zapytania rozpoczyna zapytanie; traktowanie całości URL jako jednego nieprzezroczystego elementu zmienia jego znaczenie.
console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87Base85 wymaga dokładnego wariantu
Wiele schematów Base85 reprezentuje cztery bajty z pięcioma znakami, ale ich alfabety, ograniczniki i przypadki specjalne są różne. Nie można zakładać, że ASCII85 i Z85 są zamienne. Z85 nakłada również wymagania dotyczące rozmiaru bloku. Alfabet o dużej gęstości może zawierać znaki interpunkcyjne, które należy ponownie zmienić w otaczającym formacie, zmniejszając widoczne korzyści.
Nie należy mylić tego kodowania bajtów z konwersją liczby całkowitej 255 pomiędzy podstawami liczbowymi. Plik może zaczynać się od bajtów zerowych, podczas gdy reprezentacja całkowita może odrzucić te zera wiodące. Odwracalny kodek pliku musi definiować sposób zachowania długości i zer wiodących.
Użyj szesnastkowego do kontroli bajtów, określonego wariantu Base64 do interoperacyjnego transportu binarnego, kodowania komponentowego URL dla adresów URL i wyspecjalizowanego schematu tylko wtedy, gdy obie strony wdrażają tę samą umowę. Porównaj rozmiar od końca do końca po ucieczce i kompresji. RFC 4648 definiuje standardowe rodziny Base16, Base32 i Base64, łącznie z ich odrębnymi alfabetami.