https://bz.apache.org/ooo/show_bug.cgi?id=126901
orcmid <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from orcmid <[email protected]> --- (In reply to damjan from comment #0) > Make a CSV file containing: > +,123 [ ... ] > It should be imported as the string "+,123" instead, as numbers cannot begin > with thousand separators. What happens if you use quotes around the string (that is, literally "+,123") the normal means for determining that a cell value is meant to be taken as text and not anything else? The import scheme for text (including CSV) is rather generous and attempts to handle more cases than standard CSV, which is why there are all those parameters. It also tends to find numbers in any surround and use that number. So it accepts cases that Calc never produces in CSV output when text fields are quoted. Because the input filter has so many variations, it is necessary to delimit text fields so they import properly always when it is known that conventional Excel CSV is intended. The input filter should then be set accordingly. I assume that having the text filter work in the way it does was considered a feature, and the few kinds of CSVs that Calc produces were simply lumped into cases of this more "general" feature. EXPERIMENTS Importing that file into Excel 2016 with a US locale creates two fields, one with the text "+" and another with the numeral 123. I don't know what happens in locales where the comma is a decimal separator. Same as +.123? Using ",123" (with the quotes) instead works fine directly in Excel and will work fine in OpenOffice Calc once the Option "Quoted field as text" is checked for the text import. I am confirming the behavior. Whether it is a defect or by design is a bigger question. -- You are receiving this mail because: You are the assignee for the issue.
