难道.NET Core到R2连中文编码都不支持吗？

今天写了一个简单的.NET Core RC2控制台程序，发现中文显示一直是乱码。查看操作系统设置，没有问题；查看源文件编码，也没有问题；甚至查看了Console字符编码相关的注册表，依然没有发现问题。难道NET Core到了RC2，莫非连一些常用的编码都不支持吗？

现在给大家重现这个问题，通过VS 2015创建一个.NET Core控制台程序。

我们在Main方法中只编写了如下几行行程序，将输入的字符串直接打印出来。

运行程序并分别输入中文和英文，我们会发现输入的中文显示为乱码。

为了进一步证明.NET Core对编码的局限，我们按照如下的方式调用Encoding的GetEncoding方法分别获取两种中文编码：GB2312和CP936。

程序执行结果证明，上述两种中文编码均不支持。

我们提供的两种中文编码在默认情况下都不支持，是因为默然情况下它们的EncodingProvider没有注册。上面显示的错误消息其实也提到了这一点，并且提到一个用于注册EncodingProvider的方法（Encoding.RegisterProvider）。于是我们按照下面的方式注册一个CodePagesEncodingProvider。

 11: Console.WriteLine(Encoding.GetEncoding(936));

 12: Console.WriteLine(Encoding.GetEncoding("GB2312"));

 13: while (true)

 14: {

 15: Console.WriteLine(Console.ReadLine());

 16: }

 17: }

 18: }

 19: }

CodePagesEncodingProvider定义在NuGet包“System.Text.Encoding.CodePages”之中，所以我们需要现在Project.json文件中按照如下的方式注册对应的依赖。

再次执行我们的程序后一切正常。

这个小问题其实体现了.NET Core最大的一个设计原则，那就是真正的模块化。对于.NET Framework来说，基础类型和API基本上通过几个核心的程序集来承载（比如mscorlib.dll，System.dll、System.Core.dll等），也就是在部署的时候，这些个程序集都是必需的——可能我们只使用到其中很少的API。这样的设计对于桌面应用，没有什么问题，现在.NET Core要实现真正的跨平台，并且创建适合多种设备的统一应用（UWP），这样的部署方式就有问题了。所有.NET Core将很多“不那么核心”的API分离出来定义在其他的程序集中，并通过相应的NuGet包来承载。那么我们的应用就可以“按需使用”这些NuGet包了。这是一种“pay-for-play”设计。

作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 原文链接

采用.Net Core技术框架开发的医院云LIS平台源码，B/S架构 基于B/S架构的医学实验室检验系统源码，整个系统的运行基于WEB层面，只需要在对应的工作台安装一个浏览器软件有外网即可访问。全套系统采用云部署模式，部署一套可支持多家医院检验科共同使用。 采用.Net Core新的技术框架、DEV报表、前端js封装、分布式文件存储、分布式缓存等，支持LIS独立部署，Docker部署等多种方式。
二级医院检验系统源码，SaaS模式.Net Core版云LIS系统源码 云LIS系统是医院信息管理的重要组成部分之一，集申请、采样、核收、计费、检验、审核、发布、质控、查询、耗材控制等检验科工作为一体的网络管理系统。云LIS系统不仅是自动接收检验数据，打印检验报告，系统保存检验信息的工具，而且也是医生科研、诊疗的重要参考指标。
.NET Core 3.0 控制台实现数据同步 写作背景：应工作环境中存在一个数据库实例多站点部署模式，每次同步数据都需要手动从本地导入目标站点数据库，空余之际写了个简单 Demo；技术点或 Nuget 元包：.NET Core 3.0Console；Microsoft.Data.SqlClient -v 1.0.19269.1；开发工具 VS 2019 Pro x64 v16.3.3；MS-SQLServer 2014 Enterprise ...