Files with ASCII filename and UTF-8 comment lost EFS flag when writing with `zipfile`

[danny0838]

Bug report

Bug description:

According to the spec, the EFS flag enforces the filename and comment of a file entry to be UTF-8.

However, the EFS flag is not set when a file with ASCII filename and UTF-8 comment is written through zipfile. This renders its comment at risk of mis-decoding.

Similarly, a file with ASCII filename loses its EFS flag when the central directory is rewritten in append mode. This causes an unexpected metadata mutation and introduces a structural inconsistency between the immutable Local File Header (LFH) and the rewritten Central Directory Entry (CDE). This is also a regression of gh-84353/gh-150091, before which the EFS flag was not altered.

Additionally, the metadata_encoding parameter cannot be specified when an archive is opened with 'a' mode, disallowing a proper decoding with a customized codec.

CPython versions tested on:

3.14, 3.16

Operating systems tested on:

No response

Linked PRs

• gh-152845: Keep EFS flag for a file loaded from the archive #152846

[danny0838]

PR 152845 should fix most of this issue.

A closely related sub-issue occurs in append mode: for a pre-existing entry with an ASCII-only filename and comment, its comment cannot be updated to UTF-8 safely in the future, since it will likely be decoded with cp437 or another local encoding.

I think we should consider a more robust encoding promotion logic. One straightforward approach is to enforce the EFS flag for all newly added entries.

The side effects should be minimal, as enabling the EFS flag (Bit 11) does not introduce any additional data payload, and the required "Version needed to extract" is identically at least 20 (2.0).