[6] mohta bit は、 UCS-4 の最上位ビットです。

[7] 初期の ISO/IEC 10646 は4オクテット = 32ビットの符号化文字集合でしたが、 31ビットしか使用せず、群を7ビットで表せる U-7FFFFFFF が最大の符号位置としていました。 >>1

[8] 最上位ビットを 1 とした符号位置を表すオクテットを符号化文字データ要素に含めることは認められていませんでした。 >>8 つまり U-80000000 以上が含まれるデータは不適合となります。 しかしそれを受信したときどう処理するべきなのかは定かではありませんでした。

[9] 最上位ビットを 1 とした値は、装置の内部処理で使えるとされていました。 >>1

[10] 平成時代頃には (少なくても日本でこの分野に詳しい情報技術者の間では) これを mohta bit と呼び習わしていました。 >>4

[11] かつてはそれなりに使われていた言葉のようですが (といっても使う場面はそうそうありませんが)、 現在ではウェブ検索でもほとんど用例を見つけられません。

[13] mohta 氏が関与したためにこう呼ばれるようになったとされますが、 具体的にその由来を説明したものは見つけられません。

[14] に mohta 氏がUSENETニュースグループ comp.std.c に投稿した記事によると、 getchar が正 (文字) か負 (EOF) かで分岐するような手法が一般的に用いられているため、 wchar_t を UCS-4 としたときでもこの慣習を維持できるよう、 DIS 10646 の投票時に日本から要求したとのことです。 >>5

[15] 当時の議事は現在ウェブ上で公表されておらず、 あるいは日本の委員会の報告書か何かがどこかの図書館に所蔵されている可能性もあるものの、 詳細は不明です。

[16] しかし mohta が何らかの関与をして mohta bit の規定が作られたというのはおそらく事実なのでしょう。

[1] JIS X 0221‐1:2001 5. 備考

したがって、正規形式の最上位オクテットのビット 8 は、適合する CCデータ要素中でそれが 0 に設定されている限り、装置内で内部処理に使うことができる。

[2] 将来 ASCII の8ビット目のように禍根8ビット安全とならなければよいのですが...

[12] >>2 逆に U-00110000 以上が全部未使用領域になるとはねえ

[17] skf内部符号は内部処理用に負の符号を使っています。 mohta bit の表現する領域に当たります。

[3] 関連: UCS-4, Unicodeの符号空間