https://bugs.documentfoundation.org/show_bug.cgi?id=36313
--- Comment #26 from Stephan Bergmann <sberg...@redhat.com> ---
(In reply to Stephan Bergmann from comment #17)
> With the fix from comment 16, what works for me to resolve the problem from
> comment 0 is to run
>
> soffice --headless --convert-to ods --infilter=CSV:44,34,UTF8 mytest.csv
>
> where "44" denotes the field separator character (,) and "34" denotes the
> quote character ("). The problem is that you cannot leave these obscure
> values out (e.g., --infilter=CSV:,,UTF8) and the "documentation" for the CSV
> filter's FilterOptions string format is ScAsciiOptions::ReadFromString
> (sc/source/ui/dbgui/asciiopt.cxx).
It is no longer clear to me why I assumed that "UTF8" would cause the CSV
filter to interpret the input as UTF-8. Rather, according to
ScAsciiOptions::ReadFromString (sc/source/ui/dbgui/asciiopt.cxx) calling
ScGlobal::GetCharsetValue (sc/source/core/data/global.cxx), this charset field
would be interpreted as follows:
* if it is numeric, interpret it as the corresponding RTL_TEXTENCODING_* from
include/rtl/textenc.h;
* it it is one of the (case-ignoring) legacy strings ANSI, MAC, IBMPC,
IBMPC_437, IBMPC_850, IBMPC_850, IBMPC_860, IBMPC_861, IBMPC_863, IBMPC_865,
interpret it as the corresponding RTL_TEXTENCODING_*;
* otherwise, fall back to the "system encoding" (osl_getThreadTextEncoding;
which is typically UTF-8 at least on Linux and Mac, so an input of "UTF8" often
will result in causing the CSV filter to interpret the input as UTF-8 "by
accident").
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
