如何绕过ASP.NET Core表单数据的区域性敏感转换？

我在ASP.NET Core应用中使用本地化中间件读取AspNetCore.Culture Cookie值，配置代码如下：

services.Configure<RequestLocalizationOptions>(options =>
{
    options.DefaultRequestCulture = new RequestCulture(myDefaultCulture, myDefaultCulture);
    options.SupportedCultures = options.SupportedUICultures = mySupportedCultures;

    options.RequestCultureProviders.Clear();
    options.RequestCultureProviders.Add(new CookieRequestCultureProvider());
});

我有一个Action用于接收客户端表单提交的地理位置值，表单代码如下：

<div>
    <input id="lat" name="lat" value="">
    <input id="long" name="long" value="">
</div>

提交的HTTP请求中，值类似27.67807948515076和**-109.11917758267799**。Action接收两个double类型参数，当Cookie为en-us时正常工作，但设置为es-es时，接收到的值变成2767807948515076和**-10911917758267799**。这是因为ASP.NET Core默认会对表单数据执行区域性敏感转换。

请问处理这种情况的最佳实践是什么？应该让客户端检测Cookie设置并发送不同格式的数据，还是在服务端绕过区域性敏感转换？我不想随意修改默认行为，但如果需要绕过，该如何实现？

我试过用字符串类型接收值再解析为double，这种方法可行，但我觉得这是常见场景，应该有更优的解决方案。

1. 优先选择服务端统一处理（推荐） #

客户端发送标准化格式的数值（始终用点作为小数点分隔符）是合理的，但让客户端根据Cookie动态调整格式会增加前端复杂度且易出错。更可靠的方式是在服务端统一处理区域性不敏感的模型绑定，可针对特定字段或全局配置：

方案A：全局配置模型绑定使用固定区域性

如果应用中大部分表单数据（如API接口参数、地理位置、金额等）需要标准化数值解析，可在Program.cs中全局设置模型绑定使用InvariantCulture：

builder.Services.AddControllersWithViews(options =>
{
    // 为double类型注册固定区域性的模型绑定器
    options.ModelBinderProviders.Insert(0, new SimpleTypeModelBinderProvider(
        typeof(double),
        new SimpleTypeModelBinder(typeof(double), CultureInfo.InvariantCulture)));
    // 若有需要，可添加float、decimal等其他数值类型的绑定器
});

该配置不会影响本地化中间件的其他功能（如视图本地化），仅让模型绑定阶段忽略当前请求的区域性，用固定格式解析数值。

方案B：针对特定字段使用自定义特性标记

如果只有个别字段需要绕过区域性敏感转换，可自定义绑定特性和绑定器：

// 自定义特性
public class InvariantDoubleAttribute : ModelBinderAttribute
{
    public InvariantDoubleAttribute()
    {
        BinderType = typeof(InvariantDoubleModelBinder);
    }
}

// 自定义绑定器
public class InvariantDoubleModelBinder : IModelBinder
{
    public Task BindModelAsync(ModelBindingContext bindingContext)
    {
        var valueProviderResult = bindingContext.ValueProvider.GetValue(bindingContext.ModelName);
        if (valueProviderResult == ValueProviderResult.None)
        {
            return Task.CompletedTask;
        }

        bindingContext.ModelState.SetModelValue(bindingContext.ModelName, valueProviderResult);
        var value = valueProviderResult.FirstValue;
        
        if (double.TryParse(value, NumberStyles.Any, CultureInfo.InvariantCulture, out var result))
        {
            bindingContext.Result = ModelBindingResult.Success(result);
        }
        else
        {
            bindingContext.ModelState.TryAddModelError(bindingContext.ModelName, "无效的数值格式");
        }
        return Task.CompletedTask;
    }
}

// Action中使用
public IActionResult SubmitLocation([InvariantDouble] double lat, [InvariantDouble] double @long)
{
    // 业务逻辑处理
}

2. 客户端方案（不推荐） #

若必须在客户端处理，可让前端始终将数值格式化为点分隔的字符串，忽略当前Cookie的区域性：

// 获取地理位置后格式化
const lat = position.coords.latitude.toFixed(15);
const lng = position.coords.longitude.toFixed(15);
// 赋值给表单输入框
document.getElementById('lat').value = lat;
document.getElementById('long').value = lng;

这种方式虽简单，但后续若有更多数值字段，维护成本会很高，且无法避免用户手动输入逗号分隔数值导致的解析错误。

总结 #

最佳实践是在服务端针对数值类型的模型绑定使用InvariantCulture，既无需修改客户端逻辑，又能保证解析一致性。全局配置适合大部分场景，自定义特性适合个别字段的特殊需求。

内容的提问来源于stack exchange，提问作者Gao Haitao