I think what may have happened here is the same thing that seems to have happened in a number of places around the site: at some point, a bunch of files written in UTF-8 were interpreted bytewise as what I assume is Latin-1. That also explains a number of other strange things that turn up (Ben notes that several pages have e.g. ⟨²⟩ where ⟨²⟩ is expected, and some old comments (e.g.) refer to Jörg as ⟨Jörg⟩).
I note that that transformation (and, indeed the reverse) would leave ASCII characters intact, as the backup version has (hence intact links ⁊c.) but this attempt to fix it has not (hence the broken URLs spilt around and partial names (⟨盓ric van Reem⟩) ⁊c.)
EDIT: Playing about with it, it looks like it is indeed one of the 8‐bit encodings, though the ⟨€⟩ sign suggests it's not Latin-1 but one of the others. The character between “Shuffle Chess” and “Prechess” would seem to suggest it's one where ⟨€⟩ is 0x80, as that gives a ⟨、⟩, which would make sense there (it's a punctuation used to separate items in a list) — of those, Codepage 1252 (Microsoft Windows Western European) was once quite popular iirc, so it seems a likely candidate.
EDIT 2: The backup page contains the characters Z–caron ⟨Ž⟩, S–caron ⟨Š⟩, and the O–E ligature ⟨Œ⟩; of the charsets on the linked page, codepage 1252 is the only one to contain all three of those characters, so my money is on that being the right one. As such, presumably the procedure would be to save it encoded in codepage 1252 and then open it as a UTF-8 file.
EDIT 3: A quick try at doing this with Libreoffice tells me I'm right — my Chinese isn't very good but it's enough to see that it looks plausible — the notes section for example begins with a section on how to play it on one's computer (matching the Zillions file link). Unfortunately Libreoffice still leaves a couple of things garbled: it refuses to accept bytes like 0x81 (which is unassigned in codepage 1252), rather than pass them through, which in turn leaves any character encoded using it (including the aforementioned list comma ⟨、⟩) unrecovered. A correct recovery would thus need to use software which is a bit more liberal in what it accepts/emits.
I think what may have happened here is the same thing that seems to have happened in a number of places around the site: at some point, a bunch of files written in UTF-8 were interpreted bytewise as what I assume is Latin-1. That also explains a number of other strange things that turn up (Ben notes that several pages have e.g. ⟨²⟩ where ⟨²⟩ is expected, and some old comments (e.g.) refer to Jörg as ⟨Jörg⟩).
I note that that transformation (and, indeed the reverse) would leave ASCII characters intact, as the backup version has (hence intact links ⁊c.) but this attempt to fix it has not (hence the broken URLs spilt around and partial names (⟨盓ric van Reem⟩) ⁊c.)
EDIT: Playing about with it, it looks like it is indeed one of the 8‐bit encodings, though the ⟨€⟩ sign suggests it's not Latin-1 but one of the others. The character between “Shuffle Chess” and “Prechess” would seem to suggest it's one where ⟨€⟩ is 0x80, as that gives a ⟨、⟩, which would make sense there (it's a punctuation used to separate items in a list) — of those, Codepage 1252 (Microsoft Windows Western European) was once quite popular iirc, so it seems a likely candidate.
EDIT 2: The backup page contains the characters Z–caron ⟨Ž⟩, S–caron ⟨Š⟩, and the O–E ligature ⟨Œ⟩; of the charsets on the linked page, codepage 1252 is the only one to contain all three of those characters, so my money is on that being the right one. As such, presumably the procedure would be to save it encoded in codepage 1252 and then open it as a UTF-8 file.
EDIT 3: A quick try at doing this with Libreoffice tells me I'm right — my Chinese isn't very good but it's enough to see that it looks plausible — the notes section for example begins with a section on how to play it on one's computer (matching the Zillions file link). Unfortunately Libreoffice still leaves a couple of things garbled: it refuses to accept bytes like 0x81 (which is unassigned in codepage 1252), rather than pass them through, which in turn leaves any character encoded using it (including the aforementioned list comma ⟨、⟩) unrecovered. A correct recovery would thus need to use software which is a bit more liberal in what it accepts/emits.