Live data from Hacker News

The Elegance of the ASCII Table

danq.me

181–189 of 189 posts

Re: The Elegance of the ASCII Table

#181
post #169

Earlier quoted context omitted.

I'm sure that books can be printed in your language without any need for semantic information in the characters.

How do you Ctrl+F in a printed book? Why printed when we're taking about digital?

If you search for 'a', which one of the Unicode 'a's will it find?

Re: The Elegance of the ASCII Table

#182
post #169

Earlier quoted context omitted.

How do you Ctrl+F in a printed book? Why printed when we're taking about digital?

If you search for 'a', which one of the Unicode 'a's will it find?

the one in your language's alphabet, not just anything that looks similar

Re: The Elegance of the ASCII Table

#183
post #178
post #177

Earlier quoted context omitted.

"Ą" is a separate letter in polish alfabet, not an accented variant of "A". There are writing systems where combining accents are used to represent just variation on a letter. Use of combining characters for "Ą" (and "Ć" and "Ł" and many other so-called "polish letters") is, at best, a historical artefact of trying to write them in deficient encodings.

It doesn't matter that it's a separate letter in an alphabet, you're denying the obvious - it IS an accented (or ogonek'ed) variant of A, and you can achieve this in Unicode in 2 ways: having one id for a precomposed variant and composing the variant from two ids. There is no semantic difference, just an encoding one, the end result looks the same and means the same thing (well, to a point, it still depends on the co…

This is correct, and you can look into Unicode Normalized Form C (NFC) to find the conversion and equivalence rules.

Re: The Elegance of the ASCII Table

#184
post #159
post #140

Earlier quoted context omitted.

> Unfortunately unfruitful. Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.

>widespread use We are talking about the early 80s at worst. It would have consolidated by now.

I'm not sure I'm following. We have had multiple line endings (based on combinations of two particular characters) in common use, without consolidating to a common standard, for decades -- why would introducing a third character have made that more likely?

Re: The Elegance of the ASCII Table

#185
I mean, this elegant design is just a necessity of efficient processing and is found in many places, it's throughout digital communications protocols for example. Look at IP addressing. In that sense all early computing is elegant since it had to be on the limited resources of the times.

Re: The Elegance of the ASCII Table

#186
post #184
post #159

Earlier quoted context omitted.

>widespread use We are talking about the early 80s at worst. It would have consolidated by now.

I'm not sure I'm following. We have had multiple line endings (based on combinations of two particular characters) in common use, without consolidating to a common standard, for decades -- why would introducing a third character have made that more likely?

Because the reason consolidation has not happened is simple: There's no right answer, as there's no code explicitly defined by ASCII for ending a line. A major oversight.

If a code had been timely assigned, we'd have the correct way (predominant), and the legacy ways (mostly gone by now).

Re: The Elegance of the ASCII Table

#187
post #72

Earlier quoted context omitted.

Yes, that’s very intentional and just masking (or setting) the bit is the intended way to do case-insensitive comparison of the letter range in ASCII (eg. stricmp in C), or to transform text to lower or upper case (tolower, toupper). But what’s more, ever wondered whence the control (Ctrl) key presses like Ctrl-H to backspace, or Ctrl-M for carriage return? Well, inspecting the ASCII chart it becomes evident: the Ctr…

...it's a bit of a shame that the same upper/lowercase trick doesn't apply to all UNICODE codepoints (at least those that have upper/lower variants). It seems to work for codepoints up to U+00FF, for instance: - Å (U+00C5) vs å (U+00E5) ...but above 0xFF lowercase follows uppercase: - Ă (U+0102) vs ă (U+0103) Typical for UNICODE though, nothing makes sense ;)

In Unicode, there's no universal 1:1 mapping between cases.

Lowercase "I" could very well be "ı" (lowercase dotless i) if you're typing Turkish.

Re: The Elegance of the ASCII Table

#188
post #172
post #55

Earlier quoted context omitted.

> For everyone else, UTF is a blessing. Except people who want to use Japanese and not have it render weirdly, something that was easy in any internationalised software that used the traditional codepage system, but is practically impossible in Unicode-based software.

How is it impossible if you Unicode has language tags?

It's impossible because Unicode-based programs don't bother implementing support for language tags, much less testing that support.

Re: The Elegance of the ASCII Table

#189

One downside of ASCII is the lack of two extra “letters” (whatever they might be, e.g. perhaps German ß), as it makes it impossible to represent base 64 alphanumerically. So we ended up with many alternatives picking two arbitrary punctuation marks.

Remember that ASCII is short for "American Standard Code for Information Interchange".

base64 was proposed in 1987 to work with ASCII, EBCDIC, and other character encodings.

Post reply on HN