-
Notifications
You must be signed in to change notification settings - Fork 56
RAT-532: Bump tika.version from 3.3.2 to 4.0.0 and migrate charset detection #714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
f1523bb
af87ca1
922cb2f
5043b79
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -68,6 +68,9 @@ in order to be properly linked in site reports. | |
| </release> | ||
| --> | ||
| <release version="1.0.0-SNAPSHOT" date="xxxx-yy-zz" description="Current SNAPSHOT - release to be done"> | ||
| <action issue="RAT-532" type="add" dev="pottlinger"> | ||
| Update to Tika 4.0.0: new charset detection logic in Tika returns different values compared to 3.x before, such as windows-1252 instead of ISO-8859-1. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is an error. We have some windows-1252 files but most are ISO-8859-1 I think for our purpose we can label windows-1252 as ISO-8859-1. I need to check the list that is returned from the new Tika and see if it includes ISO-8859-1 as one of the encodings. I think we should select ISO over windows when we have the option. This PR needs investigation and work.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Tika4 logics is to return the "best" charset. In contrast to version 3.x this changed into windows-1252. The new implementation returns the first hit. Personally I wouldn't want to introduce new logics on the RAT-side to generalise into ISO-8859-1 and would take the change as tika-induced and document it in our changelog.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Out of curiosity I added some logging locally in TikaProcessor to just list the encodings: It seems that ISO is not recognized anymore with Tika 4.x. |
||
| </action> | ||
| <action issue="RAT-553" type="add" dev="pottlinger" due-to="Guillaume Nodet"> | ||
| Fix NPE with parallel builds in SCM ignore parsers. | ||
| </action> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code does not do the same thing. the debug should be a warning.
And what happend to unsupported character sets?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do not have an explicit test for unsupported character sets. Tika handles this internally and returns no charset. If no charset is returned RAT will mark as UNKNOWN if I'm not too mistaken.
Do you have an example file that triggers this exception?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried adding "random bytes" but Tika still reports a probabilistic value and I'm unable to provide an input that yields an empty result in order to test RAT's behaviour.