不同环境下的十进制解析差异

Question

晚上，

我正在用头撞墙，遇到以下问题：

• 我正在从带有size=16 的Number 列的单元格中加载数字 和decimal places = 2 在dBase III .dbf 文件中。

• 使用DbfViewer 查看时，这些数字显示为：12345.12，其中没有千位分隔符和小数点 分隔符是.。

• 我使用decimal.parse(val)解析数据库中单元格中的数字。

• 我用那个号码做事。

• 我正在使用ClosedXML 库将数字粘贴到具有以下公式的.xlsx Excel 文件单元格中："=R[-1]C * 100/" & val 其中val 是我从dBaseIII 数据库文件中获得的值。这是通过以下语句完成的：

  • Dim formula as String = "=R[-1]C * 100/" & project.TotalIncome(i)
  • cell.FormulaR1C1 = formula。

• 我正在使用两种编程环境：

  1. 带有Visual Studio 2013 Community 和Office 2010 的Windows 8.1 机器。
  2. 带有Visual Studio 2013 Ultimate 和Office 2013 的Windows 8.1 机器。

• 我已确保两种环境具有相同的Language, Date, Time and Number 格式，适用于 Windows 和 Office。

当我从Option 1 Environment 构建并执行程序时，所有内容都可以正常粘贴到 Excel 文件中。我导航到包含公式的单元格，无论获得的value 是否有小数位，公式都在那里。

但是，如果我从Option 2 Environment 构建并执行程序，我会得到：

• Removed Records: Formula from /xl/worksheets/sheet.xml part
• Removed Records: Formula from /xl/calcChain.xml part (calculation properties)

我尝试在Environment 2 中添加断点，打开Locals 窗口并编辑那些有小数位的values，一切都按预期工作，而当我使用Environment 1 时，当@ 987654353@ 有小数位。

我尝试了以下方法（Environment 2）：

Dim nfi As NumberFormatInfo = New CultureInfo("es-ES", False).NumberFormat
nfi.NumberDecimalSeparator = ","
value = Decimal.Parse(row("VALUECOL"), nfi)

还有：

value = Decimal.Parse(row("VALUECOL"), New CultureInfo("es-ES"))

无济于事。

我在Environment 2 中打开了包含 Excel 工作表信息的 XML 文件，发现：

<x:c r="L101" s="41">
    <x:f>L100 * 100/57125,71</x:f>
</x:c>

而Environment 1 创建的同一 XML 文件的定义具有以下单元格值：

<x:c r="L101" s="41">
    <x:f>L100 * 100/57125.71</x:f>
</x:c>

那么，它是 Visual Studio Locale 的东西（据我所知，两者都相同），还是我错过了其他东西？

---

编辑：打印出当前的语言环境：

Console.WriteLine(CultureInfo.CurrentCulture.Name)

在Environment 1 和Environment 2 上产生相同的es-ES。

---

编辑 2： 取自：Microsoft Office XML formats. Defective by design.

为了节省时间，Microsoft 选择使用美国英语存储 XML 无论上述所有设置如何。 [...]

另外，对于 Excel 公式，这意味着公式名称是美国英语 公式名称，[...] 这意味着您愿意使用美国英语 函数名称（加上美国英语分隔符，...）。

所以基本上这一切都归结为（我相信）将decimal 值预本地化为Excel XML，同时考虑到某处。

在Environment 2 中，我写入Excel 文件的任何其他（非公式）值都以en-US 本地化值（即12345.12）的形式出现在XML 中。其中大多数是通过dataTable 导入引入的。但是，由于编写公式需要输入字符串，并且 Visual Studio 将区域设置应用于所述字符串，因此它在 Excel XML 中以 12345,12 结尾，这会导致前面提到的错误。

那么，Visual Studio 从Environment 1 那里得到到底与Environment 2 有什么不同？所有可能的 UI 本地化选项在两台机器上都完全相同......

Answer 1

我之前也遇到过类似的问题，发现我的项目引用中有不同的dll文件。 dll 的名称相同，我只注意到文件大小不同。一旦我在两台开发机器上手动链接到同一个，我就得到了预期的结果。

就像我说的，我的问题不同......但它确实也涉及 excel 文件，我确实在一台开发机器上安装了 Excel 2010，而在另一台机器上安装了 2013。

Answer 2

我什至不知道这是否可以作为答案，因为我仍然不知道Environment 1 与Environment 2 不同的本地化变量在哪里。

但是，Visual Studio 似乎 -在使用不同的本地化时-在内部处理去本地化的 decimal 变量，但处理本地化的 string 变量。即使在调试期间检查locals 面板，存储在dictionary 条目中的decimal 数字的值也将作为其本地化版本出现在keyValuePair 条目上，并作为非本地化的en-US 值出现在展开：

因此，当将dataTable 作为一个整体 输出到 Excel 文件时，它会作为 en-US 值写入 XML。另一方面，当输出一个公式（又名string）时，它会覆盖相关decimal 值的本地化版本。

结论：在本地化系统中处理 Office 文件时，只需将数据写为去本地化（即en-US），然后让软件为您本地化。

最终做了以下脏补丁：

Dim formula As String = "=R[-1]C * 100/" & project.TotalIncome(i).ToString().Replace(",", ".")