Feature | Use hardcoded LCID mappings when decoding strings

[edwardneal]

Description

This builds on #4051 and #584 by changing the mapping from collations/sort IDs to code pages, replacing it with a static list of valid mappings rather than a call to CultureInfo.GetCultureInfo.

This is performance-neutral, but it also brings us closer to supporting globalization invariant mode.

I've simply lifted the full set of mappings from the JDBC driver (here) and confirmed that the existing collation transcoding tests continue to pass on the newest SQL 2025 CU and on a SQL Azure instance.

Issues

Tested by #4051.
Addresses a backlog item listed in #584.
Contributes to #3742.

Testing

Manual testing against an on-prem SQL2025 instance and against a SQL Azure instance passes.

[mdaigle]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[benrr101]

In general, I like the idea. The only thing I would like changed is to give more labels to the magic values. Right now it looks like a book of mysterious numbers with no real explanation. They ultimately correspond with a locale of some kind, yeah? So it'd be nice to be able to see which values correspond to which locale.

[edwardneal]

Thanks @benrr101. Yes - it maps LCID (defined here) to code page IDs (except for LCIDs 0x827 and 0x2409, which don't appear in the specs or are marked as reserved, but still have an entry in the LCID table.)

The corresponding mapping here references the MS-LCID spec, which I can do. Many of the code pages are named Windows-1252 or similar though, so I'd be replacing a numeric value of 1252 with something like Windows_1252, which doesn't seem particularly helpful.

Do you just want the link to MS-LCID, or something more structural?