## 2 Related Works  
To define the possible applications of the proposed framework to an encoding method, it is useful to recall some of the binary-to-text mappings presently available and used in computer systems. Base64 was introduced many years ago and standardized in 1992: it encodes 3 bytes (24 bits) with 4 printable characters each encoding 6 of the 24 bits. The characters are thus chosen from a set of \(2^{6}=64\) symbols, namely the 26 letters of the English alphabet, uppercase and lowercase, the 10 decimal digits and 2 special characters that may differ among the various standardized applications. The most recent definition of the Base64 encoding may be found in [13]: in that RFC also the Base32 and Base16 representations are specified. Base32 encodes groups of 5 bytes (40 bits) in 8 printable characters each representing 5 bits: thus, 32 possible characters are needed (the 26 uppercase letters of the English alphabet and the digits from 2 to 7). For Base64 and Base32 the character '=' is used for padding the encoded string when the number of input bytes is not a multiple of 3 or 5, respectively. Base16 is simply the hexadecimal representation of the input bytes using the decimal digits and the uppercase letters from 'A' to 'F' (some implementations may differ from [13] and allow the use of lowercase letters from 'a' to 'f'); by construction this encoding does not need any padding. Base45 is defined in the work in progress [10] and is developed for encoding data as text in QR codes. The symbols it uses are the 10 decimal digits, the 26 letters of the English alphabet, the space and the other 8 special characters. The encoding takes pairs of bytes and converts the number in Base45 using 3 digits (in a little-endian way, i.e., the leftmost character is the least significant); in case of a binary string having odd length then the last byte is converted in 2 base 45 digits. It is interesting to note that not all 3 digit numbers in base 45 can be converted in a binary number having at maximum 16 bits: in fact, from the sequence 'GGW' (representing \(2^{16}=65,536\)) to the sequence '::' more than 16 bits are needed to write the corresponding number in binary format; these sequences are considered unacceptable by the standard and accordingly rejected. Base85, also called Ascii85 in [11], encodes 4 bytes using 5 characters from an alphabet of 85 symbols (a subset of the ASCII characters, from the code 33, 'I', to the code 117, 'u'). An exception is made for the binary value 0 which, instead of being encoded as '!!!!!! ', is encoded as 'z'. The version of this coding presented in [11] uses a delimiter (namely '\(\sim\)') to mark the ending of the character sequence. Moreover, to cope with binary strings having a length that is not a multiple of 4, a particular padding method in encoding and decoding is used. During decoding, a 'z' character in a 5-character sequence is an error. Also, as in the analogous case of Base45, a 5-character sequence decoding to a value greater than or equal to 232 is regarded as an error and not accepted. The base 85 is also used in an encoding of IPv6 addresses [12]. Encodings using Base91 are presented in [14; 15]. In [14], the authors propose an encoding that splits the input binary string into 13-bit words and encodes the resulting binary numbers in pairs of characters using an alphabet of 91 symbols (the printable ASCII characters from '!' to '\(\sim\)' excluding '\(\sim\)', \(=\)' and '\(\sim\)'). To cope with bit strings having a length not being a multiple of 13, 12 pairs are reserved to encode how many unused bits are present in the last 13-bit word: this encoding leaves \(91^{2}-2^{13}-12=77\) unused Base91 pairs. The encoding used in the source code in [15] makes use of all the \(91^{2}\) character pairs; in fact, 13 bits are encoded with 2 Base91 characters unless the value to be encoded is less than 89: in that case 14 bits are encoded adding as a significant bit one more bit from the binary string to encode. This implies the use of \(2^{13}+89=91^{2}\).