Chilkat Tech Notes
Chilkat Tech Notes
Tips, techniques, and patterns for Chilkat developers

Chilkat Binary Encoding List

June 20, 2015 in binary encoding

Chilkat Reference

Binary Encodings Supported by Chilkat

The complete set of values accepted anywhere an encoding argument or property appears in the API.

Throughout the Chilkat API there are method arguments and properties used to indicate an encoding. These are encodings for binary data such as hex, base64, and so on.

Note — these are not character encodings. A character encoding such as utf-8 indicates the byte representation of a character. A binary encoding such as base64 represents non-character binary data in printable string form.

Wherever an encoding argument or property exists, the valid encodings supported by Chilkat are as follows. Chilkat is case-insensitive when recognizing an encoding by name — for example, both Base64 and base64 are recognized as base64.

Encoding Description Added
base64 Converts binary data into an ASCII string using 64 printable characters (A–Z, a–z, 0–9, +, /). —
base64_mime Same as base64, but the output is broken into fixed-length lines exactly as it would appear in MIME or in a PEM. 9.5.0.67
modbase64

(base64url)
 A URL- and filename-safe variant of Base64: + becomes - and / becomes _. —
base62 Represents binary or numeric data using 62 printable characters (0–9, A–Z, a–z), making it URL- and filename-safe with no extra escaping. 11.2.0
base58 Excludes visually ambiguous characters (0, O, I, l) and non-safe symbols, so the result is URL- and filename-safe. Widely used for Bitcoin addresses. —
base45 Encodes data using a 45-character set of digits, letters, and select punctuation (as used, for example, in QR-code data). 9.5.0.99
base32 Uses 32 characters (A–Z and 2–7) with padding. Well suited to case-insensitive systems. —
hex Uppercase hexadecimal, two characters (0–9, A–F) per byte. For example, Hello encodes as 48656C6C6F. —
hex_lower Hexadecimal encoding, but using lowercase a–f instead of uppercase A–F. —
uu Unix-to-Unix encoding, historically used for binary email attachments on early Unix systems. —
qp

(quoted-printable)
 Encodes bytes as = followed by two hex digits. Commonly used in email/MIME to safely transmit special characters. —
url

(url_rfc3986)
 Percent-encoding per RFC 3986, replacing reserved characters with % plus their hex value (a space becomes %20). —
url_rfc1738 The older URL-encoding standard (RFC 1738), in which a space is encoded as + rather than %20. —
Q MIME Q-Encoding for email header fields: a space becomes _ and other bytes are written as =XX. —
B MIME B-Encoding — a Base64-based mechanism for encoding non-ASCII characters in email header fields. —
fingerprint Lowercase hex in which each byte is separated by a colon — e.g. 6a:de:e0:af:56:f8:0c:04. 9.5.0.55
decimal Converts large decimal integers to and from a big-endian binary representation. 9.5.0.55
eda Encodes and decodes to the UN/EDIFACT Syntax Level A character set. 9.5.0.65
json Escapes and unescapes JSON strings (backslash-escaping characters that would otherwise disrupt JSON). 9.5.0.66
decList Converts comma-separated lists of decimal integers (each 0–255) to bytes and back. See the note below. 9.5.0.66
ascii85 Encodes every 4 bytes as 5 ASCII characters — roughly 25% overhead, more compact than Base64’s 33%. 9.5.0.79

Notes on Selected Encodings

fingerprint

A lowercase hex encoding where each hex byte is separated by a colon. For example:

6a:de:e0:af:56:f8:0c:04:11:5b:ef:4d:49:ad:09:23

decimal

For converting large decimal integers to and from a big-endian binary representation. For example, the decimal string 72623859790382856 converts to the bytes:

0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08

decList

For converting comma-separated lists of decimal integers to bytes and back. Each decimal integer is a value from 0 to 255. For example:

84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110

Tip: Encoding names are case-insensitive. Base64, BASE64, and base64 are all recognized identically.