WideCharToMultiByteで「髙」から「0x7c62」を取得したい

Question

char taka[100];
WideCharToMultiByte(50221, 0, L"髙", -1, taka, 100, NULL, NULL);

Windowsで、上のルーチンで「髙」をJISコードに変換すると、
「1b 24 28 44 74 29 1b 28 42 00」というバイト列になりました。

「1b 24 28 44」はJIS X 0212、「1b 28 42」はアスキー文字のエスケープ文字で、
途中の「74 29」というバイト列が「髙」を表すものだと理解しました。
ところが、テキストエディタなどでこの文字のJISコードを表示させると、0x7c62となります。

「髙」が本来JISコードにないことは理解しているのですが、
この0x7429というバイト列はどういう意味で、なぜ0x7c62にならないのでしょうか？

Comments

[yambejp]

JISだと「1B 24 42 7C 62 1B 28 42」では？

[n_ito]

コメントありがとうございます。
JIS X 0212を表すエスケープ文字が入ってくるのがおかしいのではとも思うのですが、
上に書いたようにWideCharToMultiByteを使うと、そのようなバイト列になるようです。
「1B 24 42 7C 62 1B 28 42」が返ってくるような指定方法があるのでしょうか。

[can110]

以下試した結果を記載ください。

- 引数lpDefaultChar, lpUsedDefaultCharも指定
- 戻り値も取得し0ならGetLastErrorでエラーコードを取得

おそらくERROR_INVALID_PARAMETERで変換失敗すると思います。

[dameo]

まず、
https://learn.microsoft.com/ja-jp/windows/win32/intl/code-page-identifiers
より50221はcsISO2022JPのことであり、所謂JISコードの派生であることが分かります。
Microsoftからはこれ以上の情報の提供がありません。

他方所謂JISコード(ISO-2022-JP)には以下から
https://ja.wikipedia.org/wiki/ISO-2022-JP
いくつかの派生があることが分かっています。

ISO-2022を知ると分かりますが、そのサブセットでエスケープシーケンスが被ったりしません。
「1b 24 28 44」はRFC2237
https://datatracker.ietf.org/doc/html/rfc2237
によると、JIS X 0212-1990とのことなので、JIS X 0212は確定だと思います。

そして「74 29」は0x20ずつ引いて区点にすると84区9点となり、
https://www.asahi-net.or.jp/~ax2s-kmtn/ref/jisx0212/index.html
によるとJIS X 0212に存在しないことになります(JISでpdfを見てもいいのですが、ユーザー登録したくないので私は見てません)。ユーザー登録してPDFを見てもいい人は見て確認すれば何か分かるかもしれませんね。

[can110]

> ところが、テキストエディタなどでこの文字のJISコードを表示させると、0x7c62となります。
そのエディタでJISで保存したファイルをバイナリエディタで開き、バイトコードを確認してください。
たぶん「1B 24 42 7C 62 1B 28 42」になっていると思いますが。
あとは以下などを参考に、いろいろ調べてみてください。
https://sakura-editor.github.io/help/HLP000271.html

[n_ito]

> - 引数lpDefaultChar, lpUsedDefaultCharも指定
> - 戻り値も取得し0ならGetLastErrorでエラーコードを取得

コメントありがとうございます。
lpDefaultCharとlpUsedDefaultCharをNULLのまま、戻り値を確認してみたところ、
WideCharToMultiByteの戻り値は10で、成功扱いになっているようです。

ちなみに、lpDefaultCharとlpUsedDefaultCharを指定してみようとしたのですが、

BOOL bUsedDefaultChar = FALSE;
int result = WideCharToMultiByte(50222, 0, L"髙", -1, taka, 100, "?", &bUsedDefaultChar);

と書いてみても、GetLastErrorの値は87(パラメータが不正)となってしまいます。
「髙」の代わりに「高」などの文字を入れてみても同じです。
指定の仕方が間違っているのでしょうか。

[n_ito]

> dameoさん
> そして「74 29」は0x20ずつ引いて区点にすると84区9点となり、
> https://www.asahi-net.or.jp/~ax2s-kmtn/ref/jisx0212/index.html
> によるとJIS X 0212に存在しないことになります

> can110さん
> そのエディタでJISで保存したファイルをバイナリエディタで開き、バイトコードを確認してください。
> たぶん「1B 24 42 7C 62 1B 28 42」になっていると思いますが。

お二方コメントありがとうございます。
テキストエディタで「髙」だけを打ち込んで、JISとして保存し、
バイナリエディタで見てみたところ、「1B 24 42 7C 62 1B 28 42」となっていました。

となると、WideCharToMultiByteが正しい動作をしていないということになるのでしょうか？
その場合、任意の文字列をJISコードに変換するには、他にどういう方法がありますでしょうか？

[dameo]

> WideCharToMultiByteが正しい動作をしていないということになるのでしょうか？

いいえ

[maisumakun]

> テキストエディタなどでこの文字のJISコードを表示させると、0x7c62となります。

・どのようなエディタで、どんな文字コードで記載したうえで、どんな方法を用いて確認を行いましたか？

[n_ito]

> どのようなエディタで、どんな文字コードで記載したうえで、どんな方法を用いて確認を行いましたか？

秀丸エディタに「髙」の文字を貼り付けて、「文字コード表示」のダイアログで確認したところ、

JIS: 0x7C62

と表示されました。
また、JIS形式で保存してから開き直しても、同じ文字コードになっていることも確認しました。

[maisumakun]

では、「0x7c62のほうが正しい」と考える根拠は何でしょうか？

[n_ito]

> では、「0x7c62のほうが正しい」と考える根拠は何でしょうか？

0x7c62で調べるとそれなりに情報が出てきて、ファイルにもそのように保存されるのに、
0x7429だとなにも情報が出てこないので、WideCharToMultiByteで返ってくる0x7429はどういう意味なんだと疑問に思いました。

[tmp]

「髙」(U+9AD9)の該当しそうなSJISコードが２つあるのですね。JISコードの割り当てはないと書いてありましたが
２つのSJISコードEEE0とFBFC
EEE0の方は、NEC選定IBM拡張文字って書いてありましたが、EEE0は単純計算するとJISコード7C62になりますが、FBFCの方は、EFを超えているので計算できない。
EEE0は、恐らくNEC選定IBM拡張文字って書いてるから特殊な方なのでしょうか
エディター(内部がUNICODEのエディタ）で、SJISで保存するとFBFCのコードになります。

[dameo]

SJISコードでJIS X 208の区点を計算する方法はありますが、JIS X 212はありません。
質問者(と回答者)がISO-2022を理解してからでないと話が出来ないと思いますよ。

Answer 1

Windows 11、Visual Studio 2022で確認しました。

確かにWideCharToMultiByteでは、50220,50221,50222のいずれを指定しても、「髙」は0x7429を返しますね。
これが何故なのか私も知りたいです(と言ったら私も怒られるのかな)。

参考までに、サクラエディタ(GitHubでソース公開しています)では、以下のような処理により0x7C62を返しています。
(「髙」に関係する処理だけを抜き出して、単純化しています)

#include <iostream>
#include <windows.h>
#include <mbstring.h>

int main()
{
    const char JISESCDATA_JISX0208_1983[] = {0x1B, 0x24, 0x42};
    const char JISESCDATA_ASCII7[] = {0x1B, 0x28, 0x42};

    char *pDst = new char[8];
    char taka[100];

    // UTF-16(0x9AD9)からShift_JIS(IBM拡張文字、0xFBFC)
    WideCharToMultiByte(932, 0, L"髙", -1, taka, 100, nullptr, nullptr);

    // 2区と13区の調整(「髙」は対象外)

    // IBM拡張文字からNEC選定IBM拡張文字(0xEEE0)
    unsigned int c = ((taka[0] << 8) & 0x0000FF00) + (taka[1] & 0x000000FF);
    // 「髙」が含まれるFB9C～FBFC→EE80～EEE0の場合
    c -= 0x0D1C;

    // NEC選定IBM拡張文字からJIS(0x7C62)
    c = _mbcjmstojis_l(c, _create_locale(LC_ALL, "Japanese_Japan.932"));

    // エスケープシーケンスと連結
    memcpy(pDst, JISESCDATA_JISX0208_1983, 3);
    pDst[3] = static_cast<char>((c & 0x0000FF00) >> 8);
    pDst[4] = static_cast<char>(c & 0x000000FF);
    memcpy(&pDst[5], JISESCDATA_ASCII7, 3);

    // pDstに変換結果が入っている(0x1B 24 42 7C 62 1B 28 42)

    delete[] pDst;
}

(追記)
dameoさんの指摘により、上記ソースの参照元を追記します。
https://github.com/sakura-editor/sakura

処理内容	ソース	関数
UTF-16からIBM拡張文字	sakura_core\charset\codeutil.h	MyWideCharToMultiByte_JP
2区と13区の調整	sakura_core\charset\codeutil.cpp	SjisFilter_basis
IBM拡張文字からNEC選定IBM拡張文字	sakura_core\charset\codeutil.cpp	SjisFilter_ibm2nec
NEC選定IBM拡張文字からJIS	sakura_core\charset\codeutil.cpp	_mbcjmstojis_j
エスケープシーケンスと連結	sakura_core\charset\CJis.cpp	CJis::UniToJis

(追記・その2)
JISCに登録して「JIS X 0212-1990」規格書を見ましたが、「髙」に関する記載はありませんでした。
あとは、WideCharToMultiByte APIのソースを見るしかないですね。

(追記・その3)
FreeBSD 13.2、iconvコマンド

パラメーター	髙
CP50220	0x1B 24 42 7C 62 1B 28 42
CP50221	0x1B 24 42 7C 62 1B 28 42
CP50222	0x1B 24 42 7C 62 1B 28 42
ISO-2022-JP-1	warning: invalid characters: 1
ISO-2022-JP-2	warning: invalid characters: 1
ISO-2022-JP	warning: invalid characters: 1
JISX0208:1990	不正なバイト列です

Ubuntu 22.04.3、iconvコマンド

パラメーター	髙
CSISO2022JP	illegal input sequence at position 0
CSISO2022JP2	illegal input sequence at position 0
ISO-2022-JP-2	illegal input sequence at position 0
ISO-2022-JP-3	illegal input sequence at position 0
ISO-2022-JP	illegal input sequence at position 0
ISO2022JP	illegal input sequence at position 0
ISO2022JP2	illegal input sequence at position 0

FreeBSD 13.2、PHP 8.1.27
Ubuntu 22.04.3、PHP 8.1.2
mb_convert_encoding関数(2環境とも結果は同じ)

パラメーター	髙
CP50220	0x1B 24 42 7C 62 1B 28 42
CP50220raw	0x1B 24 42 7C 62 1B 28 42
CP50221	0x1B 24 42 7C 62 1B 28 42
CP50222	0x1B 24 42 7C 62 1B 28 42
ISO-2022-JP	0x3F
ISO-2022-JP-MS	0x1B 24 42 7C 62 1B 28 42
JIS	0x3F
JIS-ms	0x1B 24 42 7C 62 1B 28 42

※0x3FはUS-ASCIIで「?」

私の結論としては、WideCharToMultiByteに50220,50221,50222を指定して0x7429を返す動作は変だと思います。0x7C62が正しい。

Comments

[dameo]

ISO-2022の仕様を確認しましょう。JIS X 208を使って変換するコードを見ても理解はできないでしょう。

[dameo]

あとライセンスもあるものなので、コードを調べた結果を出すときはきちんと参照元を提示しないとまずいかもしれません。
未確認ですが、多分↓ではないですか？
https://github.com/sakura-editor/sakura/blob/v2.4.2/sakura_core/charset/CJis.cpp#L357-L461

[n_ito]

> 私の結論としては、WideCharToMultiByteに50220,50221,50222を指定して0x7429を返す動作は変だと思います。0x7C62が正しい。

hiroki-oさん、詳しい解説ありがとうございます。
また、現象を確認していだたきありがとうございます。

この「1b 24 28 44 74 29 1b 28 42 00」というバイト列をMultiByteToWideCharに渡すと
ちゃんと「髙」に戻るので、0x7429はどこかで定義されているのかとも思ったのですが、
ネット上で探しても見つからないので、この値をそのまま使っていいのか困っていました。

サクラエディタのコードも非常に参考になります。
WideCharToMultiByteの結果である0x7429の値を信じないとなると、
いろいろ自力で変換する必要が出てくるのですね。

[dameo]

ベストアンサーで初めて通知があったので、今修正に気付きました。

まるで間違っていますよ。
正しい正しくないだけで言えば、もしISO-2022-JPであれば0x7C62はJIS X 208なら範囲外なので全く正しくありません。

> (追記)
> dameoさんの指摘により、上記ソースの参照元を追記します。
> https://github.com/sakura-editor/sakura
十分ではありません。私が示したようにきちんとリビジョンとコード範囲を指定しましょう。

> JISCに登録して「JIS X 0212-1990」規格書を見ましたが、「髙」に関する記載はありませんでした。
JIS X 208にもないと思いますよ。
ついでに言えば213にも。

> FreeBSD 13.2、iconvコマンド
CP50220～2の結果については、きちんとissueでもあげるべきですね。
iconvのバージョンわかりませんが、MSに合わせない理由がないので。Ubuntuなどの結果を見る限り、多分間違ったエイリアスが切られているのだと思います。

PHPも同様だと思います。
0x7C62が正しいとかではなく、JIS X 208を使っているのが不適切です。
誰もコードページ5022Xについては誰もコードポイントを規定しておらず、MSしか使っていないのですから、それに合わせる以外の選択肢はありません。
(MSから出てそうなのはISO-2022-JP-1という仕様だけですが、これでも212を使うこと以外、細かい規定はありません。他はIANAの名前登録くらいです。)

213を使用するISO-2022-JP-3については、IANAの登録すらありません。

サクラエディタのコード変換は_mbcjmstojis_lを使いたいがために、わざわざIBM拡張文字からNEC選定IBM拡張文字に変換をかけるほどのものであり、ロケール指定まで使っておいてわざわざCP5022Xを使わない理由が分からないくらいです。

ただ、何度も言いますが、まずはなぜJIS X 208に固執して、合ってるだの間違ってるだの言うのでしょう？
CP50220を規定したMSが、エスケープシーケンスでJIS X 212を使っているのに、わざわざJIS X 208を使う理由は何でしょう？

所謂JISコードが昔からMSだけ違う使い方をしていて(髙とか①なんてそもそもJISじゃ使いません)、それはShift_JISとMS932(現CP932)/Windows-31Jが同じようで違っているのと同じことですよ。

[dameo]

一応追記しておくと、ISO-2022-JP-1はJIS X 208も普通に使っています。
JIS X 212は補助漢字という位置づけなので。
なので、私はUnicode→JISしかしてないのでチェックしていませんが、おそらくMicrosoftは50220→Unicode時、JIS X 208もちゃんと変換してると思いますよ。

(追記)ここは別の外字扱いで髙には変換してくれませんでしたね。ちょっと確認した結果を貼っておきます。
#include <windows.h>
#include <cstdio>
#include <clocale>
int main() {
using namespace std;
setlocale(LC_CTYPE, "");
char taka_208[] = {"\x1B\x24\x42\x7C\x62\x1b(B"};
wchar_t wch[100];
auto len = MultiByteToWideChar(50220, 0, taka_208, sizeof(taka_208)/sizeof(taka_208[0]), wch, sizeof(wch) / sizeof(wch[0]));
printf("converted %d chars.\n", len);
if (len > 0) {
wprintf(L"converted -> %lc(0x%04x)", wch[0], wch[0]);
} else {
printf("error: 0x%08X\n", GetLastError());
}
return 0;
}
// converted 2 chars.
// converted -> (0xe2d3)

あと、前に少し触れましたが、シフトJIS2バイト文字<->JIS X 208コードポイントは割と簡単な計算式で変換できます。版によって若干の入れ替えがある程度です。

[tmp]

hiroki-oさん、調べたものまとめ、大変参考になります。（無償だし面倒だから結論だけが多い中）
しかし、0x7429は、どこからきたのでしょうかね。EUC-JPに変換するとF429になってました。

[dameo]

私のコードはそこに回答してるものですよ。
何度も言っていますが、ISO-2022をきちんと知ってください。

[dameo]

一応iconvについて調べてみました。Ubuntu 22.04のものは私の環境だとglibc2.35に付属するiconv実装でした。コードでいうとこの辺です(マイナーバージョンは適当)。
https://elixir.bootlin.com/glibc/glibc-2.35.9000/source/iconvdata/iso-2022-jp.c

freebsdはcitrusプロジェクトのiconv実装を使っており、
http://citrus.bsdclub.org/
コードはこの辺
https://cgit.freebsd.org/src/tree/lib/libiconv_modules/ISO2022/citrus_iso2022.c?h=stable/13

古い上に実績の少ないBSD系の実装を元に何かを言っても仕方ないので、本家libiconv現行最新

https://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.17.tar.gz

をビルドしてubuntuで動かしてみました。(./configure;makeしただけ)

$ ./iconv_no_i18n --version
iconv (GNU libiconv 1.17)
Copyright (C) 2000-2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.
$ echo '髙' | ./iconv_no_i18n -f UTF-8 -t CP50221 | hexdump -C
00000000 1b 24 28 44 74 29 1b 28 42 0a |.$(Dt).(B.|
0000000a
$

当たり前の結果が普通に返ってきましたよ。

[hiroki-o]

tmpさん
IBM拡張文字から30個くらい選んで、WideCharToMultiByteで50221と20932(EUC-JP)の変換結果を比較したところ、差分が0x8000,0x8080のどちらかでした。何か関係がありそうです。
ちなみに、サクラエディタのEUC変換結果とは異なりました。

[dameo]

EUC-JPも正しいISO-2022の派生ですよ。
何度も言っていますが、きちんとコードを提示するか、場所とリビジョンと範囲含めて示すかして、他の人が再現できるようにしないと意味がありません。

一応「髙」だけやってみました。
#include <windows.h>
#include <cstdio>
#include <clocale>
int main() {
using namespace std;
setlocale(LC_CTYPE, "");
wchar_t wtaka[] = {L"髙"};
char ch[100];
UINT cps[] = { 20932, 51932 };
DWORD flags[] = { 0, WC_ERR_INVALID_CHARS };
for (size_t icps = 0; icps < sizeof(cps) / sizeof(cps[0]); ++icps) {
for (size_t iflags = 0; iflags < sizeof(flags) / sizeof(flags[0]); ++iflags) {
printf("[codepage=%d, flags=%d]\n", cps[icps], flags[iflags]);
auto len = WideCharToMultiByte(cps[icps], flags[iflags], wtaka, sizeof(wtaka) / sizeof(wtaka[0]), ch, sizeof(ch) / sizeof(ch[0]), NULL, NULL);
printf("converted %d chars.\n", len);
if (len > 0) {
printf("converted -> %s(", ch);
for (decltype(len) i = 0; i < len; ++i) printf("%02hhx", ch[i]);
printf(")\n");
}
else {
printf("error: 0x%08X\n", GetLastError());
}
}
}
return 0;
}
//[codepage = 20932, flags = 0]
//converted 3 chars.
//converted->・(f42900)
//[codepage = 20932, flags = 128]
//converted 0 chars.
//error: 0x000003EC
//[codepage = 51932, flags = 0]
//converted 0 chars.
//error : 0x00000057
//[codepage = 51932, flags = 128]
//converted 0 chars.
//error : 0x00000057

コードページが51932もEUCだったので、とりあえずやってみたのですが、51932は今は亡きIEの付属DLLであるmlang.dllにあるConvertINetUnicodeToMultiByte()で使用される幻のコードページだったので使えませんでした。ただし、結果を見て分かるとおり、20932では正しいISO-2022出力になっていない(JIS X212を置いてある場所の指示がなく、2バイト目をGRにしていない)ので、20932を使うなら正しい範囲(機種依存文字を使用せず、JIS X212/213も使用しないEUC-JP)であることを事前に使う側が保証する必要がありそうです。

巷の噂では51932がWindowsのコードページにおける使えるEUC-JPだった「ようです」。昨今EUC-JPは見る影もないので、IE消滅時に別の手段で51932を使えるようにしなかったのではないかと個人的に「推測しています」。つまり一言で言えば今日のWindowsで、無条件にEUC-JPを扱える(本格使用できる)コードページはない、ということです。そして51932(以下から推測)を再現するiconv上の名前もチラ見した限りではありませんでした。

https://ja.wikipedia.org/wiki/EUC-JP
https://ja.wikipedia.org/wiki/Extended_Unix_Code
https://en.wikipedia.org/wiki/Extended_Unix_Code

[dameo]

mlang.dllを使って「髙」を変換してみました。

#include <iostream>
#include <iomanip>
#include <windows.h>
#include <Mlang.h>
int main() {
HMODULE h = LoadLibrary(TEXT("mlang.dll"));
if (!h)
return 1;
typedef HRESULT(WINAPI* CONVERTINETUNICODETOMULTIBYTE)(
LPDWORD lpdwMode,
DWORD dwEncoding,
LPCWSTR lpSrcStr,
LPINT lpnWideCharCount,
LPSTR lpDstStr,
LPINT lpnMultiCharCount
);
auto ConvertINetUnicodeToMultiByte = (CONVERTINETUNICODETOMULTIBYTE)GetProcAddress(h, "ConvertINetUnicodeToMultiByte");
DWORD mode = 0;
char ch[100];
int cps[] = { 51932, 50221 };
for (size_t icps = 0; icps < sizeof(cps)/sizeof(cps[0]); ++icps) {
using namespace std;
cout << "[codepage=" << cps[icps] << "]" << endl;
INT len = sizeof(ch) / sizeof(ch[0]);
ConvertINetUnicodeToMultiByte(&mode, cps[icps], L"髙", NULL, ch, &len);
for (decltype(len) i = 0; i < len; ++i) {
cout
<< hex << setw(2) << setfill('0')
<< static_cast<uint32_t>(static_cast<uint8_t>(ch[i]))
<< dec
<< " ";
}
cout << endl;
}
FreeLibrary(h);
}
//[codepage = 51932]
//fc e2
//[codepage = 50221]
//1b 24 42 7c 62 1b 28 42

ただし以下の関数には厳しい但し書きがついています。
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa741107(v=vs.85)
> [ConvertINetUnicodeToMultiByte is available for use in the operating systems specified in the
> Requirements section. It may be altered or unavailable in subsequent versions. Instead, use
> MultiByteToWideChar or WideCharToMultiByte. ]

※public domainですが、↓のコードを参考にしています。
https://github.com/win-iconv/win-iconv/blob/v0.0.8/win_iconv.c

Answer 2

回答ではありません。

なんか質問者から中途半端な返事と結果だけ聞く質問が多く、これを見たらと言っても調べてる気配すらなく、話が進みそうにないので、とりあえず調査用のコードを貼っておきます。

#include <iostream>
#include <string>
#include <map>
#include <vector>
#include <iomanip>
#include <windows.h>
auto create_sjis2ws() {
    std::map<std::string, std::wstring> sjis2ws;
    char ch[3];
    ch[1] = 0;
    ch[2] = 0;
    for (ch[0] = 0x20; ch[0] != 0; ++ch[0]) {
        wchar_t wch[3];
        int len = MultiByteToWideChar(932, MB_ERR_INVALID_CHARS, ch, 1, wch, sizeof(wch) / sizeof(wch[0]));
        if (len == 1) {
            sjis2ws[std::string(ch)] = std::wstring(1, wch[0]);
        }
        else {
            for (ch[1] = 0x20; ch[1] != 0; ++ch[1]) {
                int len = MultiByteToWideChar(932, MB_ERR_INVALID_CHARS, ch, 2, wch, sizeof(wch) / sizeof(wch[0]));
                if (len == 1) {
                    sjis2ws[std::string(ch)] = std::wstring(1, wch[0]);
                }
            }

        }
    }
    return sjis2ws;
}
template<typename K, typename V>
auto create_ws2sjis(const std::map<K,V>& sjis2ws) {
    std::map<std::wstring, std::vector<std::string>> ws2sjis;
    for (const auto& sjis2ws_pair : sjis2ws) {
        const auto& sjis = sjis2ws_pair.first;
        const auto& ws = sjis2ws_pair.second;
        auto it = ws2sjis.find(ws);
        if (it == ws2sjis.end()) {
            it = ws2sjis.insert(std::make_pair(ws, std::vector<std::string>())).first;
        }
        it->second.push_back(sjis);
    }
    return ws2sjis;
}
const struct sequence_type {
    std::string escapes;
    std::string name;
    int char_length;
} seq_type[] = {
    {"\x1b(B", "ASCII", 1},
    {"\x1b(J", "JIS X 0201-1976", 1},
    {"\x1b$@", "JIS X 0208-1978", 2},
    {"\x1b$B", "JIS X 0208-1990", 2},
    {"\x1b$(D", "JIS X 0212-1990", 2},
    {"\x1b$A", "GB 2312-80", 2},
    {"\x1b$(C", "KS X 1001-1992", 2},
    {"\x1b.A", "ISO/IEC 8859-1(high)", 1},
    {"\x1b.F", "ISO/IEC 8859-7(high)", 1},
    {"\x1b$(O", "JIS X 0213:2000(1)", 2},
    {"\x1b$(P", "JIS X 0213:2000(2)", 2},
    {"\x1b$(Q", "JIS X 0213:2004(1)", 2},
    {"\x1b(I", "JIS X 0201(kana)", 1},
    //{"\x1b$(?", "JIS X 0208-1990(gaiji)", 2},
};
template<typename T>
auto create_jis2ws(const T& ws2sjis) {
    std::map<std::pair<std::string, std::string>, std::wstring> jis2ws;
    for (const auto& ws2sjis_pair : ws2sjis) {
        const auto& ws = ws2sjis_pair.first;
        char jis[100];
        auto len = WideCharToMultiByte(50221, 0, ws.c_str(), static_cast<int>(ws.length()), jis, sizeof(jis) / sizeof(jis[0]), NULL, NULL);
        if (len <= 0 || (jis[0] == '?' && ws[0] != L'?')) continue;
        std::string jisstr(jis, len);
        const sequence_type* pst = &seq_type[0];
        for (const auto& st : seq_type) {
            const auto& esc = st.escapes;
            if (jisstr.substr(0, esc.length()) == esc) {
                pst = &st;
                jisstr = jisstr.substr(esc.length(), st.char_length);
                break;
            }
        }
        jis2ws[std::make_pair(pst->name, jisstr)] = ws;
    }
    return jis2ws;
}
template<typename JIS, typename WS, typename SJIS>
void print_JISX0212_1990(const std::map<JIS,WS>& jis2ws, const std::map<WS, SJIS>& ws2sjis) {
    std::cout << "<pre>" << std::endl;
    for (const auto& jis2ws_pair : jis2ws) {
        const auto& jis = jis2ws_pair.first;
        const auto& ws = jis2ws_pair.second;
        if (jis.first == "JIS X 0212-1990") {
            std::wcout << jis2ws_pair.second;
            std::cout << ":Unicode(BMP)("
                << std::hex
                << std::setw(4) << std::setfill('0') << static_cast<int>(ws[0])
                << std::dec
                << ")";
            std::cout
                << ": ISO-2022-JP-2(" << jis.first << ")"
                << "(";
            for (auto ch : jis.second) {
                std::cout
                    << std::hex
                    << std::setw(2) << std::setfill('0')
                    << static_cast<int>(ch)
                    << std::dec;
            }
            std::cout
                << "): Windows_31J";
            std::cout
                << std::hex;
            for (const auto& s : ws2sjis.at(ws)) {
                std::cout << "(" << std::hex;
                for (auto ch : s) {
                    std::cout << std::setw(2) << std::setfill('0') << static_cast<int>(static_cast<unsigned char>(ch));
                }
                std::cout << std::dec << ")";
            }
            std::cout
                << std::endl;
        }
    }
}
int main(int argc, char* argv[])
{
    auto r = setlocale(LC_CTYPE, argc > 1 ? argv[1] : "");
    if (r == nullptr) {
        std::cerr << "invalid locale!" << std::endl;
        return 1;
    }
    auto sjis2ws = create_sjis2ws();
    auto ws2sjis = create_ws2sjis(sjis2ws);
    auto jis2ws = create_jis2ws(ws2sjis);
    print_JISX0212_1990(jis2ws, ws2sjis);
    return 0;
}

C:\>hoge.exe .UTF-8 >hoge.html
C:\>hoge.html