Repository navigation
Properties of type long are not converted to text correctly #627
Description
Excel Type
- XLSX
- XLSM
- CSV
- OTHER
Upload Excel File
[
b25a7003-8062-4c93-8926-a1a1407697a8.xlsx
](url)
MiniExcel Version
1.33.0
Description
我的数据源有long类型的字段，已经在代码中将excel的列格式设置为文本格式(@)，虽然生成的excel看起来是正常显示了的，但实际上点击下就变成了科学计数法，而且列的格式显示的仍然是常规。
var path = Path.Combine("C:\\Demo\\", $"{Guid.NewGuid()}.xlsx");
var config = new OpenXmlConfiguration
{
AutoFilter = false,
DynamicColumns =
[
new DynamicExcelColumn("long2") { Format = "@", Width = 25 },
]
};
var value = new[] { new { long2 = "1550432695793487872" } };
MiniExcel.SaveAs(path, value, configuration: config);
Metadata
Metadata
Assignees
Labels
No labels
Activity
shps951023 commentedon Jul 21, 2024
可以判断是否超过值，假如超过在前面加上
'shps951023 commentedon Jul 21, 2024
更新，SaveAs 应该要增加长数值判断，自动加上 style
quotePrefix="1"并把 text 的值改为去除'下个版本实现选项
EnableQuotePrefix给用户选择Gouqi-Zn commentedon Dec 4, 2024
SaveAsByTemplate是否也要增加长数值判断
The-Mojoo commentedon Apr 14, 2025
这个目前还没有任何进展吗？最近又有优化的需求，但是因为这个问题一直没办法继续。
shps951023 commentedon Apr 14, 2025
有思路了，应该最近可以支持
The-Mojoo commentedon Apr 14, 2025
谢谢，一直在关注后期版本，今天看到稍微大点的版本更新后仍未看到相关选项，看到三个相关的TestIssue672的samples，又因为最近要优化导出逻辑，所以过来留言想看下进展。
[-]long类型的字段无法正常设置为文本[/-][+]Properties of type long are not converted to text correctly[/+]The-Mojoo commentedon May 14, 2026
Thank you @michelebastione , I finally waited for this issue to be fixed, and for the version update.
But I just rewrote the same demo from the issue and opened the generated file, and found that the previous problem still occurs. After double-clicking, it still turns into scientific notation ending with 00000.
I want to know if I have set something incorrectly, or if it is really different from what I imagined, that I could simply display it as a string?
My goal is to successfully save this long type, and be able to edit it in Excel without its value changing after double-clicking, mainly I want it to be in string format.
michelebastione commentedon May 15, 2026
@The-Mojoo I apologize for yet another inconvenience, I was really sure this last update would have solved the issue. At this point I'm fairly sure this is a quirk of the Excel engine that is being too helpful to a fault even when the style is set explicitly if the values are inlined rather than being referenced from the shared strings as we do when exporting. Let me do some more testing and I'll get back at you again.
Edit: never mind, it was a much simpler oversight, I will have it fixed asap. You'll still have to covert the number to string first though, otherwise Excel will truncate it to 15 digits anyways before recognizing as text: