wsl - ubuntu
I thought this was an interesting and subtle bug behavior that was not only hard to track down but hard to pin down. I wasn&＃39;t sure &＃39;whose fault it was.&＃39;
我认为这是一个有趣且微妙的错误行为&＃xff0c;不仅难以追踪&＃xff0c;而且难以确定。 我不确定“是谁的错”。
Here&＃39;s the story. Feel free to follow along and see what you get.
这是故事。 随时随地看看您能得到什么。
I was running on Ubuntu 18.04 under WSL.
我在WSL下的Ubuntu 18.04上运行。
I made a console app using .NET Core 3.0. You can install .NET Core here http://dot.net/get-core3
我使用.NET Core 3.0创建了一个控制台应用程序。 您可以在此处安装.NET Core http://dot.net/get-core3
I did this:
我这样做&＃xff1a;
dotnet new console
dotnet add package Humanizer --version 2.6.2
Then made Program.cs look like this. Humanizer is a great .NET Standard library that you&＃39;ll learn about and think "why didn&＃39;t .NET always have this!?"
然后使Program.cs看起来像这样。 Humanizer是一个很棒的.NET Standard库&＃xff0c;您将学习它并认为“ .NET为什么不总是这样&＃xff1f;”。
using System;
using Humanizer;
namespace dotnetlocaletest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(3501.ToWords());
}
}
}
You can see that I want the app to print out the number 3051 as words. Presumably in English, as that&＃39;s my primary language, but you&＃39;ll note I haven&＃39;t indicated that here. Let&＃39;s run it.
您可以看到我希望该应用程序将数字3051作为单词打印出来。 大概是英语&＃xff0c;因为那是我的主要语言&＃xff0c;但是您会注意到&＃xff0c;我在这里没有指出。 让我们运行它。
Note that app this works great and as expected in Windows.
请注意&＃xff0c;该应用程序运行良好&＃xff0c;并且在Windows中符合预期。
scott&＃64;IRONHEART:~/dotnetlocaletest$ dotnet run
3501
Huh. It didn&＃39;t even try. That&＃39;s weird.
嗯它甚至没有尝试。 那真是怪了。
My Windows machine is en-us (English in the USA) but what&＃39;s my Ubuntu machine?
我的Windows机器是en-us(美国英语)&＃xff0c;但是我的Ubuntu机器是什么&＃xff1f;
scott&＃64;IRONHEART:~/dotnetlocaletest$ locale
LANG&＃61;C.UTF-8
LANGUAGE&＃61;
Looks like it&＃39;s nothing. It&＃39;s "C.UTF-8" and it&＃39;s nothing. C in this context means the POSIX default locate. It&＃39;s the most basic. C.UTF-8 is definitely NOT the same as en_US.utf8. It&＃39;s a locate of sorts, but it&＃39;s not a place.
看起来什么都没有。 是“ C.UTF-8”&＃xff0c;什么都没有。 在这种情况下&＃xff0c;C表示POSIX默认位置。 这是最基本的。 C.UTF-8绝对不同于en_US.utf8。 这是各种各样的地点&＃xff0c;但不是地方。
What if I tell .NET explicitly where I am?
如果我明确告诉.NET怎么办&＃xff1f;
static void Main(string[] args)
{
Thread.CurrentThread.CurrentUICulture &＃61; new CultureInfo("en-US");
Console.WriteLine(3501.ToWords());
}
And running it.
并运行它。
scott&＃64;IRONHEART:~/dotnetlocaletest$ dotnet run
three thousand five hundred and one
OK, so things work well if the app declares "hey I&＃39;m en-US!" and Humanizer works well.
好的&＃xff0c;所以如果应用程序声明“嘿&＃xff0c;我在美国&＃xff01;”&＃xff0c;一切就可以正常进行。 人性化效果很好。
What&＃39;s wrong? Seems like Ubuntu&＃39;s "C.UTF-8" isn&＃39;t "invariant" enough to cause Humanizer to fall back to an English default?
怎么了&＃xff1f; 似乎Ubuntu的“ C.UTF-8”不够“不变”&＃xff0c;无法导致Humanizer退回到英语默认值吗&＃xff1f;
Seems like other people have seen unusual or subtle issues with Ubuntu installs that are using C.UTF-8 versus a more specific locale like en-US.UTF8.
似乎其他人已经看到使用C.UTF-8的Ubuntu安装相对于en-US.UTF8这样更特定的语言环境存在异常或细微问题。
I could fix this in a few ways. I could set the locale specifically in Ubuntu:
我可以通过几种方式解决此问题。 我可以在Ubuntu中专门设置语言环境&＃xff1a;
locale-gen en_US.UTF-8
update-locale LANG&＃61;en_US.UTF-8
Fortunately Humanizer 2.7.2 and above has fixed this issue and falls back correctly. Whose "bug" was it? Tough one but in this case, Humanizer had some flawed fallback logic. I updated to 2.7.2 and now C.UTF-8 falls back to a neutral English.
幸运的是&＃xff0c;Humanizer 2.7.2和更高版本已解决此问题&＃xff0c;并可以正确回退。 那是谁的“臭虫”&＃xff1f; 艰难&＃xff0c;但在这种情况下&＃xff0c;Humanizer具有一些有缺陷的后备逻辑。 我更新到2.7.2&＃xff0c;现在C.UTF-8恢复为中性英语。
That said, I think it could be argued that WSL/Canonical/Ubuntu should detected my local language and/or set locale to it on installation.
就是说&＃xff0c;我认为可以说WSL / Canonical / Ubuntu应该检测到我的本地语言并/或在安装时为其设置语言环境。
The lesson here is that your applications - especially ones that are expected to work in multiple locales in multiple languages - take "input" from a lot of different places. Phrased differently, not all input comes from the user.
这里的教训是&＃xff0c;您的应用程序-尤其是那些有望在多种语言环境下以多种语言运行的应用程序-从许多不同的地方获取“输入”。 措辞不同&＃xff0c;并非所有输入都来自用户。
System locale and language, time, timezone, dates, are all input as ambient context to your application. Make sure you assert your assumptions about what "default" is. In this case, my little app worked great on en-US but not on "C.UTF-8." I was able to explore the behavior and learn that there was both a local workaround (I could detected and set a default locale if needed) and there was a library fix available as well.
系统语言环境和语言&＃xff0c;时间&＃xff0c;时区&＃xff0c;日期都作为环境上下文输入到您的应用程序中。 确保确定关于“默认”是什么的假设。 在这种情况下&＃xff0c;我的小应用程序在en-US上运行良好&＃xff0c;但在“ C.UTF-8”上却无法运行。 我能够探究此行为&＃xff0c;并了解到既有本地解决方法(可以检测并根据需要设置默认语言环境)&＃xff0c;也有可用的库修复程序。
Assert your assumptions!
确认您的假设&＃xff01;
翻译自: https://www.hanselman.com/blog/assert-your-assumptions-net-core-and-subtle-locale-issues-with-wsls-ubuntu
wsl - ubuntu
京公网安备 11010802041100号