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

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

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

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

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

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

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

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

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

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


[REFS[

- [5] 
[CITE@ja[character encoding]], 
[[Masataka Ohta]],
1991/07/24 16:57:49,
[TIME[2025-05-17T07:52:00.000Z]] <https://groups.google.com/g/comp.std.c/c/l6rmHpvh4H4/m/Rn4904DHkyIJ>

[FIG(quote)[ [1] [[JIS X 0221]]‐1:2001 5. 備考
>
したがって、[[正規形式]]の[[最上位オクテット]]の[[ビット]] 8
は、適合する [[CCデータ要素]]中でそれが 0
に設定されている限り、[[装置]]内で内部処理に使うことができる。
]FIG]

-
[4] [CITE@ja[ときどきの雑記帖 濫觴編 2011年10月(上旬)]], [[KIMURA koichi]], [TIME[2011-10-10T17:50:35.000Z]], [TIME[2025-05-17T07:42:46.038Z]] <http://www.kt.rim.or.jp/%7ekbk/zakkicho/11/zakkicho1110a.html#D20111008-2>

]REFS]



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


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

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


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