Fix Unicode paths on Windows (& accept more paths on Unix) #16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
I have run into #11 on my Windows machine. I believe this is because passing UTF-8 to the system file APIs simply does not actually work for Windows, and so calling
taglib_file_newandtaglib_file_new_typefails as well.Instead, this pull request makes it so on Windows, the Paths are encoded in UTF-16/WTF-16, and passed through
taglib_file_new_wcharandtaglib_file_new_type_wchar(two bindings that only exist on Windows).I also tweaked the Unix code for
taglib_file_newandtaglib_file_new_typeto avoid the intermediate conversion to UTF-8, as other paths than pure UTF-8 should be valid on Unix platforms as well.Finally, I change the API for
File::new_typeto take aP: AsRef<Path>argument for itsfilename, rather than just an&str(to make the code more consistent). This should probably be considered a breaking change; perhaps I should have bumped the semver.Depending on if/when this is able to be merged, if anyone else just needs a quick fix for Unicode on Windows, you can patch in my fork: