`zipfile` append corrupts a file due to auto filename sanitization

Bug report

Bug description:

When a ZIP archive is opened and rewritten in append mode, a member having a non-standard filename will be corrupted because its filename rewritten to the central directory is auto-sanitized and thus inconsistent with the immutable local file entry when loaded in the future.

This can easily happen if a member containing \ is added in POSIX and the archive is then appended in Windows.

For example:

import io
import zipfile
from unittest import mock

TESTFN = io.BytesIO()

# A file written in POSIX allows '\\'
with mock.patch('os.sep', '/'), mock.patch('os.altsep', None), \
     zipfile.ZipFile(TESTFN, mode="w") as zipfp:
    zi = zipfile.ZipInfo('MyFolder/My\\File.txt')
    zipfp.writestr(zi, 'foo')

# A file written in Windows has '\\' replaced with '/'
with mock.patch('os.sep', '\\'), mock.patch('os.altsep', '/'), \
     zipfile.ZipFile(TESTFN, "a") as zipfp:
    # trigger archive rewriting
    zipfp.comment = b''

with zipfile.ZipFile(TESTFN, "r") as zipfp:
    zi = zipfp.infolist()[0]
    print('content:', zipfp.read(zi))

The above code raises an error: zipfile.BadZipFile: File name in directory 'MyFolder/My/File.txt' and header b'MyFolder/My\\File.txt' differ.

CPython versions tested on:

3.16, 3.14

Operating systems tested on:

No response

Linked PRs

• gh-153626

Commencez par exécuter le reproducer de l’issue et inspecter les chemins de réécriture d’archives en mode append et de sanitisation des noms de fichiers de zipfile de Python. Le travail est terminé lorsqu’une archive créée avec un membre dont le nom contient une barre oblique inverse peut être complétée puis lue sans incohérence entre le nom de fichier du répertoire et celui de l’en-tête ; l’issue renvoie au PR gh-153626, examinez donc d’abord ce travail.