I would say that a text file is one which, when sequentially read, has is a simple transformation from the bytes to a sequence of characters in one or more character repertoires (lists), fully consuming all bytes with none remaining, except any file-termination codes. This transformation may be direct mapping using the values of the bytes, or may involve mapping sequences of bytes to some other number (e.g. UTF-8), or may involve a simple state machine (e.g. ISO 2022), for example, (but surely nothing requiring a stack or random access.) The result and initial objective of parsing the file is a single sequence of characters.
I would say that a binary file, when used in distinction to "text file", is one which uses potentially more complex transformations, where the result and initial objective of parsing the file will be a data structure or event stream.
So a ZIP file containing an uncompressed XML file is not a text file, because there are some bytes that are not intended to map to characters. But a file with a single DNA sequence as a packed string probably counts as a text file.
{You might say that therefore a file containing artificial languages like markup is a text file that is also like a binary file (in that you end up with a data structure or event stream.)}
Text and binary are also names used to represent different modes in some applications: e.g. in FTP a text file may have its newlines replaced with platform specific newlines (a la text/* MIME type) and perhaps even be transcoded, while a binary file will be kept byte-for-byte intact (a la application/* MIME type.) This usage for modes should not cloud the usage relating to files.
So the test of a text file is "can I read it?" but "is it intended to be a sequence of characters from some repertoire with a 'simple' O(n) sequential mapping from the bytes"?
Something like that.
Cheers
Rick