如何在Asp.net Web API中使用特定的CultureInfo [英] How use a specific CultureInfo in Asp.net Web API

问题描述

最近我在现有的VS桌面应用程序中添加了WEB API，一切正常，直到昨天我必须添加一个GET方法，其中包含三个参数，其中一个是Date。
嗯，起初我以为那会是一块蛋糕，但是令人惊讶的是我注意到，当我在2014/07/09（7月9日）发布了应用程序安装的服务器时，被视为2014/09/07（9月7日），因此我所有的比较从未奏效。

我尝试过从GET方法更改为POST方法，将区域和语言选项设置更改为服务器上的区域和语言选项设置，将日期作为字符串传递，使用字符串的部分在服务器上创建一个日期时间对象。不幸的是，他们都没有工作。

然后我记得这个桌面应用程序在其WCF项目中有一些方法（我正在传递给web API）传递日期完全没问题。看一下代码，我发现他们在使用日期的每个WCF项目类上都使用了这样的东西：

 导入System.Globalization 
导入System.Security.Permissions 
导入System.Threading 
 
公共类ServicioRemotoVentas 
实现IServicioRemotoVentas 
公共Sub New（）
 MyBase.New（）
 Thread.CurrentThread.CurrentCulture = New CultureInfo（es-PE，False）
 End Sub 
  

当然这个 Thread.CurrentThread.CurrentCulture = New CultureInfo（es-PE，False）必须在那里。
现在我想知道你以前在Web API中使用过这样的东西吗？如果是这样，你在哪里做了这样的配置。

这些是我的电脑上的设置：

这些是服务器设置：

我几乎忘了提及我通过所有使用此格式的日期 yyyy / M / d 与所有其他参数使用json。
这可能是当在Web API中反序列化字符串时，这是使用系统日期格式完成的，因为我没有指定要使用的文化信息？或者可能是尝试序列化/反序列化日期时的Json错误？

一如往常，您可以提供的任何建议或资源将不胜感激。

解决方案

如评论所述，ASP.NET运行时确实有这样的场景解决方案： web.cofig 元素 < worldwide> - （请参阅MSDN < worldwide> 元素）

它的结构定义为：

 < configuration> 
< system.web> 
< worldwide 
 enableClientBasedCulture =true | false
 requestEncoding =任何有效的编码字符串
 responseEncoding =任何有效的编码字符串
 fileEncoding =any有效的编码字符串
 
 responseHeaderEncoding =任何有效的编码字符串
 resourceProviderFactoryType = string 
 enableBestFitResponseEncoding =true | false
 
 culture =any有效的文化字符串
 uiCulture =任何有效的文化字符串/> 
  

所以，如果我们要强制服务器/ dev工作站在 en-US 文化我们应该使用这些显式设置：

 < worldwide 
 enableClientBasedCulture =false
 uiCulture =zh-CN
 culture =en-US/> 
  

这将为任何http请求使用适当（所需和设置）的文化。

另外有趣的可能是默认设置概述：

  < worldwide 
 requestEncoding =utf-8
 responseEncoding =utf-8
 fileEncoding =
 culture =
 uiCulture =
 enableClientBasedCulture =false
 responseHeaderEncoding =utf-8
 resourceProviderFactoryType =
 enableBestFitResponseEncoding =false/> 
  

另请参阅：

• 根据浏览器接受语言自动设置uiCulture


• < a href =http://stackoverflow.com/a/12985913/1679310>如何更改我的电脑的cultureInfo


• 和全球化元素本身

I've recently added WEB API to an existing VS desktop application and everything worked fine, until yesterday when I had to add a GET method that took three parameters, one of them a Date. Well, at first I thought that that was going to be a piece of cake, but much to my surprise I noticed that when I sent 2014/07/09 (9th July) on the server where the application was installed it was treated like 2014/09/07 (7th September) and for that reason all my comparisons never worked.

I have tried things like changing from a GET method to a POST method, changing my Regional and Language Options settings to the same on the server, passing the date as a String a created a Datetime object on the server using the parts of the string. Unfortunately none of them worked.

Then I remember that this desktop application have some methods on its WCF project (which I'm passing now to web API) that passed dates with no problem at all. Looking in the code for a while I found that they used something like this on every class of they WCF project that uses dates:

Imports System.Globalization
Imports System.Security.Permissions
Imports System.Threading

Public Class ServicioRemotoVentas
    Implements IServicioRemotoVentas        
    Public Sub New()
        MyBase.New()
        Thread.CurrentThread.CurrentCulture = New CultureInfo("es-PE", False)
    End Sub

Surely this Thread.CurrentThread.CurrentCulture = New CultureInfo("es-PE", False), must be there for something. Now I would like to know if you have used something like that in Web API before? if so how and where did you put such a configuration.

These are the settings on my pc :

And these are the server settings:

I almost forgot to mention that I pass all the dates using this format yyyy/M/d with all the other parameters using json. Is it perhaps that when the string is deserialized in the Web API this is done using the system date format because I haven't specify the culture info to use?? or maybe it is a Json error when trying serialize/deserialize the dates??

As always, any advice or resources you could provide would be greatly appreciated.

解决方案

As discussed in the comments, the ASP.NET runtime does have a solution for these scenarios: it is the web.cofig element <globalization> - (see MSDN <globalization> Element)

It's structure is defined as:

<configuration>
 <system.web>
  <globalization 
    enableClientBasedCulture="true|false"
    requestEncoding="any valid encoding string"
    responseEncoding="any valid encoding string"
    fileEncoding="any valid encoding string"

    responseHeaderEncoding = "any valid encoding string" 
    resourceProviderFactoryType = string
    enableBestFitResponseEncoding = "true|false"

    culture="any valid culture string"
    uiCulture="any valid culture string"/>

So, in case, that we want to force server/dev workstation to act in en-US culture we should use these explicit settings:

<globalization 
    enableClientBasedCulture="false" 
    uiCulture="en-US" 
    culture="en-US" />

This will use the proper (desired and set) culture for any http request.

Also interesting could be the default setting overview:

<globalization 
    requestEncoding="utf-8" 
    responseEncoding="utf-8" 
    fileEncoding="" 
    culture="" 
    uiCulture="" 
    enableClientBasedCulture="false" 
    responseHeaderEncoding="utf-8" 
    resourceProviderFactoryType="" 
    enableBestFitResponseEncoding="false" />

See also similar here:

• Set uiCulture automatically based on browser accept language
• How to change my computer's cultureInfo
• and the globalization Element itself

这篇关于如何在Asp.net Web API中使用特定的CultureInfo的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！