refactor: Remove ZipFileData fields

[Its-Just-Nans]

I don't really know the is_ascii check

ea30849#diff-ed12f5ea605f23bb4d26cc65778e3daff9db3eec40e2abfc82beafca130a99a0

[amazon-q-developer]

The PR removes three redundant fields (encrypted, is_utf8, using_data_descriptor) from ZipFileData and replaces them with computed methods. The changes appear functionally correct with no logic errors or security issues. However, the PR title "Remove zipfiledata fields" does not conform to the Conventional Commits format required by the repository guidelines. The title should start with a type prefix like refactor:, fix:, feat:, etc. Consider updating it to something like: refactor: remove redundant fields from ZipFileData

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.

[gemini-code-assist]

Code Review

This pull request bumps the crate version to 9.0.0 and refactors the ZipFileData struct by removing the redundant encrypted, is_utf8, and using_data_descriptor boolean fields, instead deriving these states directly from the flags bitfield. Helper methods were introduced to maintain the API, and all call sites have been updated accordingly. Review feedback identified a logic error in the flags() method that causes data loss by discarding existing bits in the flags field, as well as a redundant UTF-8 check during file initialization.

[gemini-code-assist]

The check std::str::from_utf8(&file_name_raw).is_ok() is redundant here. file_name_raw is created directly from file_name.as_bytes() on line 428, and since file_name is a Box, it is guaranteed to be valid UTF-8.

Suggested change

	if std::str::from_utf8(&file_name_raw).is_ok() && !file_name.is_ascii() {
	flags |= ZipFlags::LanguageEncoding.as_u16();
	}
	if !file_name.is_ascii() {
	flags |= ZipFlags::LanguageEncoding.as_u16();
	}

[Its-Just-Nans]

@Pr0methean

Yes but later the file_name could be not UTF-8

[Pr0methean]

Mostly looks good, but please address the remaining Gemini suggestion.

[Its-Just-Nans]

Mostly looks good, but please address the remaining Gemini suggestion.

I don't think gemini i really correct here

1. it was always like that so far, and this MR is not about fixing an issue but just refactoring
2. Gemini is technically rights but we don't really use the "compression settings" bits

        (For Method 6 - Imploding)
        Bit 1: If the compression method used was type 6,
               Imploding, then this bit, if set, indicates
               an 8K sliding dictionary was used.  If clear,
               then a 4K sliding dictionary was used.

        Bit 2: If the compression method used was type 6,
               Imploding, then this bit, if set, indicates
               3 Shannon-Fano trees were used to encode the
               sliding dictionary output.  If clear, then 2
               Shannon-Fano trees were used.

        (For Methods 8 and 9 - Deflating)
        Bit 2  Bit 1
          0      0    Normal (-en) compression option was used.
          0      1    Maximum (-exx/-ex) compression option was used.
          1      0    Fast (-ef) compression option was used.
          1      1    Super Fast (-es) compression option was used.

        (For Method 14 - LZMA)
        Bit 1: If the compression method used was type 14,
               LZMA, then this bit, if set, indicates
               an end-of-stream (EOS) marker is used to
               mark the end of the compressed data stream.
               If clear, then an EOS marker is not present
               and the compressed data size must be known
               to extract.

        Note:  Bits 1 and 2 are undefined if the compression
               method is any other.

Imploding -> we cannot compress with imploding with the current crate (decompress only)
Deflating -> technically yes we should set these bytes
LZMA -> we cannot compress with LZMA with the current crate (decompress only)