Prefer application/x-ole-storage instead of application/x-tika-msoffice #54
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #44
Prefer
application/x-ole-storage
as a fallback for ms-office documents. This was the behaviour of Marcel 0.33.However, I'm resorting to this because I can't find a good magic matcher to identify
*.olf
files. The header of the binary file is already used to identify it is an OLE/office type file, and there doesn't appear to be (AFAICS) any bytes we can read at a consistent offset to denoteapplication/vnd.ms-outlook
.The more specific matching matchers for office subtypes appear to be very subtle though. For example, the one we use for
application/msword
:marcel/data/custom.xml
Lines 13 to 17 in 85c2559
Regardless, I think we can agree that
x-tika-msoffice
was supposed to be an internal type grouping that shouldn't be surfaced in mime type detection.