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

[9] CSICode Set Independent

wchar_t 符号化文字集合

[6] wchar_t における符号と文字の対応関係は実装依存です。

[7] 次のようなものがあります。

[3] 文字および文字列の処理 - Oracle Solaris でのアプリケーションの国際化とローカライズ (, ) https://docs.oracle.com/cd/E62101_01/html/E62868/gmwke.html

Oracle Solaris では、wchar_t の内部形式はロケール固有です。Oracle Solaris の Unicode ロケールでは、wchar_t は UTF-32 Unicode エンコード形式を使用し、その他のロケールは別の表現を使用します。

[4] C および C++ 組み込み SQL アプリケーションにおける日本語または中国語 (繁体字) EUC、および UCS-2 に関する考慮事項 - IBM Documentation () https://www.ibm.com/docs/ja/db2/11.1?topic=hvicc-japanese-traditional-chinese-euc-ucs-2-considerations-in-c-c

wchar_t エンコード方式が 2 バイト Unicode のクライアント環境 (例えば Windows 2000 または AIX® バージョン 5.1 以上) の場合には、NOCONVERT オプションを使用して直接 UCS-2 で作業できます。

[5] EUC(5) - ファイルフォーマット - YOS OPENSONAR () http://www.yosbits.com/opensonar/rest/man/freebsd/man/ja/man5/euc.5.html?l=ja

EUC マルチバイト文字の wchar_t エンコーディングは、 len および mask 引数に依存します。先ず、以下のように wchar_t にバイトが移動されます:

byte0 << ((lenN-1) * 8) | byte1 << ((lenN-2) * 8) | ... | bytelenN-1

その結果はそれから ~mask と AND をとられ、 maskN と OR をとられます。コードセット 2 と 3 は特殊で、前のバイト (0x8e または 0x8f) が最初に取り除かれ lenN 引数が 1 減少させられます。

歴史

[22] DIS 10646

ISO 2022 wchar_t encoding

[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推進Unicoder、アンチ 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言語タグに期待が寄せられていたらしいので、 触れておきたかったのだろうか。

メモ