10

As ASCII is a 7-bit code set, and ISO 646 cannot satisfy needs of many languages, variable-length ISO 2022/EUC was developed, which introduced C1 control codes.

However, C1 have hardly left any impression nowadays beyond 0x85 Next Line. Unicode just ignores other C1 control codes. Moreover, EBCDIC control codes were not compatible, so a large market doesn't adopt it either.

Were they widely used before? And to what extent? Note it's not about the usage by ISO/ECMA standard, but how they were used in real life.

2
  • Do you specifically care about the values between 0x80 and 0x9f inclusive in ISO 8859 encodings, or just the functional meanings? Because in the second case, a handful of them (especially CSI and to a lesser extent OSC) are used all over the place in terminal applications, albeit in Fe escape forms instead of the single-byte forms. May 21 at 11:43
  • @AustinHemmelgarn Yeah. Merging ISO 8859 Latin codepages to ONE is favorable. Since escape code itself doesn't take console position, extra byte is acceptable to me.
    – Schezuk
    May 21 at 13:04
7

Within DEC, "all the time". Why send two bytes down a wire at a lousy 300-to-1200 bps when one byte would do?

DEC terminals from the VT200 series onwards supported an 8-bit character set known as "DEC standard 169", a close cousin to ISO 8859-1 (there were a couple of different character assignments). I'm pretty sure the C1 controls were specified as part of DEC 169.

"DEC 169" may have been internal jargon; Wikipedia calls it the "DEC multinational character set". And it jogged my memory - the main differences in displayable characters is y-with-diaresis and o-e-ligature (in both cases).

At one point in my life I wrote the front end of an IBM 3270 terminal emulator that ran on DEC VAXen, which used practically all of the VT200 cursor-movement repertoire.

In particular, the single-byte CSI was used instead of the two-byte equivalent, ESC [.

6

However, C1 have hardly left any impression nowadays beyond 0x85 Next Line.

Not restricted to C1. Not much of any control character has still an 'impression' nowadays.

Unicode just ignores other C1 control codes.

Sorry to disappoint you, but Unicode does define all of them as part of the C1 Controls and Latin-1 Supplement page. What to do with them concerns Unicode as much as with (almost) any other character ... not at all.

Moreover, EBCDIC control codes were not compatible, so a large market doesn't adopt it either.

Depends on you each ones value for $LARGE_MARKET, doesn't it? While I do agree that the /370 world is all one needs to know, others did have as well some impact - and most modern stuff is rather based on their heritage.

For example the DEC linage as one of the more prominent ones. Here Terminals did use a good number of these codes.

Were they widely used before?

Yes. Right of my memory the VT220 supports codes like

  • HTS, IND, RI, NEL and more for cursor handling.
  • SS2 and SS3 for single code shifts
  • DCS and ST for keyboard programming

And most important of all: CSI to reduce transmission overhead.

In fact, I always feel that many (if not all) of these extensions were made to fit what DEC had in mind for their terminals.

And to what extent?

Well, there might be many more with other terminal variants. Also, ANSI.SYS for MS-DOS does as well support some, so essentially next to all (MS-)DOS machines running2.0 and up:))

2
  • Aren't the C1 control codes in ANSI all C0 esc formatted on PC? CP437 assigned 0x80-0x9F to extended Latin characters.
    – Schezuk
    May 21 at 4:38
  • 2
    @Schezuk Keep in mind that codes are what you make of it. CP437 (like so many micro computer code sets) also assigns glyphs to all C0. After all, it's a DISPLAY charset, defining what a display should make if these codes ends up being displayed, nothing else.
    – Raffzahn
    May 21 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.