Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Elegance of the ASCII Table

danq.me

Post reply on HN
Print view View original

91–100 of 189 posts

Re: The Elegance of the ASCII Table

#91

Post by mnau »

WalterBright wrote: post #52

Too bad we now have Unicode, an elegant castle covered with ugly graffiti and ramshackle addons. For example: 1. normalization 2. backwards running text (hey, why not add spiral running text?) 3. fonts 4. invisible characters 5. multiple code points with the same glyph 6. glyphs defined by multiple code points (gee, I thought Unicode was to get away with that mess from code pages!) 7. made up languages (Elvish? Come…

As someone that whose native language isn't representable purely by ASCII, I celebrate it. Plus the first 128 codepoints are same as ASCII in UT-8.

Is Unicode kind of messy? Sure, but that's just natural consequences of writing systems being messy. Every point you made was for a sensible reason that is in a scope of Unicode mission (representing all text in all writing systems).

Re: The Elegance of the ASCII Table

#92

Post by fukawi2 »

BobbyTables2 wrote: post #12

I always lament that since at least 1980s or so, it seems the vast majority of the control characters were never used for their intended purpose. Instead, we crudely use commas and tabs as delimiters instead of something like RS (#30).

I recall working on a PICK D3 system, which was a "multivalue" database. Each field could have multiple values, those values could have sub values, and a third level beyond that.

Values were separated with char(254), subvalues were separated with char(253), and the third level were char(252) separated.

It was... unique, but worked. And to be fair, PICK originated in the 60's, so this method probably evolved in parallel to the ASCII table!

Re: The Elegance of the ASCII Table

#93

Post by red_admiral »

The "16 rows x 8 columns" version, with the lowercase letters added, seems the most elegant one to me because it makes the internal structure of the thing visible. For example, to lowercase a letter, you set bit 6; a decimal digit is the prefix 011 followed by the binary encoding of the digit etc.

It also makes clear why ESC can be entered as `^[` or ENTER (technically CR) as `^M` on some terminals (still works in my xterm), because the effect of the control key is to unset bits 6 and 7 in the original set-up.

Of course you can color in the fields too, if you want.

Re: The Elegance of the ASCII Table

#94

Post by red_admiral »

BobbyTables2 wrote: post #12

I always lament that since at least 1980s or so, it seems the vast majority of the control characters were never used for their intended purpose. Instead, we crudely use commas and tabs as delimiters instead of something like RS (#30).

As long as your data is not binary, so does not contain record separators itself, this would be a thousand times better than CSV (because text data _does_ often contain commas and double quotes).

The only thing you'd need is editors to support some way of entering and displaying the RS, and CTRL+^ is a bit of a kludge as it ends up CTRL+SHIFT+6.

Of course, if a record itself can contain RS for subrecords, things become more complicated. I guess you could use `\^`.

Re: The Elegance of the ASCII Table

#95

Post by red_admiral »

theamk wrote: post #29
EvanAnderson wrote: post #20

Earlier quoted context omitted.

I did some ETL work that used the ASCII delimiter characters. It was very enjoyable. I didn't have to worry about escaping or parsing escaped strings. The control codes were guaranteed to be illegal in input. It was refreshing.

Could you do the same with TSV? A lot of datasets can either prohibit tabs in data, or convert it to spaces in early ingestion.

Yes, and as long as you remember to turn off the "TAB produces 4 spaces" thing in your editor (grumble makefiles grumble) it's really nice to work with.

Re: The Elegance of the ASCII Table

#96

Post by omnicognate »

dailykoder wrote: post #81
augusto-moura wrote: post #67

Useful tip, on linux (not sure about other *nixes) you can view the ascii table by opening its manpage: man ascii It's been useful to me more than once every year, mostly to know about shell escape codes and when doing weird character ranges in regex and C. It can be a bit confusing, but the gist is that you have 2 chars being show in each line, I would prefer a view where you see the same char with shift and/or ctrl…

Damn, thanks! Why the hell did I never try this? Maybe because typing ascii table into my favorite search engine and clicking one of the first links was fast enough

I used to do that until the experience became degraded enough, reflecting the general state of the web, that I took the time to look for a better way and found `man ascii`.

Re: The Elegance of the ASCII Table

#97

Post by layer8 »

augusto-moura wrote: post #67

Useful tip, on linux (not sure about other *nixes) you can view the ascii table by opening its manpage: man ascii It's been useful to me more than once every year, mostly to know about shell escape codes and when doing weird character ranges in regex and C. It can be a bit confusing, but the gist is that you have 2 chars being show in each line, I would prefer a view where you see the same char with shift and/or ctrl…

Or even simpler use the ascii command, when installed: https://packages.debian.org/bookworm/ascii

Re: The Elegance of the ASCII Table

#98

Post by layer8 »

jolmg wrote: post #10

> So when you’re reading 7-bit ASCII, if it starts with 00, it’s a non-printing character. Otherwise it’s a printing character. > The first printing character is space; it’s an invisible character, but it’s still one that has meaning to humans, so it’s not a control character (this sounds obvious today, but it was actually the source of some semantic argument when the ASCII standard was first being discussed). Hmm..…

Space is what is represented in the output, i.e. in one cell of the terminal grid, whereas control characters like Tab and CR/LF don’t map onto such an output representation. If you want to represent the printed contents of each “grid cell” of a printout or a textmode screen buffer, you don’t need the control characters, only the printable characters. The printable characters are what you’d need in a screen font.

Re: The Elegance of the ASCII Table

#99

Post by bregma »

snvzz wrote: post #75

The ASCII table is defective; it is missing a dedicated code for newline. CR and LF aren't dedicated, and have precise cursor movement meanings, rather than being a logical line ender. There was a proposal in the 80s to reassigning the -otherwise useless- VT (vertical tab) character for the purpose. Unfortunately unfruitful.

A separate control character was not needed to indicate where your Hollerith string ended: it ended at the end of the Hollerith string. If you wanted to render a Hollerith string onto print media, you'd often want to feed the line and then return the carriage before printing the next Hollerith string. Of course, that wasn't strictly necessary if you were using a line printer, which would just print the line and advance.

The filesystems I used had 5 kinds of file: random-access, sequential, ISAM, Fortran-carriage-control and carriage-return-carriage-control. The only people who used the latter were the eggheads that used that new-fangled C programming language brought over from Bell Lab's experimental Unix system.

You're probably just looking for the record separator (036). If you are storing multiple text records and a block of memory, that would be the ideal ASCII code to separate them.

Re: The Elegance of the ASCII Table

#100

Post by gumby »

kr2 wrote: post #73
kalleboo wrote: post #39

Earlier quoted context omitted.

It was at some point looking at a chart like that where it also dawned on me where the control codes like ^D, ^H, ^[ etc came from

I was going to ask you to please explain as I didn't understand, but I am guessing you are talking about the same thing as this comment[1] right? That's super cool https://news.ycombinator.com/item?id=41042570

Yes, though ^m, ^[ et al aren’t so much elegant as coincidental; but look at A and a, for example.

I found the chart I was looking for: https://en.wikipedia.org/wiki/ASCII#/media/File:USASCII_code...

Post reply on HN