https://bugs.documentfoundation.org/show_bug.cgi?id=169591
Julien Nabet <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] |desktop.org | Status|NEW |ASSIGNED OS|Windows (All) |All --- Comment #8 from Julien Nabet <[email protected]> --- On pc Debian x86-64 with master sources updated today, I could reproduce this. UTF-16BE (so UTF-16 Big Endian) is well detected and used for the preview but the problem is only the encoding RTL_TEXTENCODING_UCS2 is remembered to display data in Calc. UCS2 means unicode with 2 bytes so UTF-16 but we don't know the endianess. Since the endianess by default is most of the time SvStreamEndian::LITTLE, it triggers wrong display then. For the display, LO detects RTL_TEXTENCODING_UCS2 again then try to find BOM but doesn't find it with the first file so use SvStreamEndian::LITTLE. With the second file, LO finds the BOM and so use the correct endianess (here SvStreamEndian::BIG). That explains why the file without BOM doesn't work and the one with BOM works. I've submitted this patch https://gerrit.libreoffice.org/c/core/+/208981 The idea is to call a second time DetectEncoding function (which uses lib icu) in case of RTL_TEXTENCODING_UCS2. An alternative would be to store the endianess in ScFilterOptionsObj::aFilterOptions after the first call to DetectEncoding for the preview but I'm not sure it worths it. -- You are receiving this mail because: You are the assignee for the bug.
