1、背景

公司业务遍及全球各地，对应业务系统国际化就是顺理成章的事情。最近就接手了一批新老系统的国际化任务，这里把一些探索经验、案例记录下来。本身改造和探索过程包括.NET MVC的，以及.NET CORE WEB API的，但这里旧版MVC的就不描述了，重点介绍netcore下的国际化方案。国际化重点在于多语言支持，以及多时区支持，本文就从这两个方面入手。

预设：有一个前后端分离的系统，前端由i18n负责多语言支持，后端不渲染视图，提供api返回数据给前端。

Demo解决方案截图：

2、多语言

如上解决方案截图，Common.Resource是多语言资源工程，ExceptionHandlerTest是示例web api项目，Service是api项目依赖的服务工程。之所以这么设计场景，是为了探索资源文件放在单独工程下，以及非Web Api工程中的多语言方案，这点在官方教程中基本是没有的。

先来看demo要干的事情：HomeController中有个SayHello方法，此方法调用HomeService中的SayHello方法返回欢迎语信息，我们要做的就是对HomeService中返回的欢迎语进行语言协商。下边来看看具体怎么实现：

2.1、定义多语言资源文件

以支持中英文为例，定义如下图资源文件，步骤与FX下的很类似。

唯一的重大区别，是如果你希望在单独工程中放置资源配置，那就添加一个单独类代码文件，假如你的资源是Common.en.rex，那对应类就应该是Common，这点在跨程序集寻找资源文件中至关重要，官网文档中可没有描述这至关重要的一点，别问我怎么知道的， 问就是看core底层源码。。。

资源文件中定义的资源配置项如下：

2.2、配置多语言服务及中间件

1）注册本地化服务及HomeService服务

HomeService必须使用容器解析，否则core底层没法注入多语言基础服务到我们的组件，那你就只能手动传入。

2）注册本地化中间件

2.3、系统中引入多语言设置项

1）HomeService中注入IStringLocalizer服务

2）SayHello方法引用多语言配置项

2.4、实际效果

1）默认访问

不做任何设置，系统也无设置对应cookie情况下，netcore直接取浏览器语言环境设置，就是下图这个地方：

假如我们将浏览器语言环境改成英文，那默认情况下系统就会选取英文了。

2）通过查询字符串切换语言

如上图，我们使用netcore规定的culture=en格式向后端传递语言环境信息。具体语言环境选择优先级是这样的：查询字符串 > cookie > 浏览器语言环境设置，这在官网有详细介绍，看底层源码也证实了这个。基于cookie选取语言环境时候，cookie名称是可以修改的，我实际项目就是如此，官网文档也有介绍，这里不做赘述。

3、多时区

3.1、场景预设

预设1：HomeController中有两个方法，GetTime返回服务端或数据库中存储的UTC时间，系统根据客户本地时区自动转换成其对应时间；SetTime方法接收客户本地时区下的时间，转换成UTC时间存入服务器或数据库

预设2：系统支持中国东八区时间及印度东5区时间

3.2、自定义时间转换器

/// <summary>/// 日期转换/// </summary>
public class DateTimeOffsetJsonConverter : JsonConverter<DateTimeOffset>
{
    private TimeZoneInfo chinaZoneInfo = TimeZoneInfo.CreateCustomTimeZone("zh", TimeSpan.FromHours(8), "中国时区", "China time zone");
    private TimeZoneInfo indiaZoneInfo = TimeZoneInfo.CreateCustomTimeZone("en-IN", TimeSpan.FromHours(5), "印度时区", "India time zone");

    public override DateTimeOffset Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var currentZoneInfo = Thread.CurrentThread.CurrentCulture.Name.Contains("zh") ? chinaZoneInfo : indiaZoneInfo;
        //var time1 = DateTimeOffset.Parse(reader.GetString());//var time2 = time1.ToOffset(currentZoneInfo.BaseUtcOffset);var time1 = new DateTimeOffset(DateTime.Parse(reader.GetString()), currentZoneInfo.BaseUtcOffset); 
        var time2 = time1.ToUniversalTime();
        //var time3 = time2.ToUniversalTime();

        return time2;
    }

    public override void Write(Utf8JsonWriter writer, DateTimeOffset value, JsonSerializerOptions options)
    {
        var currentZoneInfo = Thread.CurrentThread.CurrentCulture.Name.Contains("zh") ? chinaZoneInfo : indiaZoneInfo;
        writer.WriteStringValue(value.ToOffset(currentZoneInfo.BaseUtcOffset).ToString("yyyy-MM-dd HH:mm:ss"));
    }
}

如上所述，自定义时间序列化转换器，读取时间时，根据客户语言环境匹配其对应时区，时区中有对应UTC偏离时间信息，据此转换成UTC时间；序列化写入时候，同样根据语言环境匹配时区信息，将服务器端的UTC时间按照时区偏离转换成本地时间返给客户端。

3.3、时间转换测试

1）获取服务器时间

其中currentTime是模拟服务器上或数据库中取出来的UTC时间，然后什么不做直接返回，具体时间转换交由时间转换器负责。下边看效果：

中文环境时间：

可以看到，原始UTC时间2019-07-15 08:30:00在中国东八区8个小时偏离下，返给客户端变成了16:30:00，即中国本地时间；

英文环境：

当语言环境切换为英文，则匹配到印度东5区时区信息，UTC时间2019-07-15 08:30:00转换成印度本地时间2019-07-15 13:30:00。

2）写入时间到服务器

同样的，接收到客户端时间后，我们业务代码层不做任何设置，交由时间转换器去负责，具体看效果：

中文环境：

传入本地时间2019-07-15 16:30:00，到了服务器，时间如下：

可以看到，中国东八区时间2019-07-15 16:30:00在服务器上转换成UTC时间2019-07-15 08:30:00；

同样的本地时间，但语言环境为英语：

可以看到，印度东5区的本地时间2019-07-15 16:30:00到服务器，转换成UTC时间2019-07-15 11:30:00。

4、总结

系统国际化的重点，在于语言环境国际化，以及多时区自适应，解决这两点，剩下就不是啥问题了。关于时区，这里是以服务器及数据库中统一保存UTC时间为例，但也有一定麻烦，比如你需要后台维护数据，尤其是直接在数据库中维护这种，就需要做本地时间和UTC时间的手动处理，除非你是英国人，身处英国，用英国的时区。针对这点可以做对应发散，例如假如系统中文用户占多数，运维也主要是中国员工，那就可以采取服务器或数据库统一存储中国东8区的时间，其他本地时间向中国时间进行转换的做法，思路、解决方案是一致的。

转自

https://www.cnblogs.com/guokun/p/13581632.html