Fix #75557: Error opening archive w/non-english chars in path #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.
While there is already some support for Unicode file paths, apparently
the archive name itself may only be given as ANSI. To support Unicode,
the
ArcNameW
of theRAROpenArchiveDataEx
struct needs to be set(instead of the
ArcName
member).This is overall an insufficient solution, so must not be merged as is. I'm merely dropping this here, to see where it might go. I noticed that there are already functions to convert between
char[]
andwchar_t[]
in rar.c, but these won't take into account the improved code page support wrt. to Unicode paths on Windows. So I've added Windows and PHP version specific code using the new APIs; the attached test case succeeds, but several others are failing (segfault), due toArcName
being accessed instead ofArcNameW
. This would need to be solved as well. I'm not sure, though, whether the Windows specific APIs or the general SAPIs should be used, and whether some kind of abstraction layer would be reasonable.Thoughts?