There's no magical solution to this. If the file formats have some version information built into them, you can use that data, feed it into a Factory, and create the appropriate instance of a Strategy for reading. You may also have separate Strategies for processing that data. The degree to which you'll be able to share logic between them will depend the number of useful abstractions you can come up with (based on your knowledge of what the application does), to build your system around them.
The core idea behind the Strategy pattern, and any other pattern that needs to be agnostic of implementation details, is to write code against an abstraction (like an interface), and have some other implementation-specific object support that abstraction.

You'll have to come up with an interface that's general enough, but at the same time useful enough so that your application can still do the work it needs done, because at a higher level, you cannot refer to data fields that might be unique to a specific file format and version (or other format-specific details, like structure, ordering, etc.). Otherwise, you would have to handle each case differently, and that may limit extensibility and maintainability; the idea is to contain this format-specific behavior in a lower level class, or a collection of related classes. So you have to think through what is it that your application does, and if it's possible to express the logic in higher-level terms (i.e. you should be able to just tell the code DoATask() and let some format-specific subclass handle it, instead of ReadDataField(...); DoStuffWithDataField(...);).
Another possible approach (that may be complementary to what I described above) is to come up with some sort of a unified data model that your application will use internally. Your various format-specific data readers would read the data and convert it to this unified format, and the "core" of your application would take that (it would work exclusively with data in that form). This would require writing some boilerplate code (to translate to/from the internal format), and there may or may not be a performance hit. But design is all about trade-offs, so you have to weigh pros and cons yourself.
P.S. If there's no version information available, then you may be able to use your knowledge of the domains to somehow inspect the file and determine (well, guess) the file format, based on something like the structure of the file. But this (1) may not always be possible, and (2) even when it is possible, it can be unreliable and may backfire.