6 ms·

The purpose is more obvious if you understand what makes \r and \n different, and why both existed. But I guess that's becoming lost knowledge now. Ultimately,

The purpose is more obvious if you understand what makes \r and \n different, and why both existed. But I guess that's becoming lost knowledge now. Ultimately, many "character sets" combined printable characters, cursor/head control, and record boundaries into one serialized byte stream that could be used by terminals, printers, programs for all sorts of purposes.

pavlov 2y ago
It’s a shame that ASCII unit/record/group boundary characters were practically never used, at least since microcomputers took over. Instead we’re stuck with broken replacements like CSV.
- yjftsjthsd-h 2y ago
  Right? And they're a really obvious solution to a problem that we somehow still have even though they've been around forever. The only problem I've ever seen is that there's no good way to type or display them
  - deleted 2y ago
    [deleted]
  - jandrese 2y ago
    It is a bit of a chicken and egg problem here. If those characters were used then at least for CSV support better text editors would find a way to handle them. Since they aren't nobody wants to try to use them in a CSV like file.
  - otabdeveloper4 2y ago
    If there was a good way to type of display them, then normal people would be typing them every day (say, pasting them into comment forms or whatever), and then we would need to have some standard for quoting them.
- qsort 2y ago
  ASCII separators are equally as broken. How do you represent a string containing the record separator in a record-separated file? Any such solution will always be broken, proof is left as an exercise for the reader. Hint: use Ogden's lemma.
  - Dylan16807 2y ago
    They are exactly the same... Expect for the massive use case of storing human text, which contains tons of commas and zero ASCII separators. So if you decide not to support "strings", just "text", then those separators Just Work.
    - qsort 2y ago
      In that alternate universe nobody would have put them into some varchar column? The edge case still exists, which means that the standard would need to support it somehow, and we're back to exactly square one.
      - Dylan16807 2y ago
        The standard does not have to support nesting. But if I was writing a similar standard today and someone was pressuring me that I really had to make some kind of mechanism for nesting, I'd use something that transforms the field to remove the need for escaping, in a big and obvious way. Probably base64. That prevents most of the implementation issues you see with CSV.
        qsort 2y ago
        Neither does a trivial variation of CSV where quotes are not special and commas must be escaped in whatever way. The separator is completely immaterial, the resulting format is identical.
        Dylan16807 2y ago
        People screw up escaping. Don't escape. CSV needs escaping, so don't do CSV.
- indymike 2y ago
  This is not actually the case. The problem was you were transporting CSV often using a mechanism that used control characters at the hardware level. Using those characters often would have unpredictable results when storing, retrieving, and transmitting data.
- Eiim 2y ago
  Interestingly, if you ever scan a FedEx barcode, they use tons of ASCII separator characters. About the only time I've seen them significantly used though.
- hhh 2y ago
  They are used, but they tend to be in places that nobody sees or thinks about. A few auto manufacturers use them in their serialized part codes.
- paulryanrogers 2y ago
  Really old point of sale protocols sometimes still used them. That's how I learned field separator.
Dylan16807 2y ago
What percentage of hardware terminals could actually handle arbitrary character overlapping?
- akira2501 2y ago
  The better question is what percentage of _printers_ could handle arbitrary overlap, and I think the answer is, all of them. It's just a head striking paper, backspace and strike twice is always an option. Printers were fare more common than hardware terminals for most of the initial history of computing.
- dfox 2y ago
  I vaguely remember that vt220 actually special caces this kind of overprinting. And today everybody targets some kind of vt220/xterm hybrid…
  - Dylan16807 2y ago
    In a way that lets you get accents on the characters that have built-in accented versions, or in a way that lets you put it on anything?
    - dfox 2y ago
      The hardware is not capable of conjuring up new characters, so this is limited to detecting things like bold and underline… and maybe mapping the overprinting to characters that already exist in the font.
  - deleted 2y ago
    [deleted]

pavlov 2y ago

It’s a shame that ASCII unit/record/group boundary characters were practically never used, at least since microcomputers took over. Instead we’re stuck with broken replacements like CSV.

yjftsjthsd-h 2y ago
Right? And they're a really obvious solution to a problem that we somehow still have even though they've been around forever. The only problem I've ever seen is that there's no good way to type or display them
- deleted 2y ago
  [deleted]
- jandrese 2y ago
  It is a bit of a chicken and egg problem here. If those characters were used then at least for CSV support better text editors would find a way to handle them. Since they aren't nobody wants to try to use them in a CSV like file.
- otabdeveloper4 2y ago
  If there was a good way to type of display them, then normal people would be typing them every day (say, pasting them into comment forms or whatever), and then we would need to have some standard for quoting them.
qsort 2y ago
ASCII separators are equally as broken. How do you represent a string containing the record separator in a record-separated file? Any such solution will always be broken, proof is left as an exercise for the reader. Hint: use Ogden's lemma.
- Dylan16807 2y ago
  They are exactly the same... Expect for the massive use case of storing human text, which contains tons of commas and zero ASCII separators. So if you decide not to support "strings", just "text", then those separators Just Work.
  - qsort 2y ago
    In that alternate universe nobody would have put them into some varchar column? The edge case still exists, which means that the standard would need to support it somehow, and we're back to exactly square one.
    - Dylan16807 2y ago
      The standard does not have to support nesting. But if I was writing a similar standard today and someone was pressuring me that I really had to make some kind of mechanism for nesting, I'd use something that transforms the field to remove the need for escaping, in a big and obvious way. Probably base64. That prevents most of the implementation issues you see with CSV.
      - qsort 2y ago
        Neither does a trivial variation of CSV where quotes are not special and commas must be escaped in whatever way. The separator is completely immaterial, the resulting format is identical.
        Dylan16807 2y ago
        People screw up escaping. Don't escape. CSV needs escaping, so don't do CSV.
indymike 2y ago
This is not actually the case. The problem was you were transporting CSV often using a mechanism that used control characters at the hardware level. Using those characters often would have unpredictable results when storing, retrieving, and transmitting data.
Eiim 2y ago
Interestingly, if you ever scan a FedEx barcode, they use tons of ASCII separator characters. About the only time I've seen them significantly used though.
hhh 2y ago
They are used, but they tend to be in places that nobody sees or thinks about. A few auto manufacturers use them in their serialized part codes.
paulryanrogers 2y ago
Really old point of sale protocols sometimes still used them. That's how I learned field separator.

Dylan16807 2y ago

What percentage of hardware terminals could actually handle arbitrary character overlapping?

akira2501 2y ago
The better question is what percentage of _printers_ could handle arbitrary overlap, and I think the answer is, all of them. It's just a head striking paper, backspace and strike twice is always an option. Printers were fare more common than hardware terminals for most of the initial history of computing.
dfox 2y ago
I vaguely remember that vt220 actually special caces this kind of overprinting. And today everybody targets some kind of vt220/xterm hybrid…
- Dylan16807 2y ago
  In a way that lets you get accents on the characters that have built-in accented versions, or in a way that lets you put it on anything?
  - dfox 2y ago
    The hardware is not capable of conjuring up new characters, so this is limited to detecting things like bold and underline… and maybe mapping the overprinting to characters that already exist in the font.
- deleted 2y ago
  [deleted]