There is no absolute guarantee for that.
From your examples, your files incurred a major change: the advent of Unicode.
Previously, text (here I talk only about text, not about document structure representation) was encoded in 8-bit characters allowing for a total of 94 (or 95 if you include space) printable ASCII characters plus either 127 or 95 extension characters, which is not enough to cover all Latin languages (and even less languages not based on Latin alphabet). The extended characters were not standardised prior to ISO-8859-x and every vendor had his own solution (also with the intent of locking in the customer). For instance, IBM invented the notion of code page to match with a specific language.
Unicode offers now a universal solution which I hope will be valid for several decades (which is eternity when dealing with computer). Its repertoire contains potentially millions of glyphs.
Rule #1: convert your existing documents to Unicode
The second aspect is the representation of formatting. Unfortunately, you can’t freeze application improvement. There will always be an excellent reason to add a new formatting feature. As long as this new feature does not use an encoding previously used for something else, adding to a format standard should not prevent interpreting correctly an older file.
But, computers had not always the disk storage of contemporary devices. Do you remember the ~100kB disquettes? This meant the document has to be compressed as much as possible using a binary encoding. This is were the danger lies because this encoding is “implicit”: there is no description metadata allowing to interpret the binary stream if you have lost the original application.
Current XML encodings do not use binary streams. They use XML to mark up text. This means there is hope that once the file is inflated (in case it is stored in a zip-style state like .odt or .docx), you can “understand” what is inside, even if you can’t format it again. In other words, you can recover content by wiping out markup.
Rule #2: convert your documents to some XML-based representation
Rule #1 & #2 don’t give you any guarantee to be able to open old documents without loss or reliably.
If you really want an additional safety, backup the application used to create them. But, as these applications won’t be able to be executed in future versions of OS and hardware, keep an OS and a machine in working order, hoping that the network protocols will be compatible enough so that you can transfer from one machine to the other.
IMHO, the best option is to convert your files periodically, following the evolution rate of the document processing applications.
To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!
In case you need clarification, edit your question (not an answer which is reserved for solutions) or comment the relevant answer.
