Plain text can be a really problematic format for data preservation. - While it's fairly easy to read and write plain text, it's also fairly easy to inadverten

Plain text can be a really problematic format for data preservation. - While it's fairly easy to read and write plain text, it's also fairly easy to inadvertently introduce unintended artifacts in the process. - The more frequently a file gets passed around and read and written to, the more likely mojibake[1] will get introduced. This concern rises exponentially when you move to non-US audiences and introduce local-specific encodings. File storage settings, client operating system settings, server configuration settings, database settings, programming languages that touch it along the way. All of them introduce assumptions along the way of a file's encoding, and many failure cases can be subtle and easily go unnoticed at a glance while causing some irreversible damage to downstream recipients. - Even if you solve for the encoding, you still have structural issues with tabular data. Different parsers treat escaping and quoting policies differently. This can result in data shifts as things get mis-parsed, data corruptions if literal values get interpreted as escape characters or vis versa, etc. For preserving data, generic plain text tends to get worse and worse over time because it's such a non-opinionated format and even if you document the specifics on econdings and parsing details it's easy for those to get lost over time as things exchange hands or for intermediaries to corrupt the plaintext because they relied on defaults instead of the documented parsing details. For better or worse, PDF tends to solve the preservation issue while introducing potential barriers on the parsing/processing side. [1] https://en.wikipedia.org/wiki/Mojibake https://en.wikipedia.org/wiki/Mojibake