Bestätigen Sie Ihre Annahmen – .NET Core und subtile Gebietsschemaprobleme mit WSLs Ubuntu

Ich hielt dies für einen interessanten und subtilen Bug Verhalten, das nicht nur schwer aufzuspüren, sondern schwer zu fassen war. Ich war mir nicht sicher, 'wessen Schuld es war.'

Hier ist die Geschichte. Fühlen Sie sich frei, mitzumachen und zu sehen, was Sie bekommen.

Ich habe Ubuntu 18.04 unter WSL ausgeführt.

Ich habe eine Konsolen-App mit .NET Core 3.0 erstellt. Sie können .NET Core hier http://dot.net/get-core3

installieren

Ich habe dies getan:

dotnet new console
dotnet add package Humanizer --version 2.6.2

Dann sah Program.cs so aus. Humanizer ist eine großartige .NET Standard-Bibliothek, die Sie kennenlernen und denken werden:„Warum hatte .NET das nicht schon immer!?“

using System;
using Humanizer;

namespace dotnetlocaletest
{
    class Program
    {
        static void Main(string[] args)
        {
             Console.WriteLine(3501.ToWords()); 
        }
    }
}

Sie können sehen, dass ich möchte, dass die App die Nummer 3051 als Wörter ausdruckt. Vermutlich auf Englisch, da dies meine Hauptsprache ist, aber Sie werden feststellen, dass ich das hier nicht angegeben habe. Lass es laufen.

Beachten Sie, dass diese App unter Windows hervorragend und wie erwartet funktioniert.

scott@IRONHEART:~/dotnetlocaletest$ dotnet run
3501

Hm. Es hat es nicht einmal versucht. Das ist seltsam.

Mein Windows-Rechner ist en-us (Englisch in den USA), aber was ist mein Ubuntu-Rechner?

scott@IRONHEART:~/dotnetlocaletest$ locale
LANG=C.UTF-8
LANGUAGE=

Sieht aus, als wäre es nichts. Es ist "C.UTF-8" und es ist nichts. C bedeutet in diesem Zusammenhang die POSIX-Standardlokalisierung. Es ist das grundlegendste. C.UTF-8 ist definitiv NICHT dasselbe wie en_US.utf8. Es ist eine Art Ort, aber es ist kein Ort.

Was ist, wenn ich .NET explizit sage, wo ich bin?

static void Main(string[] args)
{
    Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
    Console.WriteLine(3501.ToWords()); 
}

Und es ausführen.

scott@IRONHEART:~/dotnetlocaletest$ dotnet run
three thousand five hundred and one

OK, die Dinge funktionieren also gut, wenn die App erklärt:"Hey, ich bin en-US!" und Humanizer funktioniert gut.

Was ist los? Anscheinend ist Ubuntus "C.UTF-8" nicht "invariant" genug, um Humanizer dazu zu bringen, auf eine englische Standardeinstellung zurückzugreifen?

Scheint, als hätten andere Leute ungewöhnliche oder subtile Probleme mit Ubuntu-Installationen gesehen, die C.UTF-8 im Vergleich zu einem spezifischeren Gebietsschema wie en-US.UTF8 verwenden.

Ich könnte das auf ein paar Arten beheben. Ich könnte das Gebietsschema speziell in Ubuntu festlegen:

locale-gen en_US.UTF-8
update-locale LANG=en_US.UTF-8

Glücklicherweise hat Humanizer 2.7.2 und höher dieses Problem behoben und fällt korrekt zurück. Wessen "Bug" war es? Schwierig, aber in diesem Fall hatte Humanizer eine fehlerhafte Fallback-Logik. Ich habe auf 2.7.2 aktualisiert und jetzt fällt C.UTF-8 auf ein neutrales Englisch zurück.

Abgesehen davon denke ich, dass man argumentieren könnte, dass WSL/Canonical/Ubuntu meine Landessprache erkennen und/oder bei der Installation das Gebietsschema darauf einstellen sollte.

Die Lehre hieraus ist, dass Ihre Anwendungen – insbesondere solche, die in mehreren Gebietsschemata und in mehreren Sprachen funktionieren sollen – „Eingaben“ von vielen verschiedenen Stellen erhalten. Anders ausgedrückt:Nicht alle Eingaben stammen vom Benutzer.

Gebietsschema und Sprache des Systems, Zeit, Zeitzone, Daten werden als Umgebungskontext in Ihre Anwendung eingegeben. Stellen Sie sicher, dass Sie Ihre Annahmen darüber geltend machen, was "Standard" ist. In diesem Fall funktionierte meine kleine App hervorragend auf en-US, aber nicht auf „C.UTF-8“. Ich konnte das Verhalten untersuchen und erfuhr, dass es sowohl eine lokale Problemumgehung (ich konnte bei Bedarf ein Standardgebietsschema erkennen und festlegen) als auch eine Bibliothekskorrektur gab.

Bestätigen Sie Ihre Vermutungen!

Sponsor: Leiden Sie unter einem Mangel an Klarheit in Bezug auf Softwarefehler? Bieten Sie Ihren Kunden mit der Fehlerüberwachung von Raygun.com die Erfahrung, die sie verdienen und erwarten. Lässt sich in wenigen Minuten installieren, probieren Sie es noch heute aus!