Warn if settings.json is not UTF-8 (at least in key binding)

[KalleOlaviNiemitalo]

Description of the new feature/enhancement

If settings.json is encoded in e.g. Windows-1252 rather than UTF-8, then Terminal should warn about that, rather than silently substitute U+FFFD replacement characters in strings. This would help users who edit settings.json with Visual Studio, which saves in the ANSI code page by default if the file does not appear to be UTF-8 already. The silent substitution is especially hard to diagnose if the only non-ASCII character is in a key binding that then just does not work.

Proposed technical implementation details (optional)

Apply settings.json as much as possible, but then pop up a message saying that the encoding is wrong.

AFAICT, jsoncpp gives the raw bytes of JSON string values to Terminal if there is are no backslash escapes. These bytes are UTF-8 if the file was correctly encoded. In Terminal, ConversionTrait<KeyChord>::FromJson calls til::u8u16, which calls MultiByteToWideChar without the MB_ERR_INVALID_CHARS flag. There are more til::u8u16 calls in other ConversionTrait specializations.

terminal/src/cascadia/TerminalSettingsModel/KeyChordSerialization.cpp

Line 332 in 2531454

return _fromString(til::u8u16(keyChordText));

terminal/src/cascadia/TerminalSettingsModel/JsonUtils.h

Line 161 in 2531454

return til::u8u16(Detail::GetStringView(json));

terminal/src/inc/til/u8u16convert.h

Line 282 in 2531454

const int lengthOut = MultiByteToWideChar(gsl::narrow_cast<UINT>(CP_UTF8), 0ul, in.data(), lengthRequired, out.data(), lengthRequired);

[KalleOlaviNiemitalo]

It seems it would be much easier to throw an exception right away than save the error and keep processing the rest of the JSON tree. Wouldn't be much worse for the user, either.

[orcmid]

It seems it would be much easier to throw an exception right away than save the error and keep processing the rest of the JSON tree. Wouldn't be much worse for the user, either.

Yes, once it is not known exactly what the damage involves, stopping is better than continuing. A compromise (not unlike preprocessor/VC fails) is to count and quit when it is clear there is no simple continuation. But absent that, stopping and identifying the point of difficulty is appropriate, just like hitting an XML cliff. The error message should not be misleading - i.e., presume too much about the root cause.