上周同事往我工位上一坐扔过来一个 Excel 文件这几列设备编码读出来全是 1.23457E11 这种报表根本没法看。我瞄了一眼就知道是怎么回事——C# 里遇到带 E 的科学计数法数字几乎每个人迟早都会撞上一次。而且这条标题其实藏着两个方向一种是把1.234E05这种字符串解析成真正的数字另一种是反过来把 double 值输出成 123400 而不是 1.234E05。我平时处理上位机数据、读写 CSV、调试日志的时候两边都踩过不少坑这篇就把解析、格式化、精度、溢出这几个关键点一次讲透。1. 先搞清楚C# 里带 E 的数字是怎么冒出来的1.1 一条标题两个方向的烦恼很多人看到C# 代码里把带 E 的科学计数法数字这句话第一反应是把字符串转成数字但实际上工作中你会遇到两类完全相反的问题从 Excel、CSV、日志文件里读出来的是字符串1.23457E11你需要把它变成double或decimal参与计算。计算完的数字是double或floatToString()之后莫名其妙变成了1.23457E11写进文件或者拼接 SQL 语句时用户根本看不懂。我处理设备报文的时候经常遇到第二种情况。一个温度值明明只有 25.3结果因为某个中间计算把 double 放大到 2.5E16输出日志就成了天书。搞清楚你面对的是解析还是格式化后面的代码才写得对。1.2 E 到底是什么先统一认识科学计数法里的 E 表示乘以 10 的多少次方。1.2345E05就是1.2345 × 10^5 1234501e-3就是0.001。C# 里 E 大写小写都能识别正号可带可不带1e5、1E5、1e5全是合法写法。你还需要知道 .NET 数字类型在什么情况下会默认输出这种格式。我用下面这个表格总结最常见的触发场景基本能覆盖 90% 的生产环境场景表现典型类型double 值很大如超过 1e151234567890123456.0变1.234567890123456E15doubledouble 值很小如低于 1e-50.000001变1E-06doublefloat 值超出精度大数ToString()带 EfloatExcel 单元格读出COM Interop 的 Value2 返回1.23457E11doubleCSV 文件内容文本形式保存了1.23457E11string根本原因在于 .NET 的默认格式化规则当数值索引指数超出一定范围时G格式会主动切换成科学计数法。这个行为本身没问题问题是它不分场合日志、报表、接口输出全按同一套逻辑来用户自然就懵了。2. 把 1.234E05 解析成数字字符串到 double 和 decimal2.1 double.Parse 的正确打开方式最直接的方案是double.Parse但很多人死就死在没给参数上。我建议任何解析科学计数法的场景都显式传NumberStyles.Float和CultureInfo.InvariantCulturestring raw 1.2345E05; double value double.Parse(raw, NumberStyles.Float, CultureInfo.InvariantCulture); Console.WriteLine(value); // 123450NumberStyles.Float是解析指数格式的标准套餐它包含AllowLeadingWhite、AllowTrailingWhite、AllowLeadingSign、AllowDecimalPoint、AllowExponent这些组合。不传的话代码行为会依赖当前线程的 CultureInfo一旦部署的机器是德语、法语区域小数点都会变逗号直接解析失败。有一点很多人不知道double.Parse对溢出并不总是抛异常。传1e400给它它返回的是double.PositiveInfinity不是OverflowException。如果你后面拿这个结果去做比较、做运算很容易产生诡异的逻辑错误。所以解析 double 之前最好先检查一下结果是不是有限值if (!double.IsFinite(value)) { // 归零或者报错取决于你的业务 }2.2 decimal 的严格脾气必须显式声明 NumberStyles如果你处理的是金额、数量这种需要高精度的数据应该用decimal。但decimal.Parse比double.Parse更挑剔它默认的NumberStyles.Number并不包含AllowExponent所以你直接decimal.Parse(9.87654e8)会抛FormatException。必须这样写string raw 9.87654e8; decimal value decimal.Parse(raw, NumberStyles.Float, CultureInfo.InvariantCulture); Console.WriteLine(value); // 987654000这里有个容易混淆的点decimal本身能表示科学计数法的值但它对字符串里出现 E这件事非常敏感非要你点明允许指数符号才肯干活。所以遇到从外部文件读进来的数字字符串我第一反应就是NumberStyles.Float不管后面要转成什么类型先保证能解析再说。另外decimal.Parse溢出会直接抛OverflowException行为比 double 清晰得多。这个特性既是优点也是缺点——优点是不会静默出错缺点是如果你解析的字符串来源不可靠必须用TryParse包一层否则一个脏数据就能让整个程序崩溃。2.3 TryParse 和 Convert.ToDouble各有什么坑生产环境我更推荐TryParse理由很简单你无法控制外部文件里的每一行都规规矩矩。TryParse的签名和 Parse 一一对应不成功时返回 false不会抛异常if (double.TryParse(raw, NumberStyles.Float, CultureInfo.InvariantCulture, out double v)) { // 解析成功使用 v } else { // 记录原始字符串方便排查 }至于Convert.ToDouble(raw)我基本不用它来处理科学计数法字符串。原因是它在内部调用double.Parse时用的是当前文化信息你很难精细控制NumberStyles。一次在欧洲客户现场日志里全是1,5E3这种数据用Convert.ToDouble直接炸换回double.Parse(... InvariantCulture)才消停。用表格总结一下三个方案的选择逻辑方案适用场景注意点double.Parse确定数据格式规范、允许异常暴露溢出返回 Infinity需检查IsFinitedouble.TryParse外部文件、用户输入等不可控来源失败返回 false便于容错Convert.ToDouble快速写 demo、不关心文化无法精细控制格式跨语言环境有风险decimal.Parse/decimal.TryParse金额、精确计数等需要高精度必须加NumberStyles.Float3. 反向操作怎么让数字老老实实输出成十进制3.1 double.ToString 的默认行为和触发阈值前面说了double.ToString()在数值很大或很小时会自动切科学计数法。比如double huge 1e20; Console.WriteLine(huge.ToString()); // 1E20 double tiny 1e-6; Console.WriteLine(tiny.ToString()); // 1E-06问题在于默认的G格式只保留 15 位有效数字它为了通用性牺牲了可读性。写日志的时候你想看到完整的 100000000000000000000它偏给你1E20拼接 SQL 往数据库插数据时如果字段是 NVARCHAR1E20会被当成普通字符串存进去后面排序、统计全乱。3.2 用自定义格式串把科学计数法变回普通数字最简单的办法是给ToString传一个自定义格式double d 1234567890123456.0; Console.WriteLine(d.ToString(0)); // 1234567890123456 double e 0.00000123456789; Console.WriteLine(e.ToString(0.###############)); // 0.00000123456789格式串0.###############的含义是整数部分至少一位小数部分最多 15 位能省则省。它只做输出时格式化不会改变原始值。这里有个被问过无数次的问题那ToString(0.##)和ToString(F2)有啥区别区别在于0.##不会强制保留小数位1.5输出1.5F2会强制输出1.50。报表里想有小数就显示没小数就显示整数用0.##这种格式更合适。但要注意0.###############只对业务范围内的数值好使。如果d 1e-30015 个#根本装不下那么多零结果会变成0。所以这个方法的前提是你清楚业务数据不会小到离谱。3.3 为什么我推荐用 G17 而不是 R 来保证精度有时你并不在意是不是科学计数法但你不能接受精度丢失。比如把 double 序列化成字符串存进文件过两天再读回来希望还是同一个值。这时候用默认的ToString()是危险的它只保留 15 位有效数字往返一次精度就丢了。正确做法是string s value.ToString(G17, CultureInfo.InvariantCulture); double restored double.Parse(s, CultureInfo.InvariantCulture);G17表示最多保留 17 位有效数字。对 double 来说17 位有效数字可以保证往返无损——序列化之后解析回来位级完全相同。R格式在老的 .NET Framework 里也是做这个事的但 .NET Core 3.0 之后R和G17行为趋于一致我统一用G17避免记忆负担。需要提醒一句G17解决的是 double 的精度问题小数位输出规则仍然受数值范围影响大数还是会变科学计数法。如果你是写给用户看的报表用它不合理如果你是做数据持久化、跨系统传输它是必需品。4. 比格式更隐蔽的坑文化差异、符号和溢出4.1 InvariantCulture一行代码解决小数点变逗号的翻车现场我见过最典型的翻车是程序在本地跑好好的部署到一台英文系统的服务器上突然 CSV 里的1.5E3全解析失败。原因就是当前线程的CultureInfo变了——某些区域默认小数点不是.而是,double.Parse看到1.5E3时把.当成了千位分隔符直接拒绝。统一解法是任何 Parsing、Formatting 都显式传CultureInfo.InvariantCulturedouble v double.Parse(raw, NumberStyles.Float, CultureInfo.InvariantCulture);InvariantCulture不是英语文化而是一套与区域无关的固定规则它的小数点一定是.日期格式固定不会因为部署环境变化而改变。只要你做的是机器对机器的数据交换文件、接口、数据库一律用它这样代码的行为在任何机器上都一致。4.2 指数符号的边界e、E、正号、负号一个都不能漏C# 解析时对符号的处理比较宽松但宽松不代表你可以掉以轻心。我列一下实际测试过的合法写法1e5、1E5合法e 大小写都行。1e5、1e-5合法指数前可以有正负号。1.5e5、1.5E05合法尾数带小数完全没问题。1.e5、.5e2部分环境下可以但强烈不建议依赖这种写法。1e5.5非法指数必须是整数。如果你的数据源来自 Excel 导出它经常生成1.23457E11这种格式标准解析没问题。如果有外部系统给你的是1,23457E11逗号当小数点一旦带着InvariantCulture反而解析失败那时需要先把逗号替换成点号再解析。替换前确认字符串格式别无脑 Replace有些地区的千位分隔符也是逗号1,234.5和1.234,5完全是两回事。4.3 溢出、空字符串和 NaN解析之前先想清楚怎么办double.Parse(1e400)返回Infinitydecimal.Parse(1e400)抛异常这是很多人没意识到的差异。应对策略是在解析后立即做范围校验if (!double.IsFinite(result)) { // 记录异常数据按业务策略处理 }对于TryParse来说空字符串、纯空格、NaN、Infinity的行为在不同 .NET 版本上也有差异。double.TryParse(NaN, NumberStyles.Float, InvariantCulture, out _)在 .NET Core 3.0 之后其实是能成功解析出double.NaN的这不算 bug但你要知道有这个可能性。如果你的业务里 NaN 是非法的解析后还要多加一步double.IsNaN(result)判断。5. 高精度场景科学计数法字符串转 BigInteger 和自定义解析器5.1 decimal 不够用的时候怎么办decimal最多 28~29 位有效数字double 更少。遇到加密货币的 wei 单位、物联网设备上报的超长 ID、金融系统里的超大整数这两个类型都不够。如果目标是把1.234567890123456789e30转成不丢精度的整数long和decimal都装不下正统思路是用BigInteger。但注意BigInteger.Parse本身不支持指数格式。你需要先把字符串拆解再用BigInteger组合。下面是我在项目里用过的整数版解析方法要求结果必须是整数public static bool TryParseScientificToBigInteger(string text, out BigInteger result) { result 0; int eIndex text.IndexOfAny(new[] { e, E }); string mantissa eIndex 0 ? text.Substring(0, eIndex) : text; string exponentStr eIndex 0 ? text.Substring(eIndex 1) : 0; if (!int.TryParse(exponentStr, NumberStyles.Integer, CultureInfo.InvariantCulture, out int exponent)) return false; int dotIndex mantissa.IndexOf(.); int decimalPlaces dotIndex 0 ? mantissa.Length - dotIndex - 1 : 0; string digits dotIndex 0 ? mantissa.Remove(dotIndex, 1) : mantissa; if (!BigInteger.TryParse(digits, NumberStyles.Integer, CultureInfo.InvariantCulture, out BigInteger mantissaValue)) return false; int finalExponent exponent - decimalPlaces; if (finalExponent 0) return false; // 结果是小数超出本方法范围 result mantissaValue * BigInteger.Pow(10, finalExponent); return true; }调用方式if (TryParseScientificToBigInteger(1.2345e10, out var big)) { Console.WriteLine(big); // 12345000000 }这个方法的局限是只接受结果为整数的输入1e-5这类带负指数的会返回 false。要支持完整小数需要引入有理数或 BigDecimal 的实现一般情况下做到整数精度已经能覆盖 90% 的超大数需求了。5.2 手写解析器什么时候值得做有人看到BigInteger版本就觉得我也要手写一个解析器。我的建议是大部分场景不要。double.TryParse底层是经过高度优化的原生实现它的性能远超任何托管代码手写方案。只有在两种情况下才值得自己动手你要把科学计数法转成BigInteger或自定义高精度类型框架没有现成 API。数据来源格式固定且量极大比如每秒几十万条报文你想省掉NumberStyles组合带来的额外解析开销。第二种情况我实测过固定格式1.23E5下手写解析器能比TryParse快 30%~50%前提是完全没有异常分支、没有正则、没有文化检查。但收益并不总是值得——一旦数据格式出现意外手写解析器更容易崩TryParse反而更稳。5.3 封装一个读写两用的工具方法实际项目里我不会到处写NumberStyles.Float, CultureInfo.InvariantCulture而是封装成静态工具类统一入口public static class ScientificNotationHelper { public static bool TryParseDouble(string input, out double value) { return double.TryParse(input, NumberStyles.Float, CultureInfo.InvariantCulture, out value); } public static bool TryParseDecimal(string input, out decimal value) { return decimal.TryParse(input, NumberStyles.Float, CultureInfo.InvariantCulture, out value); } public static string ToFixedString(double value, int maxDecimalPlaces 15) { string format 0. new string(#, maxDecimalPlaces); return value.ToString(format, CultureInfo.InvariantCulture); } }封装的好处是以后如果发现某个 .NET 版本上NumberStyles行为有变化你只需要改一个文件而不是满项目搜double.Parse。我所有涉及文件导入导出、串口报文、数据库长数字的上位机项目都会在启动阶段放这么一组工具方法后面省非常多事。6. 实战场景连起来看Excel、JSON、CSV 里的科学计数法6.1 Excel 单元格读出科学计数法先判断类型再转换用 Excel COM Interop 读单元格时很多人直接取Range.Value2拿到的可能是 double一打印就是1.23457E11。更稳妥的做法是先看Range.Value2的实际类型object cellValue range.Value2; if (cellValue is double d) { string formatted d.ToString(0, CultureInfo.InvariantCulture); Console.WriteLine(formatted); } else if (cellValue is string s) { // 有些场景 Excel 已经把数字变成文本比如 1.23457E11 if (ScientificNotationHelper.TryParseDouble(s, out var parsed)) { Console.WriteLine(parsed.ToString(0, CultureInfo.InvariantCulture)); } }推荐用 OpenXML SDK 时单元格数值在v节点里也可能直接就是1.23457E11这种字符串。解析逻辑和上面完全一样先TryParseDouble再格式化别想当然地认为单元格里存的一定是 double。6.2 System.Text.Json 对带 E 数字的处理System.Text.Json对标准 JSON 数字里的科学计数法支持很好{value: 1e5}直接反序列化成100000。但 JSON 规范里数字不能带引号如果对方接口返回的是{value: 1e5}默认情况下JsonSerializer会直接报错。这时要配置NumberHandlingvar options new JsonSerializerOptions { NumberHandling JsonNumberHandling.AllowReadingFromString }; var model JsonSerializer.DeserializeMyModel(json, options);设置之后字符串形式的1e5也能被反序列化成数字类型。但注意这个选项是全局的开了之后所有数字属性都允许字符串形式JSON 规范严格性会下降最好配合测试用例保证数据源不会给你NaN之类的怪异字符串。6.3 CSV 导出后被 Excel 显示成科学计数法根源在 Excel这是最容易让开发背锅的一个场景。你用 C# 写了一个 16 位长的设备号到 CSV 文件用记事本打开明明是1234567890123456结果 Excel 一打开就显示成1.23457E15。这不是你代码的问题是 Excel 对超过 11 位的数字会自动应用科学计数法格式。解决办法是在 CSV 里把设备号写成文本形式// 数字前面加一个制表符Excel 会把它当成文本处理 string csvField \t deviceId.ToString(0, CultureInfo.InvariantCulture);或者用 Excel 的文本标记语法1234567890123456在数字外套一层等号和引号string csvField \ deviceId \;更正规的做法是导出真正的.xlsx文件时给对应列设置单元格样式为文本格式。只靠 CSV 加转义可以解决显示问题但用户后续复制数据到其他系统时可能带上号这个坑也要提前跟使用方讲清楚。回到最开始同事那个问题我最后给的方案其实很简单读 Excel 时用TryParseDouble加NumberStyles.Float解析成功后统一ToString(0)格式化输出再也没出现过1.23457E11泄漏到报表里的情况。我自己在项目里习惯留一组封装好的转换工具读写两端都走同一个入口格式化、解析、溢出校验全包在里面遇到科学计数法再也不用每次临时想参数怎么写。如果你的代码里还在裸写double.Parse(s)不带任何参数建议趁早改成显式声明文化信息的版本这个习惯能帮你避开一大半字符串数字的坑。 
长河君 · 2026/10/2 22:16:40 · 阅读 1.2k C#科学计数法全攻略：从解析到格式化避免数据错乱
上周同事往我工位上一坐扔过来一个 Excel 文件这几列设备编码读出来全是 1.23457E11 这种报表根本没法看。我瞄了一眼就知道是怎么回事——C# 里遇到带 E 的科学计数法数字几乎每个人迟早都会撞上一次。而且这条标题其实藏着两个方向一种是把1.234E05这种字符串解析成真正的数字另一种是反过来把 double 值输出成 123400 而不是 1.234E05。我平时处理上位机数据、读写 CSV、调试日志的时候两边都踩过不少坑这篇就把解析、格式化、精度、溢出这几个关键点一次讲透。1. 先搞清楚C# 里带 E 的数字是怎么冒出来的1.1 一条标题两个方向的烦恼很多人看到C# 代码里把带 E 的科学计数法数字这句话第一反应是把字符串转成数字但实际上工作中你会遇到两类完全相反的问题从 Excel、CSV、日志文件里读出来的是字符串1.23457E11你需要把它变成double或decimal参与计算。计算完的数字是double或floatToString()之后莫名其妙变成了1.23457E11写进文件或者拼接 SQL 语句时用户根本看不懂。我处理设备报文的时候经常遇到第二种情况。一个温度值明明只有 25.3结果因为某个中间计算把 double 放大到 2.5E16输出日志就成了天书。搞清楚你面对的是解析还是格式化后面的代码才写得对。1.2 E 到底是什么先统一认识科学计数法里的 E 表示乘以 10 的多少次方。1.2345E05就是1.2345 × 10^5 1234501e-3就是0.001。C# 里 E 大写小写都能识别正号可带可不带1e5、1E5、1e5全是合法写法。你还需要知道 .NET 数字类型在什么情况下会默认输出这种格式。我用下面这个表格总结最常见的触发场景基本能覆盖 90% 的生产环境场景表现典型类型double 值很大如超过 1e151234567890123456.0变1.234567890123456E15doubledouble 值很小如低于 1e-50.000001变1E-06doublefloat 值超出精度大数ToString()带 EfloatExcel 单元格读出COM Interop 的 Value2 返回1.23457E11doubleCSV 文件内容文本形式保存了1.23457E11string根本原因在于 .NET 的默认格式化规则当数值索引指数超出一定范围时G格式会主动切换成科学计数法。这个行为本身没问题问题是它不分场合日志、报表、接口输出全按同一套逻辑来用户自然就懵了。2. 把 1.234E05 解析成数字字符串到 double 和 decimal2.1 double.Parse 的正确打开方式最直接的方案是double.Parse但很多人死就死在没给参数上。我建议任何解析科学计数法的场景都显式传NumberStyles.Float和CultureInfo.InvariantCulturestring raw 1.2345E05; double value double.Parse(raw, NumberStyles.Float, CultureInfo.InvariantCulture); Console.WriteLine(value); // 123450NumberStyles.Float是解析指数格式的标准套餐它包含AllowLeadingWhite、AllowTrailingWhite、AllowLeadingSign、AllowDecimalPoint、AllowExponent这些组合。不传的话代码行为会依赖当前线程的 CultureInfo一旦部署的机器是德语、法语区域小数点都会变逗号直接解析失败。有一点很多人不知道double.Parse对溢出并不总是抛异常。传1e400给它它返回的是double.PositiveInfinity不是OverflowException。如果你后面拿这个结果去做比较、做运算很容易产生诡异的逻辑错误。所以解析 double 之前最好先检查一下结果是不是有限值if (!double.IsFinite(value)) { // 归零或者报错取决于你的业务 }2.2 decimal 的严格脾气必须显式声明 NumberStyles如果你处理的是金额、数量这种需要高精度的数据应该用decimal。但decimal.Parse比double.Parse更挑剔它默认的NumberStyles.Number并不包含AllowExponent所以你直接decimal.Parse(9.87654e8)会抛FormatException。必须这样写string raw 9.87654e8; decimal value decimal.Parse(raw, NumberStyles.Float, CultureInfo.InvariantCulture); Console.WriteLine(value); // 987654000这里有个容易混淆的点decimal本身能表示科学计数法的值但它对字符串里出现 E这件事非常敏感非要你点明允许指数符号才肯干活。所以遇到从外部文件读进来的数字字符串我第一反应就是NumberStyles.Float不管后面要转成什么类型先保证能解析再说。另外decimal.Parse溢出会直接抛OverflowException行为比 double 清晰得多。这个特性既是优点也是缺点——优点是不会静默出错缺点是如果你解析的字符串来源不可靠必须用TryParse包一层否则一个脏数据就能让整个程序崩溃。2.3 TryParse 和 Convert.ToDouble各有什么坑生产环境我更推荐TryParse理由很简单你无法控制外部文件里的每一行都规规矩矩。TryParse的签名和 Parse 一一对应不成功时返回 false不会抛异常if (double.TryParse(raw, NumberStyles.Float, CultureInfo.InvariantCulture, out double v)) { // 解析成功使用 v } else { // 记录原始字符串方便排查 }至于Convert.ToDouble(raw)我基本不用它来处理科学计数法字符串。原因是它在内部调用double.Parse时用的是当前文化信息你很难精细控制NumberStyles。一次在欧洲客户现场日志里全是1,5E3这种数据用Convert.ToDouble直接炸换回double.Parse(... InvariantCulture)才消停。用表格总结一下三个方案的选择逻辑方案适用场景注意点double.Parse确定数据格式规范、允许异常暴露溢出返回 Infinity需检查IsFinitedouble.TryParse外部文件、用户输入等不可控来源失败返回 false便于容错Convert.ToDouble快速写 demo、不关心文化无法精细控制格式跨语言环境有风险decimal.Parse/decimal.TryParse金额、精确计数等需要高精度必须加NumberStyles.Float3. 反向操作怎么让数字老老实实输出成十进制3.1 double.ToString 的默认行为和触发阈值前面说了double.ToString()在数值很大或很小时会自动切科学计数法。比如double huge 1e20; Console.WriteLine(huge.ToString()); // 1E20 double tiny 1e-6; Console.WriteLine(tiny.ToString()); // 1E-06问题在于默认的G格式只保留 15 位有效数字它为了通用性牺牲了可读性。写日志的时候你想看到完整的 100000000000000000000它偏给你1E20拼接 SQL 往数据库插数据时如果字段是 NVARCHAR1E20会被当成普通字符串存进去后面排序、统计全乱。3.2 用自定义格式串把科学计数法变回普通数字最简单的办法是给ToString传一个自定义格式double d 1234567890123456.0; Console.WriteLine(d.ToString(0)); // 1234567890123456 double e 0.00000123456789; Console.WriteLine(e.ToString(0.###############)); // 0.00000123456789格式串0.###############的含义是整数部分至少一位小数部分最多 15 位能省则省。它只做输出时格式化不会改变原始值。这里有个被问过无数次的问题那ToString(0.##)和ToString(F2)有啥区别区别在于0.##不会强制保留小数位1.5输出1.5F2会强制输出1.50。报表里想有小数就显示没小数就显示整数用0.##这种格式更合适。但要注意0.###############只对业务范围内的数值好使。如果d 1e-30015 个#根本装不下那么多零结果会变成0。所以这个方法的前提是你清楚业务数据不会小到离谱。3.3 为什么我推荐用 G17 而不是 R 来保证精度有时你并不在意是不是科学计数法但你不能接受精度丢失。比如把 double 序列化成字符串存进文件过两天再读回来希望还是同一个值。这时候用默认的ToString()是危险的它只保留 15 位有效数字往返一次精度就丢了。正确做法是string s value.ToString(G17, CultureInfo.InvariantCulture); double restored double.Parse(s, CultureInfo.InvariantCulture);G17表示最多保留 17 位有效数字。对 double 来说17 位有效数字可以保证往返无损——序列化之后解析回来位级完全相同。R格式在老的 .NET Framework 里也是做这个事的但 .NET Core 3.0 之后R和G17行为趋于一致我统一用G17避免记忆负担。需要提醒一句G17解决的是 double 的精度问题小数位输出规则仍然受数值范围影响大数还是会变科学计数法。如果你是写给用户看的报表用它不合理如果你是做数据持久化、跨系统传输它是必需品。4. 比格式更隐蔽的坑文化差异、符号和溢出4.1 InvariantCulture一行代码解决小数点变逗号的翻车现场我见过最典型的翻车是程序在本地跑好好的部署到一台英文系统的服务器上突然 CSV 里的1.5E3全解析失败。原因就是当前线程的CultureInfo变了——某些区域默认小数点不是.而是,double.Parse看到1.5E3时把.当成了千位分隔符直接拒绝。统一解法是任何 Parsing、Formatting 都显式传CultureInfo.InvariantCulturedouble v double.Parse(raw, NumberStyles.Float, CultureInfo.InvariantCulture);InvariantCulture不是英语文化而是一套与区域无关的固定规则它的小数点一定是.日期格式固定不会因为部署环境变化而改变。只要你做的是机器对机器的数据交换文件、接口、数据库一律用它这样代码的行为在任何机器上都一致。4.2 指数符号的边界e、E、正号、负号一个都不能漏C# 解析时对符号的处理比较宽松但宽松不代表你可以掉以轻心。我列一下实际测试过的合法写法1e5、1E5合法e 大小写都行。1e5、1e-5合法指数前可以有正负号。1.5e5、1.5E05合法尾数带小数完全没问题。1.e5、.5e2部分环境下可以但强烈不建议依赖这种写法。1e5.5非法指数必须是整数。如果你的数据源来自 Excel 导出它经常生成1.23457E11这种格式标准解析没问题。如果有外部系统给你的是1,23457E11逗号当小数点一旦带着InvariantCulture反而解析失败那时需要先把逗号替换成点号再解析。替换前确认字符串格式别无脑 Replace有些地区的千位分隔符也是逗号1,234.5和1.234,5完全是两回事。4.3 溢出、空字符串和 NaN解析之前先想清楚怎么办double.Parse(1e400)返回Infinitydecimal.Parse(1e400)抛异常这是很多人没意识到的差异。应对策略是在解析后立即做范围校验if (!double.IsFinite(result)) { // 记录异常数据按业务策略处理 }对于TryParse来说空字符串、纯空格、NaN、Infinity的行为在不同 .NET 版本上也有差异。double.TryParse(NaN, NumberStyles.Float, InvariantCulture, out _)在 .NET Core 3.0 之后其实是能成功解析出double.NaN的这不算 bug但你要知道有这个可能性。如果你的业务里 NaN 是非法的解析后还要多加一步double.IsNaN(result)判断。5. 高精度场景科学计数法字符串转 BigInteger 和自定义解析器5.1 decimal 不够用的时候怎么办decimal最多 28~29 位有效数字double 更少。遇到加密货币的 wei 单位、物联网设备上报的超长 ID、金融系统里的超大整数这两个类型都不够。如果目标是把1.234567890123456789e30转成不丢精度的整数long和decimal都装不下正统思路是用BigInteger。但注意BigInteger.Parse本身不支持指数格式。你需要先把字符串拆解再用BigInteger组合。下面是我在项目里用过的整数版解析方法要求结果必须是整数public static bool TryParseScientificToBigInteger(string text, out BigInteger result) { result 0; int eIndex text.IndexOfAny(new[] { e, E }); string mantissa eIndex 0 ? text.Substring(0, eIndex) : text; string exponentStr eIndex 0 ? text.Substring(eIndex 1) : 0; if (!int.TryParse(exponentStr, NumberStyles.Integer, CultureInfo.InvariantCulture, out int exponent)) return false; int dotIndex mantissa.IndexOf(.); int decimalPlaces dotIndex 0 ? mantissa.Length - dotIndex - 1 : 0; string digits dotIndex 0 ? mantissa.Remove(dotIndex, 1) : mantissa; if (!BigInteger.TryParse(digits, NumberStyles.Integer, CultureInfo.InvariantCulture, out BigInteger mantissaValue)) return false; int finalExponent exponent - decimalPlaces; if (finalExponent 0) return false; // 结果是小数超出本方法范围 result mantissaValue * BigInteger.Pow(10, finalExponent); return true; }调用方式if (TryParseScientificToBigInteger(1.2345e10, out var big)) { Console.WriteLine(big); // 12345000000 }这个方法的局限是只接受结果为整数的输入1e-5这类带负指数的会返回 false。要支持完整小数需要引入有理数或 BigDecimal 的实现一般情况下做到整数精度已经能覆盖 90% 的超大数需求了。5.2 手写解析器什么时候值得做有人看到BigInteger版本就觉得我也要手写一个解析器。我的建议是大部分场景不要。double.TryParse底层是经过高度优化的原生实现它的性能远超任何托管代码手写方案。只有在两种情况下才值得自己动手你要把科学计数法转成BigInteger或自定义高精度类型框架没有现成 API。数据来源格式固定且量极大比如每秒几十万条报文你想省掉NumberStyles组合带来的额外解析开销。第二种情况我实测过固定格式1.23E5下手写解析器能比TryParse快 30%~50%前提是完全没有异常分支、没有正则、没有文化检查。但收益并不总是值得——一旦数据格式出现意外手写解析器更容易崩TryParse反而更稳。5.3 封装一个读写两用的工具方法实际项目里我不会到处写NumberStyles.Float, CultureInfo.InvariantCulture而是封装成静态工具类统一入口public static class ScientificNotationHelper { public static bool TryParseDouble(string input, out double value) { return double.TryParse(input, NumberStyles.Float, CultureInfo.InvariantCulture, out value); } public static bool TryParseDecimal(string input, out decimal value) { return decimal.TryParse(input, NumberStyles.Float, CultureInfo.InvariantCulture, out value); } public static string ToFixedString(double value, int maxDecimalPlaces 15) { string format 0. new string(#, maxDecimalPlaces); return value.ToString(format, CultureInfo.InvariantCulture); } }封装的好处是以后如果发现某个 .NET 版本上NumberStyles行为有变化你只需要改一个文件而不是满项目搜double.Parse。我所有涉及文件导入导出、串口报文、数据库长数字的上位机项目都会在启动阶段放这么一组工具方法后面省非常多事。6. 实战场景连起来看Excel、JSON、CSV 里的科学计数法6.1 Excel 单元格读出科学计数法先判断类型再转换用 Excel COM Interop 读单元格时很多人直接取Range.Value2拿到的可能是 double一打印就是1.23457E11。更稳妥的做法是先看Range.Value2的实际类型object cellValue range.Value2; if (cellValue is double d) { string formatted d.ToString(0, CultureInfo.InvariantCulture); Console.WriteLine(formatted); } else if (cellValue is string s) { // 有些场景 Excel 已经把数字变成文本比如 1.23457E11 if (ScientificNotationHelper.TryParseDouble(s, out var parsed)) { Console.WriteLine(parsed.ToString(0, CultureInfo.InvariantCulture)); } }推荐用 OpenXML SDK 时单元格数值在v节点里也可能直接就是1.23457E11这种字符串。解析逻辑和上面完全一样先TryParseDouble再格式化别想当然地认为单元格里存的一定是 double。6.2 System.Text.Json 对带 E 数字的处理System.Text.Json对标准 JSON 数字里的科学计数法支持很好{value: 1e5}直接反序列化成100000。但 JSON 规范里数字不能带引号如果对方接口返回的是{value: 1e5}默认情况下JsonSerializer会直接报错。这时要配置NumberHandlingvar options new JsonSerializerOptions { NumberHandling JsonNumberHandling.AllowReadingFromString }; var model JsonSerializer.DeserializeMyModel(json, options);设置之后字符串形式的1e5也能被反序列化成数字类型。但注意这个选项是全局的开了之后所有数字属性都允许字符串形式JSON 规范严格性会下降最好配合测试用例保证数据源不会给你NaN之类的怪异字符串。6.3 CSV 导出后被 Excel 显示成科学计数法根源在 Excel这是最容易让开发背锅的一个场景。你用 C# 写了一个 16 位长的设备号到 CSV 文件用记事本打开明明是1234567890123456结果 Excel 一打开就显示成1.23457E15。这不是你代码的问题是 Excel 对超过 11 位的数字会自动应用科学计数法格式。解决办法是在 CSV 里把设备号写成文本形式// 数字前面加一个制表符Excel 会把它当成文本处理 string csvField \t deviceId.ToString(0, CultureInfo.InvariantCulture);或者用 Excel 的文本标记语法1234567890123456在数字外套一层等号和引号string csvField \ deviceId \;更正规的做法是导出真正的.xlsx文件时给对应列设置单元格样式为文本格式。只靠 CSV 加转义可以解决显示问题但用户后续复制数据到其他系统时可能带上号这个坑也要提前跟使用方讲清楚。回到最开始同事那个问题我最后给的方案其实很简单读 Excel 时用TryParseDouble加NumberStyles.Float解析成功后统一ToString(0)格式化输出再也没出现过1.23457E11泄漏到报表里的情况。我自己在项目里习惯留一组封装好的转换工具读写两端都走同一个入口格式化、解析、溢出校验全包在里面遇到科学计数法再也不用每次临时想参数怎么写。如果你的代码里还在裸写double.Parse(s)不带任何参数建议趁早改成显式声明文化信息的版本这个习惯能帮你避开一大半字符串数字的坑。