wchar_t
データ型[1] wchar_t ‐ 通信用語の基礎知識, https://www.wdic.org/w/TECH/wchar_t
[2] ワイド文字 - Wikipedia, , https://ja.wikipedia.org/wiki/%E3%83%AF%E3%82%A4%E3%83%89%E6%96%87%E5%AD%97
wchar_t
符号化文字集合[6]
wchar_t
における符号と文字の対応関係は実装依存です。
[7] 次のようなものがあります。
[13] ISO 2022 wchar_t encoding, Markus Kuhn, created 2001-06-16 – last modified 2001-06-26, , https://www.cl.cam.ac.uk/~mgk25/ucs/iso2022-wc.html
[14] 21世紀初頭の Unicode への移行が徐々に始まった時代に提案されたもの。 著者は Unicode推進、アンチ ISO/IEC 2022 で当時有名 (悪名?) だった人。
[15] 題名に ISO 2022 と書いてあるが、 ISO/IEC 2022 とはあまり関係ない。 当時の東アジア (主に日本) では ISO/IEC 2022 の符号化文字集合の違いがフォントの選択 (によって誤魔化されていた漢字統合の問題) や文字幅 (半角 vs 全角) の決定に影響していたので、 ISO/IEC 2022 を捨てて Unicode に移行させるためには ISO/IEC 2022 における指示シーケンスの情報を Unicode文字に付与すればいいのでは、という誤解に基づき設計されている.
[16]
ISO 2022 wchar_t encoding では
ISO/IEC 10646 の U+0000
- U-07FFFFFF
はそのまま使える。
(U-08000000
- U-7FFFFFFF
は表現不能。)
それに加えて、
ISO/IEC 10646 の U+0000
- U+3FFFFF
は、
上位数ビットに特定の値を加えた形でも使える。
[17] その特定の値が、 ISO/IEC 2022 における符号化図形文字集合の指示シーケンスの中間バイトや終端バイトである。 従って元が JIS X 0208 だったか GB 2312 だったか ISO/IEC 8859 だったか区別できる、 という仕組み。
[18] あくまで往復変換のために元の符号化文字集合が何だったか記録するだけで、 下位ビットは相当する Unicode の文字に置き換えないといけない。 従って当時まだ多かった Unicode 嫌悪派の受けが良いはずがないし、 ISO/IEC 2022 との相互変換時の Unicode 文字との変換表が必要なことはただの Unicode への変換と変わらないし (その点が固定長EUCのようなものとは違う)、 その変換表が実装によって違うことに起因する相互運用性の問題の解決にもならない。
[19] そこまでしてなぜ Unicode に変換する必要があるのかというとそれは Unicode を使うためなのだろう。当時まだ勢力があった ISO/IEC 2022 派を懐柔するなにかの改善ないし譲歩のように見えながら、 その真逆をいっているので、神経を逆撫でするようなものだったのでは。
[20] 別案として示されているUnicode言語タグを使用する案は、 本人も書いている通り考慮する価値すらない。 ならなぜそんな案を示しているんだという感じもするが、 当時はUnicode言語タグに期待が寄せられていたらしいので、 触れておきたかったのだろうか。