Thank you, Javen. As happens too often, I had senders-regret on this email. I found a triggering file in our regression corpus and opened 61045.
No multibytes found; more details in issue. Thank you! -----Original Message----- From: Javen O'Neal [mailto:javenon...@gmail.com] Sent: Wednesday, April 26, 2017 11:59 PM To: POI Developers List <dev@poi.apache.org> Subject: Re: xls record length exception Are there any multibyte Unicode characters in the record? Any chance you could open the file in a hex editor or modify the biff record reader to dump the bytes of just that record? If the record contents are sensitive, you could redact all single-byte codepoints with 0x41 ("A"). Of course at that point you've probably found the problem... On Apr 26, 2017 11:45, "Allison, Timothy B." <talli...@mitre.org> wrote: All, I can't share the file, but... (sorry, it hurts me too). File opens without problem in Excel. If anyone has any recommendations, I'd appreciate it. Caused by: org.apache.poi.hssf.record.RecordFormatException: Expected to find a ContinueRecord in order to read remaining 1 of 51 chars at org.apache.poi.hssf.record.RecordInputStream. readStringCommon(RecordInputStream.java:420) at org.apache.poi.hssf.record.RecordInputStream. readCompressedUnicode(RecordInputStream.java:379) at org.apache.poi.hssf.record.FormatRecord.<init>( FormatRecord.java:57) It looks like the record length is correct, but that the XLUnicode string requires one more character than is stored in the record. In a format record, I'm seeing: 1E 04 37 00 -- format record which should contain 0x37 bytes 2a 00 - index code and Unicode or not 33 00 00 ... --- the XLUnicode String that should be 51 characters long However, only 50 characters follow...and they match where the overall record length should end Another format record follows immediately: 1E 04 2E 00...
