Volt
00000000

Guide

EBCDIC on macOS: opening, editing and converting

A file came off a mainframe and every editor on your Mac shows gibberish. Here is why, which of the seventeen EBCDIC code pages you probably need, and how to read it, change it and write it back.

What EBCDIC is, and why the file looks like rubbish

EBCDIC is IBM's character encoding, still in daily use on z/OS and its ancestors. It is not ASCII and it is not a superset of it: the letters are not contiguous, the digits sit at F0–F9, and a space is 0x40 rather than 0x20. Open an EBCDIC file in an editor that assumes UTF-8 and you get a screen of accented punctuation, because every byte is being read as the wrong character.

There is no single EBCDIC. There are dozens of national code pages that agree on the letters and disagree on almost everything else — which byte is a dollar sign, a hash, a square bracket, an umlaut. Reading a German file as the American page gives you text that is almost right, with a handful of characters quietly wrong, which is worse than obviously broken.

The sixty-two code pages Volt reads and writes

Western Europe and the Americas

  • 037 — US, Canada
  • 273 — Germany, Austria
  • 274 — Belgium
  • 275 — Brazil
  • 277 — Denmark, Norway
  • 278 — Finland, Sweden
  • 280 — Italy
  • 282 — Portugal
  • 284 — Spain, Latin America
  • 285 — United Kingdom
  • 297 — France
  • 500 — International
  • 871 — Iceland
  • 924 — Latin 9
  • 1047 — Latin 1, Open Systems

The euro revisions

  • 1140 — US, Canada, euro
  • 1141 — Germany, Austria, euro
  • 1142 — Denmark, Norway, euro
  • 1143 — Finland, Sweden, euro
  • 1144 — Italy, euro
  • 1145 — Spain, Latin America, euro
  • 1146 — United Kingdom, euro
  • 1147 — France, euro
  • 1148 — International, euro
  • 1149 — Iceland, euro
  • 1153 — Central European, euro
  • 1154 — Cyrillic multilingual, euro
  • 1155 — Turkey, euro
  • 1156 — Baltic multilingual, euro
  • 1157 — Estonia, euro
  • 1158 — Ukraine, euro
  • 1160 — Thailand, euro
  • 1164 — Vietnam, euro

Central Europe

  • 870 — Central European
  • 1112 — Baltic multilingual
  • 1122 — Estonia

Cyrillic

  • 880 — Cyrillic
  • 1025 — Cyrillic multilingual
  • 1123 — Ukraine
  • 1166 — Kazakhstan

Greek

  • 423 — Greece, superseded
  • 875 — Greece

Turkish

  • 905 — Turkey, Latin 3
  • 1026 — Turkey, Latin 5
  • 1175 — Turkey, euro and lira

Middle East

  • 420 — Arabic
  • 424 — Hebrew
  • 425 — Arabic, Latin
  • 803 — Hebrew, Character Set A
  • 918 — Urdu
  • 1097 — Farsi

Asia

  • 281 — Japan, Latin
  • 290 — Japan, Katakana
  • 1027 — Japan, Latin extended
  • 838 — Thailand
  • 1130 — Vietnam
  • 1132 — Laos
  • 1137 — Devanagari

Japanese — single- and double-byte

  • 930 — Japanese Katakana-Kanji
  • 939 — Japanese Latin-Kanji
  • 1390 — Japanese Katakana-Kanji, JIS X 0213
  • 1399 — Japanese Latin-Kanji, JIS X 0213

Each one is read and written, so a file can be opened, changed and saved back in the page it arrived in — or converted to UTF-8 on the way out, if that is what the next system wants.

Which page it picks, and why it tells you

Volt chooses by reading: it tries the candidates and keeps the one whose result looks most like language rather than assuming the American page because it is the common one. The status bar then says which it chose and on what evidence, because a guess you cannot see is a guess you cannot correct.

Two of the pages are deliberately never guessed at. Greek (875) and Cyrillic (880) produce byte patterns that are indistinguishable from ordinary Latin words, so no amount of scoring can tell them apart honestly. You pick the page from the menu and it reads perfectly — a question asked is better than an answer invented.

Choosing a different page afterwards asks the question that matters: re-read these bytes as that page, or convert the text into it? Those are opposite operations and most editors do not ask.

The line-ending trap

An EBCDIC file usually has no 0x0A in it at all. Its line ending is NEL, byte 0x15 — a real line ending in every Unicode sense, and one most editors have never heard of. That is why a mainframe export so often appears as a single line several megabytes long.

Volt reads nine kinds of line ending, NEL among them, decides which one a file uses from the converted bytes rather than the raw ones, and writes back what it found.

And the files with no line endings whatsoever

Plenty of mainframe data has no terminator of any kind: IBM RDW variable-length records with a four-byte descriptor, or fixed-width 80- and 132-column records where the length is the whole convention. Volt turns those into lines when the file opens and puts the padding back when it saves. More on mainframe files on a Mac.

Opening one

  • Open the file. If it is recognisably EBCDIC, it is read as EBCDIC, and the status bar names the page.
  • If the page is wrong — or it is Greek or Cyrillic, which are never guessed — pick the right one from the character-set menu and choose to re-read the bytes.
  • Edit it as ordinary text.
  • Save it back in the same page, or convert to UTF-8 on the way out.
  • If you would rather see what is actually there, the hex view shows offsets, bytes and the printable column side by side.

Questions

How do I open an EBCDIC file on a Mac?

Open it in an editor that knows the encoding. Volt reads sixty-two EBCDIC code pages and picks the one whose result looks most like language, then says in the status bar which it chose. If the guess is wrong, or the file is Greek or Cyrillic EBCDIC, choose the page from the character-set menu and re-read the bytes.

Why does my EBCDIC file open as one enormous line?

Because its line ending is NEL, byte 0x15, not the line feed 0x0A that most editors look for. The file has no 0x0A in it at all, so an editor that only knows LF and CRLF sees a single line several megabytes long. Volt reads NEL as the line ending it is.

Can I convert EBCDIC to UTF-8?

Yes. Open the file in its code page, then save it as UTF-8; the character set and the line endings are converted in the same pass. The reverse works too — a file edited on a Mac can be written back in the EBCDIC page it came from.

Which EBCDIC code pages are supported?

62: 58 single-byte national pages, grouped above by region, and 4 Japanese pages that mix single- and double-byte characters — plus the generic US page. All of them are read and written.

Why does Volt not detect Greek, Cyrillic, Arabic or Hebrew EBCDIC automatically?

Because those pages put their letters where the ASCII alphabet lives, so their bytes are indistinguishable from ordinary Latin words, so any automatic choice would be a coin toss presented as a fact. Volt asks instead, and reads the file perfectly once you have said which page it is.

Try it on your own file

Volt is in private beta. Join the waitlist and you will be invited when the next round goes out — one email, and then one question about what to build next.

Join the waitlist