microsoft/icu

Fork of https://github.com/unicode-org/icu for ICU4C, with changes needed for consumption inside various Microsoft products.

ICU (MS-ICU)

See the official International Components for Unicode site for an introduction to ICU.

This repository is a fork of the ICU project (specifically ICU4C) with changes. This fork is maintained by the Microsoft Global Foundations team.

The changes in this repository fall into the following broad categories:

• Maintenance related changes.
• Changes needed for consumption inside various Microsoft products.
• Additional locales from CLDR to improve parity with existing NLS locale support, and changes to address customer issues and feedback.

Before reporting any issues, or creating any pull-request(s), please ensure that your issue or change is related to one of the above reasons.

Any other issues, changes, bug fixes, improvements, enhancements, etc. should be made in the upstream project here:

• Upstream source: https://github.com/unicode-org/icu
• Upstream issues: https://unicode-org.atlassian.net/projects/ICU

Build Status

Contributing

👉 Note: Please make sure your change(s) cannot be made upstream first.

Most bug fixes, improvements, enhancements, etc. should be made in the upstream project here: https://github.com/unicode-org/icu

Otherwise, this project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

License

The contents of this repository are licensed under the terms described in the LICENSE file.

icu's Issues

Magic strings compare

Dear all,

when we enabled ICU for our applications, we had a problem with our CI (testhost.exe process was crashed). After deep investigation, we have found that it is not related to our software and problem could be reproduced with simple application.

Steps to reproduce:
add to project file

<ItemGroup>
  <PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="68.2.0.9" />
  <RuntimeHostConfigurationOption Include="System.Globalization.AppLocalIcu" Value="68.2.0.9" />
</ItemGroup>

and add to execution code

var locale = CultureInfo.InvariantCulture;
locale.CompareInfo.Compare("Table1", "NewDataSet1", CompareOptions.IgnoreCase | CompareOptions.IgnoreKanaType | CompareOptions.IgnoreWidth);

We are able to reproduce it not on all Windows systems. Even more for some machine it works before without issue and after some updates were installed it crashed now.

We have to created 2 simple application: WPF and Console, and it is reproducible on both of them.
Please find source code here:

• Console app source code: ConsoleStringIssue.zip
• WPF app source code WpfApp2.zip
• Console app crash dump: ConsoleStringIssue.exe_221118_140109.zip
• WPF app crash dump: WpfApp2.exe_221118_144018.dmp.zip

New version of Microsoft.ICU.ICU4C.Runtime

The latest version of Microsoft.ICU.ICU4C.Runtime is 68.2.0.9 https://www.nuget.org/packages/Microsoft.ICU.ICU4C.Runtime/68.2.0.9 last update (9/27/2021) but I see ICO new version is 73 https://icu.unicode.org/download/73. Is Microsoft.ICU.ICU4C.Runtime is still maintained or I am missing something?

Problem with Norway Culture

Problem:
The CultureInfo "nb" and "nn" have no parent.
new CultureInfo("nb").Parent / new CultureInfo("nn").Parent return InvariantCulture
Expected:
The CultureInfo "nb" and "nn" have parent "no" .

This is an icu issue and is already fix by following PRs.
unicode-org/cldr#1031
unicode-org/icu#1581

I see MS-ICU 72.1.0.3 contains CLDR 42 so this should be fixed if I use Microsoft.ICU.ICU4C.Runtime 72.1.0.3.
But the actual result is still not fixed.

I added

  <ItemGroup>
    <PackageReference Include="Microsoft.ICU.ICU4C.Runtime.win-x86" Version="72.1.0.3" />
    <RuntimeHostConfigurationOption Include="System.Globalization.AppLocalIcu" Value="72.1.0.3" />
  </ItemGroup>

into the csproj file.

Outdated release

Found an issue with en-AU cultulreinfo on win10 (dotnet/runtime#73837) porting a library from net 4.x to 6.x.
Current release is outdated (current version is ICU 71) and windows update seems to ignore new ICU releases.

An updated release of this package can fix the odd behavior of the linked issue.

TZ database version

This might be a duplicate of #120 but the entire library doesn't need to be updated in order to update timezone information, only the timezone resource files. I'm unsure how this is shipped so I could be incorrect on this.

I started creating a custom tzdb using libicu directly for use with date/tz, similar to how STL does it for std::chrono and ended up with a hard realization that the TZ database included with the version of libicu shipped on Windows is over 2 years out of date at this point, shipping with version 2021a of the IANA database.

So my question is straight forward, is this library meant to be used as a reliable TZ database for Windows?

• If not, could I be redirected on what the appropriate way to go about this on Windows is?
• If so, is it okay that the TZ data is 2 years out of date? If it's problematic, could I request the database be updated more regularly, even if the core libicu is not kept up-to-date with upstream?
• Am I even in the right place to request any of this? I feel like a lost child if I'm honest.

References:

• Raymond Chen appears to claim that the globalization team recommends not using Windows identifiers except for legacy cases.

Somewhat Related:

• HowardHinnant/date#771 (comment)

Why is 72.1.0.1 described as "internal implementation package" and fails at runtime?

I recently updated Microsoft.ICU.ICU4C.Runtime from 68.2.0.9 to 72.1.0.1, but my apps then started failing at startup:

Process terminated. Failed to load app-local ICU: icuuc68.2.0.9.dll
   at System.Environment.FailFast(System.String)
   <rest of stack trace omitted>

I checked the NuGet page, and see that the 72 version is described as internal and not for direct dependency:

This surprised me, because the previous version is described as "mature" and "widely used":

Did the nature of Microsoft.ICU.ICU4C.Runtime change? Are we supposed to just never upgrade from 68.2.0.9?

Windows cultures missing in ICU

Hi,
there is wast amount of cultures which are present on Windows 10 and are missing in ICU. What are your plans on getting these two list the same?

ICU 68

Hello,
Is there any plan to update to ICU 68 (was released a few weeks ago)
http://site.icu-project.org/download/68

Our dotnet/icu fork depends on microsoft/icu.

Pick up CLDR windows time zone mapping changes for South Sudan (Juba)

Thanks to Matt Johnson-Pint for filing the upstream CLDR ticket and creating a PR.

Upstream PR: unicode-org/cldr#1193
Upstream CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-14653

From the CLDR ticket:
Windows Update released 2021-03-29 added a new time zone "South Sudan Standard Time" which needs to be mapped to "Africa/Juba" in the windowsZones.xml file.

Once this is accepted and merged we should cherry-pick the change into MS-ICU.

Incorrect configurations of x86 and x64 arch

While using ICU.dll provide by windows, observed that internally x86 builds refer to the x64 icu.dll and vice versa. Is there any work around or fix for this ?

BinSkim: BA2008 : EnableControlFlowGuard

BinSkim (https://github.com/microsoft/binskim) with the Microsoft recommended ruleset flags the native ICU DLLs built as part of the NuGet packages with BA2008: EnableControlFlowGuard.

'icuin72.dll' does not enable the control flow guard (CFG) mitigation. To resolve this issue, pass /guard:cf on both the compiler and linker command lines. Binaries also require the /DYNAMICBASE linker option in order to enable CFG.
'icuuc72.dll' does not enable the control flow guard (CFG) mitigation. To resolve this issue, pass /guard:cf on both the compiler and linker command lines. Binaries also require the /DYNAMICBASE linker option in order to enable CFG.

Incompatibility Issue Between ICU 64 DLLs and ICU 68 Data Files

Description:
I've encountered an issue where the ICU (International Components for Unicode) DLLs from version 64 appear to be incompatible with the data files from ICU version 68. According to the documentation, these versions should be compatible. This incompatibility is causing problems in my application, as it relies on the interoperability of these components.

Steps to Reproduce:

Install ICU version 64 and integrate the DLLs into the application.
Upgrade the ICU data files to version 68.
Run the application and observe the compatibility issue.
Expected Behavior:
The ICU 64 DLLs should be compatible with the ICU 68 data files, allowing for smooth operation of the application.

I would appreciate any insights or solutions to resolve this compatibility issue. Thank you.

Windows and linux binaries have different version suffixes

We plan to use System.Globalization.AppLocalIcu with a framework dependent build. That means we can only define this switch once. But as the windows binaries just have the major version as a suffix (file names) and the linux ones have the full version as a suffix, we are not able to use System.Globalization.AppLocalIcu.

The linux release from https://github.com/unicode-org/icu/releases/tag/release-71-1 names the ".so" eg libicuuc.so.71

Any hints?