How use a specific CultureInfo in Asp.net Web API

2020-03-15 04:12发布

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 :

enter image description here

enter image description here

And these are the server settings:

enter image description here enter image description here

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.

2条回答
我欲成王,谁敢阻挡
2楼-- · 2020-03-15 04:40

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:

查看更多
家丑人穷心不美
3楼-- · 2020-03-15 05:03

It is mentioned in your question that the input is a string not a datetime object ("I almost forgot to mention that I pass all the dates using this format yyyy/M/d"). Your service interface isn't posted but I guess that the parameter type is DateTime and this is why the deserialization is incorrect.

Although the setting posted by Radim works it's not a fix but a hack/workaround.

There are two recommended ways to implement this:

  1. Use strings at both ends, i.e. the API parameter should also be string and the API specification should state what date format to use. Use DateTime.Parse(String, IFormatProvider) and specify the culture in contract (i.e. new CultureInfo("es-PE")) when the input string is converted to DateTime. https://msdn.microsoft.com/en-gb/kc8s65zs

  2. Use date objects at both ends. In this case the serializer will serialize the date object to a well known, culture independent format and the desrializer will deserialize the string to correct DateTime object.

    public void GetOrders(DatetTime fromDate)

I'd go with #2 because is generic and doesn't force the client to use a specific culture.

See also: The "right" JSON date format

查看更多
登录 后发表回答