Kind of related question: why are no whitespaces allowed in many passwords while special characters are? I’m a huge fan of elaborate nonsense sentence passphrases but get shot down.
(I ask cause that regex has that requirement it seems)
I have no idea if this is true or not but I was told it harkens back to very early multi-user operating systems where user credentials were stored unencrypted in plaintext files that used white space as delimiters.
I tend to believe this might be accurate because I learned programming back in the 1980’s on an Onyx Systems microcomputer. There was a bug that some of us learned about in its rudimentary email program that would dump you into its otherwise-protected system directory. In that directory was a file containing both usernames & passwords in clear text. I don’t recall if it used white space as a delimiter, but given everything was in clear text and not encrypted I think that might have been the case.
Oh boy, having done data science work with government files, you remind me that they still use terrible delimiters. A white space delimiter sounds significantly worse than a tab delimited file, though!
Tabs are also usually not allowed in many fields. The thing is, tab delimiters are fine, but the data sets often get stored without file extensions. Let me tell ya, I was the only person on staff to even know what a file extension was, let alone how to load it into software that can process tab delimiters!
Tabs are considered white space. A white space is technically any character that is not visible. That covers things like spaces, vertical/horizontal tabs, non-breaking spaces, zero-length spaces, etc.
I learned COBOL programming on that system. COBOL’s sequential file data type was all about space-delimited text files. Part of a program would define the various input & output files. For example a numerical userid might take up columns 1-8 then the first initial would be in column 10 then the last name in columns 12-20 and so on…
Kind of related question: why are no whitespaces allowed in many passwords while special characters are? I’m a huge fan of elaborate nonsense sentence passphrases but get shot down.
(I ask cause that regex has that requirement it seems)
I have no idea if this is true or not but I was told it harkens back to very early multi-user operating systems where user credentials were stored unencrypted in plaintext files that used white space as delimiters.
I tend to believe this might be accurate because I learned programming back in the 1980’s on an Onyx Systems microcomputer. There was a bug that some of us learned about in its rudimentary email program that would dump you into its otherwise-protected system directory. In that directory was a file containing both usernames & passwords in clear text. I don’t recall if it used white space as a delimiter, but given everything was in clear text and not encrypted I think that might have been the case.
Oh boy, having done data science work with government files, you remind me that they still use terrible delimiters. A white space delimiter sounds significantly worse than a tab delimited file, though!
I never use tab delimiters but thinking about it, it is much less common to encounter a tab character in a CSV field than a comma…
Tabs are also usually not allowed in many fields. The thing is, tab delimiters are fine, but the data sets often get stored without file extensions. Let me tell ya, I was the only person on staff to even know what a file extension was, let alone how to load it into software that can process tab delimiters!
Ugh. Bless you
Tabs are considered white space. A white space is technically any character that is not visible. That covers things like spaces, vertical/horizontal tabs, non-breaking spaces, zero-length spaces, etc.
I learned COBOL programming on that system. COBOL’s sequential file data type was all about space-delimited text files. Part of a program would define the various input & output files. For example a numerical userid might take up columns 1-8 then the first initial would be in column 10 then the last name in columns 12-20 and so on…