Fix non-ASCII path handling

[benrg]

The game RiME (version 1.04, from GOG) has a negative path length in its .pak index. Looking at the raw data, it's clear that this flags a UTF-16 encoded path.

The pak version is 3, and the single non-ASCII character is U+00B4 (which I'm mentioning since it's in Latin-1).

I submitted a pull request (#50) that fixes the path decoding for this game. It should be safe to apply since it only changes the handling of negative path lengths when reading. Most likely when writing, any non-ASCII path should be encoded as UTF-16, but I don't know whether that applies to every game and pak version. Are there any known examples of non-ASCII paths other than this one?

[panzi]

Thank you!

[panzi]

Would you willing to try if this works for that game, too? https://github.com/panzi/rust-u4pak/releases/tag/v1.3.0
It's a re-implementation of u4pak in Rust that should be faster and comes as a single binary (no need to install Python).

[benrg]

Listing works with the Rust version (and I checked that the correct filename appears in the output).

u4pak check produces a lot of errors, but I think it's an unrelated issue (panzi/rust-u4pak#4).