System.IO.Packaging: Avoid setting the general purpose bitflag due to enforced UTF8 encoding on ZipArchive creation

[carlossanlop]

Fixes #87658

The ZipArchive constructor is being called by ZipPackage with the entryNameEncoding argument set to Encoding.UTF8. This is not needed by default, particularly because it's not respecting the Office XML standard which does not expect the general purpose bit flag 11 to be set. The entry name can still be stored using UTF8 if the archive encoding is unset or null, and the general purpose bit flag for entryname and comment encoding can still be changed later if the caller changes the entry name or the comment to a string with an encoding other than ASCII.

This change is relatively safe to make since ZipArchive is capable of handling archives without specifying a particular encoding.

This was verified with a manual test with @ericstj in a video call: we confirmed with reflection that the _generalPurposeBitFlag was now left unchanged by default, and an inspection of the generated file using a hex editor showed that the relevant bytes were unset.

We will add tests as a followup of the original issue. #87882

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #87658

The ZipArchive constructor is being called by ZipPackage with the entryNameEncoding argument set to Encoding.UTF8. This is not needed by default, particularly because it's not respecting the Office XML standard which does not expect the general purpose bit flag 11 to be set. The entry name can still be stored using UTF8 if the archive encoding is unset or null, and the general purpose bit flag for entryname and comment encoding can still be changed later if the caller changes the entry name or the comment to a string with an encoding other than ASCII.

This change is relatively safe to make since ZipArchive is capable of handling archives without specifying a particular encoding.

This was verified with a manual test with @ericstj in a video call: we confirmed with reflection that the _generalPurposeBitFlag was now left unchanged by default, and an inspection of the generated file using a hex editor showed that the relevant bytes were unset.

We will add tests as a followup of the original issue.

Author:	carlossanlop
Assignees:	carlossanlop
Labels:	area-System.IO.Compression
Milestone:	-

[ericstj]

LGTM based on manual testing. Approving this minimal change in order to get it out in P6 so that we can find out if it helps solve the issue.

[tomjebo]

Thanks @carlossanlop and @ericstj!