Character Encoding Explained: ASCII, EBCDIC, Hex & Binary

Character encoding is the foundation of how computers represent text. ASCII and EBCDIC are the two oldest encoding systems, and understanding them — especially their differences — is essential when working with legacy payment systems, mainframes, and HSMs. This guide covers both encodings and how to convert between them.

What is Character Encoding?

Character encoding maps characters (letters, digits, symbols) to numeric values that computers can store and process. The letter A doesn't exist in memory — instead, it's stored as a number: 65 in ASCII or 193 in EBCDIC.

Every piece of text you encounter uses some encoding. If you interpret bytes with the wrong encoding, you get garbled output — this is the classic "mojibake" problem.

ASCII

ASCII (American Standard Code for Information Interchange) was published in 1963 and became the dominant encoding for English text.

ASCII Table Structure

• 128 characters (0-127), using 7 bits
• Control characters: 0-31 and 127 (non-printable)
• Printable characters: 32-126

Key ranges:

Common Control Characters

ASCII in Modern Systems

ASCII is the foundation of virtually all modern encodings. UTF-8 is backward-compatible with ASCII — any valid ASCII text is also valid UTF-8. This is why ASCII knowledge remains essential.

EBCDIC

EBCDIC (Extended Binary Coded Decimal Interchange Code) was developed by IBM in 1963-1964 for their System/360 mainframe. It remains in use on IBM mainframes (z/OS) and AS/400 (IBM i) systems.

EBCDIC Table Structure

• 256 characters (0-255), using 8 bits
• Different layout from ASCII — this is where confusion arises
• Gaps in the letter ranges (not contiguous)

Key ranges:

Note the gaps — EBCDIC letters are not contiguous like ASCII. This makes range-based character checks more complex.

EBCDIC in Payment Systems

EBCDIC is still widely used in:

• IBM mainframes (z/ISO-TP, z/VSE) processing financial transactions
• Payment switches running on mainframe platforms
• ATM networks using ISO 8583 messages in EBCDIC
• Card processing systems where legacy mainframe integration is required

Many HSMs support EBCDIC because they interface directly with mainframe payment systems.

ASCII vs EBCDIC Comparison

The Digit Offset

A useful fact: in ASCII, digits start at 48 (hex 30). In EBCDIC, digits start at 240 (hex F0). To convert a digit character to its numeric value:

• ASCII: char - 0x30 (e.g., '5' = 0x35, so 0x35 - 0x30 = 5)
• EBCDIC: char - 0xF0 (e.g., '5' = 0xF5, so 0xF5 - 0xF0 = 5)

Hex and Binary Representation

Each encoding maps to specific hex values. Understanding hex representation is critical for HSM and payment work:

Example: "HELLO" in Different Encodings

The same word produces completely different byte sequences depending on encoding.

Converting Between Encodings

To convert text between ASCII and EBCDIC, you need a translation table that maps each character from one encoding to the other. This is not a simple arithmetic operation — it requires a lookup.

Common conversion approach:

1. Look up the source byte in the source encoding table → get the character
2. Look up the character in the destination encoding table → get the destination byte

Encoding Compatibility Issues

Data Corruption

When EBCDIC-encoded data is interpreted as ASCII (or vice versa), the result is garbled:

EBCDIC bytes: C8 C5 D3 D3 D6  (represents "HELLO")
Interpreted as ASCII: ÈÅÓÓÖ  (meaningless characters)

This is a common issue when transferring data between mainframes and modern systems.

ISO 8583 Messages

ISO 8583 payment messages can be encoded in either ASCII or EBCDIC depending on the system. When an HSM processes these messages, it must know which encoding is used. Mismatched encoding causes:

• Incorrect PAN extraction
• Wrong MAC calculation
• Failed PIN block processing

HSM Communication

Many HSMs (especially Thales/PayShield) use ASCII for command communication, but some IBM-compatible HSMs use EBCDIC. Always check your HSM documentation.

Practical Applications

Mainframe Integration

When integrating modern applications with IBM mainframes:

• Convert request from ASCII to EBCDIC before sending
• Convert response from EBCDIC to ASCII after receiving
• Handle numeric fields carefully (packed decimal, BCD)

Debugging Payment Messages

When debugging ISO 8583 or APDU commands:

• Check which encoding is expected
• Convert hex values to characters using the correct table
• Look for common patterns: digits (ASCII 30-39, EBCDIC F0-F9)

Log Analysis

Mainframe logs are often in EBCDIC. When analyzing these logs on modern systems, you need to convert the text to be readable.

Extended ASCII and Code Pages

Beyond basic ASCII (0-127), extended ASCII (128-255) varies by code page:

• CP437: Original IBM PC character set
• CP850: Multilingual Latin I
• ISO 8859-1 (Latin-1): Western European
• Windows-1252: Superset of Latin-1

Similarly, EBCDIC has multiple code pages (CP037 for US English, CP500 for international).

Try It Yourself

Use our Character Encoding Converter to:

• Convert text between ASCII, EBCDIC, Hex, Binary, and Base64
• View the complete ASCII and EBCDIC tables side by side
• Debug encoding issues by seeing byte-level representation
• Translate mainframe data for modern system analysis

All processing happens in your browser — your data never leaves your device.