[ 
https://issues.apache.org/jira/browse/TIKA-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152041#comment-13152041
 ] 

Michael McCandless commented on TIKA-782:
-----------------------------------------

These changes look great!

Cutover to PushbackInputStream, and then using this to lookahead to
find '*' after '{' to know we should ignore the group state, is
great; much simpler than before.

I like the new broken out methods for parsing control token/word, hex
char.

Since addOutputByte now takes int instead of byte, could you add an
assert that the int is "in bounds" for byte?

It makes me nervous creating a new StringBuilder and String for every
control word; can we go back to our own reused char[] buffer/ equals
method?

Instead of allocating a full byte[] for the "bin" control word, can we
say allocate (up to) a fixed buffer size and read in chunks until
we've skipped that many bytes?  This way if an RTF doc has massive
embedded binary data we don't use lots of RAM when skipping it.

                
> Add support for parsing binary data in RTF files
> ------------------------------------------------
>
>                 Key: TIKA-782
>                 URL: https://issues.apache.org/jira/browse/TIKA-782
>             Project: Tika
>          Issue Type: Improvement
>          Components: parser
>    Affects Versions: 1.0
>            Reporter: Arjohn Kampman
>            Assignee: Michael McCandless
>         Attachments: bin.patch, bin2.patch
>
>
> The current RTF parser doesn't process \bin control words yet. These control 
> words are followed by a specific amount of binary data. Because of this, the 
> RTF parser trips over some of these bytes in a number of (classified) 
> documents.
> I've implemented processing of the \bin control word, but it required of the 
> core parsing algorithm. IMHO, it also improved readability of the code. I 
> hope you will accept this patch. Please let me know if the patch requires 
> modifications.
> Apart from the \bin code word, this patch also makes the parser stop after 
> reading the document-closing '}' character. In a number of files (again, 
> classified), the parser would include non-readable characters that appeared 
> after this closing brace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to