Support Unicode file paths in the Windows CLI

[gregbenz]

Summary

• Read the native UTF-16 Windows command line and convert it to UTF-8 for the existing argument parser.
• Open every CLI input and output through std::filesystem::u8path() on Windows.
• Add a Windows regression test that encodes and probes files in a CJK and emoji path.

Why

The Windows narrow argv and file-stream paths use the active system code page. Valid filenames outside that code page can be replaced with ?, causing the CLI to reject files that exist or fail to create the requested output.

This change preserves the original Unicode path while leaving the existing CLI parser and command-line interface unchanged.

Scope

This affects only filesystem access in the Windows sample CLI. The library API and ABI are unchanged, and non-Windows behavior is unchanged. Windows reserved filenames, long-path policy, and legacy-console rendering are outside this PR's scope.

Addresses the filesystem-access failure reported in #379.

Validation

Tested natively on Windows x64 with Visual Studio 2022 17.14.2, MSVC 19.44, and CMake 3.31.6:

• Before the fix, a CJK/emoji path was converted to ? and encoding failed.
• After the fix, the dedicated Unicode-path CTest passed.
• Full CTest passed: 2/2.
• Unit suite: 1,065 passed, 224 expected skips, 0 failed.
• Additional encode/probe cases passed for spaces, accented Latin, CJK, non-BMP emoji, and Windows-valid punctuation.
• Unicode JPEG input, decoded output, and metadata filenames were preserved exactly.

HEIF/x265 were disabled because they are unrelated to CLI filesystem handling.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[kmilos]

As already Windows 10 is EOL, it might not be worth carrying this wide vs narrow legacy cruft around. A more elegant/modern solution is to use ultrahdr apps (and other clients of the library) in the native UTF-8 code page.

See e.g. AOMediaCodec/libavif@3ec01ce

[gregbenz]

Thanks for the suggestion—the UTF-8 manifest is a cleaner approach for modern Windows, and the libavif precedent is helpful.

There is one compatibility tradeoff:

• The current PR explicitly converts the native UTF-16 command line and therefore supports Unicode paths across older Windows versions, including Windows 10 LTSC 2019 and Windows Server 2019.
• The manifest approach requires Windows 10 version 1903 or newer. It substantially reduces the application code, but Unicode paths would remain unsupported on older builds. LTSC 2019 and Server 2019 are based on version 1809 and remain supported until 2029.

Microsoft documents the version requirement here:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

@DichenZhang1 Would the maintainers prefer the simpler manifest approach and effectively require Windows 10 1903+, or retain the explicit conversion for broader Windows compatibility? I’m happy to revise the PR either way and will keep the existing Windows Unicode regression test to verify the chosen implementation.

[kmilos]

• LTSC 2019 and Server 2019 are based on version 1809 and remain supported until 2029.

Only on mission critical equipment like medical devices etc. I don't think they'd be deploying new (read "not yet withstood the test of time") features and libraries like libultrahdr on those.

[gregbenz]

@kmilos Thank you, helpful context. I like your proposal and agree it seems simpler and a good approach. I would like to hear if the maintainers have a preference, I'm happy to revise the approach but just want to confirm direction.