Open monqkim opened 6 years ago
@monqkim the v
values are coming from the file itself directly, which means that Excel likely stored the values with the remainder. Can you share a sample file?
and here is my options.
const XLSX_READ_FILE_OPTS = {
bookDeps: false,
bookFiles: false,
bookProps: false,
bookSheets: false,
bookVBA: false,
cellDates: true,
cellFormula: false,
cellHTML: false,
cellNF: false,
cellStyles: false,
cellText: true,
dense: false,
raw: false,
sheetStubs: false,
WTF: false,
};
Just so we're on the same page here, the v
values are exactly what is stored in the Excel file. To see, go to
https://sheetjs.com/cfb-editor/ then drag and drop the sample file, click "xl/worksheets/sheet1.xml" then click "View as Text" to see what is actually stored in the file:
It's clearly an artifact of the IEEE754 representation that Excel and JavaScript use, which is unfortunate but it is what it is.
Thanks for the answer, but why the 'w' value is different from the others? The 'w' of other cells reflects original formatted text accurately, but only 18800000000
cell's 'w' is different from the original value. Is it related to the digits after the floating point?
Has anyone solved this problem
in excel:
in DOM
the code i use is
const wb = XLSX.read(fileContent, { type: 'binary' });
const wsname = wb.SheetNames[0];
const ws = wb.Sheets[wsname];
const jsonData: any[][] = XLSX.utils.sheet_to_json(ws, { header: 1, raw: false});
raw:true is also fixed the problem in different project 😂 . It is not about the .w format.
I have an xlsx file including some big numbers below.
After converting this file using XLSX.sheet_to_json(), the part of result data is
Due to inaccurate number converting, I used to use 'w' property to make accurate result, but in "K50" cell case, 'w' property is not accurate also. (original value is 18800000000)