Another XLSX signature: 50 4b 03 04 14 00 06 08 08 00

[AndrewNowosad]

MicrosoftOffice365Document's MagicBytes list doesn't cover every general-purpose bit flag / compression method combination that real-world zip writers emit for OOXML's first local file header ([Content_Types].xml).

I hit this with a .xlsx produced by a non-Microsoft editor. Its first local file header is:

50 4B 03 04 14 00 06 08 08 00 ...

• Version needed to extract: 0x0014
• General purpose bit flag: 0x0806 (bit 0x0800 = "language encoding flag" / UTF-8 filenames, plus the "super-fast deflate" sub-bits 0x06)
• Compression method: 0x0008 (deflate)

None of the existing MagicSequence entries in MicrosoftOffice365Document.cs match this combination, so FileTypeValidator.GetFileType(...) falls through to the generic ZipFile type instead of recognizing the file as an OOXML document.

Reproduction

using FileTypeChecker;

var header = new byte[] { 0x50, 0x4B, 0x03, 0x04, 0x14, 0x00, 0x06, 0x08, 0x08, 0x00 };
using var stream = new MemoryStream(header.Concat(new byte[54]).ToArray());

var type = FileTypeValidator.GetFileType(stream);
Console.WriteLine(type.Extension); // "zip" -- expected an OOXML-recognized type

Suggested fix

Add new(new byte[] { 0x50, 0x4B, 0x03, 0x04, 0x14, 0x00, 0x06, 0x08, 0x08, 0x00 }) to MicrosoftOffice365Document.MagicBytes, the same way earlier signature variants were added (e.g. #48 / #49).

I'll open a PR with this fix plus a test fixture shortly.