StringTools Encode/Decode methods now recognize the "WebCharset" keywords from the MIME types list in the registry (e.g. "shift_jis" is the web charset name for "iso-2022-jp").
But unfortunately, shift_jis and iso-2022-jp are related, but not the same encoding.
I checked this DOpus treats iso-2022-jp as shift_jis, by using Ad-Hoc Script Editor and python.
JScript on DOpus:
var stringTools = DOpus.Create().StringTools();
DOpus.Output(stringTools.Encode(stringTools.Encode("ใในใ", "iso-2022-jp"), "base64"))
Personally, I'm using this table for a handy alias reference.
This table treats shift_jis and cp932 as not the same encoding, and they're a bit different technically, but you can ignore and treat cp932 as shift_jis if you can't handle them differently.
Opus maps the string you give it to a codepage via the registry. Based on that, both iso-2022-jp and shift_jis map to codepage 932. The string conversion is done using the underlying codepage so there isn't really anything else shift_jis could be mapped to. Maybe it's technically incorrect (I'm not an expert on this) but you'd need to talk to Microsoft about creating a new codepage to fix it.
Also, I enumerated BodyCharset values for all code pages and found that some BodyCharsets are repeated. So I concluded that you should not believe that BodyCharset is an alias for codepage.
codepage
.NET Name
BodyCharset
remarks by me
708
ASMO-708
ASMO-708
720
DOS-720
DOS-720
852
ibm850
ibm852
862
DOS-862
DOS-862
866
cp866
cp866
874
windows-874
windows-874
932
shift_jis
iso-2022-jp
This codepage isn't compatible with iso-2022-jp
936
gb2312
gb2312
949
ks_c_5601-1987
euc-kr
might be compatible, but euc-kr defined as 51949
950
big5
big5
1200
utf-16
unicode
(idk; might be related)
1201
unicodeFFFE
unicodeFFFE
1250
windows-1250
iso-8859-2
might be related, but iso-8859-2 defined as 28592
1251
windows-1251
koi8-r
might be related, but koi8-r defined as 20866
1252
windows-1252
iso-8859-1
might be related, but iso-8859-1 defined as 28591
1253
windows-1253
iso-8859-7
might be related, but iso-8859-7 defined as 28597
1254
windows-1254
iso-8859-9
might be related, but iso-8859-9 defined as 28599
1255
windows-1255
iso-8859-8-i
might be related, but iso-8859-8-i defined as 38598
1256
windows-1256
iso-8859-6
might be related, but iso-8859-6 defined as 28596
1257
windows-1257
iso-8859-4
might be related, but iso-8859-4 defined as 28594
1258
windows-1258
windows-1258
20866
koi8-r
koi8-r
This should be real koi8-r instead of 1251
21866
koi8-u
koi8-ru
(idk; might be related)
28592
iso-8859-2
iso-8859-2
This should be real iso-8859-2 instead of 1250
28593
iso-8859-3
iso-8859-3
28594
iso-8859-4
iso-8859-4
This should be real iso-8859-4 instead of 1257
28595
iso-8859-5
iso-8859-5
28596
iso-8859-6
iso-8859-6
This should be real iso-8859-6 instead of 1256
28597
iso-8859-7
iso-8859-7
This should be real iso-8859-7 instead of 1253
28598
iso-8859-8
iso-8859-8
38598
iso-8859-8-i
iso-8859-8-i
This should be real iso-8859-8-i instead of 1255
50000
x-user-defined
(unknown)
50001
_autodetect_all
(unknown)
50220
iso-2022-jp
iso-2022-jp
This should be real iso-2022-jp instead of 932
50221
_iso-2022-jp$ESC
(idk; related to 50220)
50222
_iso-2022-jp$SIO
(idk; related to 50220)
50225
iso-2022-kr
iso-2022-kr
50932
_autodetect
(unknown)
50949
_autodetect_kr
(unknown)
51932
euc-jp
euc-jp
51949
euc-kr
euc-kr
I think that this shuld be real euc-kr instead of 949
The best thing to do is to use the codepage directly. The lookup Opus does is provided as a convenience, at the end of the day the cp is what's used to do the conversion.
I have now found that you should use HKCR\MIME\Database\Charset\[CHARSET NAME] for codepage lookups. It has a unique codepage definition for each charset. But InternetEncoding seems to be the right value name for that instead of Codepage if that key has it.
I decided to keep using code page personally, but I don't want you to keep wrong aliasing. I want to prevent another script developer from relying on that. They might publish the script with a user-customizable charset ... for example, sending an email? ... with that. And the script developer will be confused by that user's bug report.