[ravi-arnan]

Fixes: #66975

Problem

In test/parallel/test-zlib-zip-interop.js, zipinfoUnicode is evaluated as /UNICODE_SUPPORT/.test(unzip -v). However, stock Info-ZIP builds (common on Linux distros such as NixOS, Arch Linux, Alpine, and Debian) still sanitize non-ASCII bytes to '?' in fnfilter() unless patched with wide-character/UTF-8 printing support (e.g. USE_NATSPEC or alt-iconv-utf8-print).

On these systems, zipinfo outputs unicode-??.txt (or unicode-??????.txt) instead of unicode-名前.txt, which causes the assertion:

assert.ok(zipinfo.stdout.toString().includes(name), `zipinfo missing ${name}`);

to fail.

Solution

When checking zipinfo output:

• First check if the entry name matches verbatim (as on patched Info-ZIP builds).
• If not and the entry name contains non-ASCII characters, verify that zipinfo listed the entry with '?' placeholders.
• If an entry is missing entirely (or if a plain ASCII entry is missing), fail the assertion.

The actual UTF-8 decoding and round-trip extraction continue to be verified by bsdtar directly afterwards.

Verification

• Ran Node.js ESLint: node tools/eslint/node_modules/eslint/bin/eslint.js test/parallel/test-zlib-zip-interop.js (clean, 0 warnings/errors).
• Verified against real zipinfo execution on Linux (NixOS) where stock Info-ZIP prints unicode-??.txt (clean pass).

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

[vedchaudhari]

Hi @ravi-arnan, thanks for working on this! Two things I noticed:

• It fails on macOS. Since the UNICODE_SUPPORT check is removed, macOS now checks the Japanese name too. But Apple's zipinfo doesn't turn the whole name into ?s, it keeps some of the bytes: 名前 comes out as e5 3f 3f e5 3f 3f. So the \?+ pattern doesn't match and the test fails: https://github.com/vedchaudhari/node/actions/runs/40075440958
• Debian, Arch and Alpine actually print the name fine. The description and the new comments say they show ?, but those distros turn the ? filter off (NO_WORKING_ISPRINT). I checked on Ubuntu and it printed unicode-名前.txt. The ? only shows up on builds that keep the filter on, like Gentoo with USE="unicode -natspec".

I opened #66979 with a version that keeps the UNICODE_SUPPORT check, in case that helps. Happy to go with whichever the reviewers prefer!

[ravi-arnan]

Hi @vedchaudhari, thanks for the review and for catching the macOS behavior!

I reproduced and verified this directly on a physical macOS machine (Darwin 21.6.0, built-in Info-ZIP 6.0). As you noted:

• Apple's Info-ZIP build does not report UNICODE_SUPPORT in unzip -v.
• Its fnfilter() keeps 0xe5 (since isprint(0xe5) is true under the default 8-bit table) but replaces continuation bytes with ?, giving \xe5??\xe5?? (e5 3f 3f e5 3f 3f), which decodes as \uFFFD??\uFFFD?? in UTF-8.

I have updated this PR to:

1. Restore the zipinfoUnicode check so platforms lacking UNICODE_SUPPORT (such as stock macOS) continue to skip the zipinfo non-ASCII assertion, preserving baseline behavior.
2. For systems with UNICODE_SUPPORT where fnfilter() still sanitizes non-ASCII bytes without wide-character printing (e.g. NixOS or Gentoo without natspec), normalize runs of ? and \uFFFD to match the non-ASCII placeholder.

Linter and test assertions are verified clean.