hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
X Window System コアプロトコル 概要
サーバとクライアント間の通信は、伝送路上でパケットを交換することでなされる。コネクションはクライアントが確立する（クライアントの起動についてはプロトコル上規定されていない）。クライアントは最初のパケットを送信する。これには、使用するエンディアン、プロトコルのバージョン、クライアントがサーバに期待する認証方式が指定されている。サーバは、コネクションを受け付けるか否かを示した応答パケットを送り返すか、認証のためのパケットを送る。コネクションが受け付けられる場合、その後のやり取りでクライアントが使うべきデータを格納したパケットが送られる。
コネクションが確立すると、クライアントとサーバ間で以下の四種類のパケットが交換される。
要求パケットと応答パケットは様々な長さのものがあるが、イベントパケットとエラーパケットは32バイトで固定されている。
要求パケットにはサーバ側で受信した時点で逐次的な番号が振られる。あるクライアントからの最初の要求パケットには 1、2番目のパケットには 2 といったようになる。この番号の最下位ビットから16ビットぶんが応答パケットやエラーパケットに格納され、どの要求に対するものかを示すようになっている。また、イベントパケットにも同様の情報が格納されており、イベント発生時に処理中（あるいは直前まで処理していた）の要求パケットの番号が示されている。
X Window System コアプロトコル ウィンドウ
一般にグラフィカルユーザインタフェースで「ウィンドウ」と呼ぶものを、X Window System では「トップレベルウィンドウ」と呼ぶ。いわゆる「親ウィンドウ」の「サブウィンドウ」と呼ばれるウィンドウ内ウィンドウも「ウィンドウ」と呼ぶ。ボタン、メニュー、アイコンなどのグラフィカルな構成要素は、実際にはサブウィンドウとして認識されている。
クライアントはウィンドウ生成を要求できる。より正確に言えば、既存のウィンドウのサブウィンドウの生成を要求できる。結果として、クライアントが生成するウィンドウ群は一種の木（階層）を形成する。この木の根をルートウィンドウと呼び、サーバが起動したときに自動的に生成される特殊なウィンドウである。他の全ウィンドウはルートウィンドウの直接的または間接的なサブウィンドウである。トップレベルウィンドウは、ルートウィンドウの直接のサブウィンドウである。見た目で言えば、ルートウィンドウは画面全体と同じ大きさであり、他のウィンドウ群の一番背後にある。
X Window System コアプロトコル ウィンドウ
ウィンドウの内容は常に保持されるとは限らない。特に、ウィンドウが移動されたり、リサイズされたり、他のウィンドウの影に隠れたり、完全に（あるいは部分的に）見えなくなったりすると、ウィンドウの内容は破壊される可能性がある。Xサーバが、ウィンドウの内容の「バッキングストア」を管理していない場合はウィンドウの内容は失われる。クライアントはバッキングストアの保持を要求することができるが、サーバが必ずそうするという保証はない。従って、クライアントはバッキングストアを当てにしてはいけない。見える状態のウィンドウの中身が不明の場合、そのクライアントに対してイベントが送られ、内容の再描画が行われる。
ウィンドウには、一連の「属性」があり、ウィンドウの大きさと位置、背景画像、バッキングストア要否などの情報が格納されている。これら属性を調べたり、変更したりする要求パケットが存在する。
ウィンドウは InputOutput と InputOnly のどちらかである。画面に表示され、何らかの内容が描画されるものは前者である。後者のウィンドウは画面には現れず、入力を受け取るためだけに存在する。
X Window System コアプロトコル ウィンドウ
ウィンドウの外枠とタイトルバー（ボタンも含むことがある）はウィンドウマネージャが作成するものであって、そのウィンドウを作成したクライアントは関知しない。ウィンドウマネージャは、それらの部分についての入力も受け取り、ウィンドウのリサイズなどに対応する。クライアントは一般にウィンドウマネージャによるウィンドウの変化は関知しない。しかし、最近のウィンドウマネージャの多くはトップレベルウィンドウの親ウィンドウをルートウィンドウ以外に設定変更することが多く、この変更をクライアントが無視することはできない。Xコアプロトコルの観点では、ウィンドウマネージャもクライアントの一種であり、他のアプリケーションと何ら違いはない。
ウィンドウに関する情報は xwininfo プログラムを実行することで得られる。引数に -tree を付与すると、ウィンドウの親子関係をツリー形式で表示し、それぞれの識別子や位置データも表示する。
X Window System コアプロトコル ピクスマップと描画領域
ピクスマップとは、描画に使われるメモリ領域である。ピクスマップの内容がそのままウィンドウとして表示されるわけではなく、ピクスマップの内容（の一部）がウィンドウに転送されたり、逆にウィンドウからピクスマップに内容が転送されたりする。これによりダブルバッファリングなどの技法が可能となっている。ウィンドウ上で可能なグラフィカルな操作の多くは、ピクスマップ上でも可能である。
ウィンドウとピクスマップを総称して「描画領域; drawables」と呼ぶ。描画領域の内容データはサーバ側に置かれる。クライアントはサーバに対して描画領域の内容を転送してもらうこともできるし、逆に内容をサーバに送ることもできる。
X Window System コアプロトコル グラフィックコンテキストとフォント
クライアントはいくつかのグラフィック操作を要求できる。例えば、領域の生成、領域のコピー、点/直線/多角形/テキストの描画などである。これらの操作は全て、任意の描画領域（ウィンドウもピクスマップも）に対して実施可能である。
グラフィック操作要求の多くは、「グラフィックコンテキスト」を含む。これは、グラフィック操作のパラメータを格納した構造体である。グラフィックコンテキストには、前景色、背景色、テキストのフォント、その他のグラフィックパラメータが含まれる。グラフィック操作を要求する場合、クライアントはグラフィックコンテキストを作成しなければならない。グラフィックコンテキストの全パラメータがグラフィック操作に影響するわけではない。例えば、直線描画要求では、フォント指定は影響しない。
X Window System コアプロトコル グラフィックコンテキストとフォント
Xコアプロトコルでは、サーバ側のフォントの使用を扱う。その場合のフォントはファイルとして格納されており、サーバはローカルなファイルシステムに直接アクセスする場合もあるし、「フォントサーバ」と呼ばれるプログラムにネットワーク経由でアクセスする場合もある。クライアントは、そのサーバで利用可能なフォント一覧を要求でき、フォントのロード（まだロードされていない場合）やアンロード（他のクライアントが使っていない場合）を要求できる。クライアントはフォントについての汎用情報を要求でき、特定のテキストを特定のフォントで描画するときに必要なスペースを問い合わせることもできる。
フォント名はXコアプロトコルのレベルでは任意の文字列に過ぎない。X Logical Font Description Conventions により、フォントの属性に対応した命名規則が規定されている。この命名規則では、オプション的な属性も考慮するようになっている。
xlsfonts プログラムは、サーバが格納しているフォントの一覧を表示する。xfontsel プログラムは、フォントの字体を表示し、フォント名をコピー・アンド・ペーストで別のウィンドウに入力できる。
近年では、クライアント側でフォントを用意することが多くなり、サーバ側フォントの使用が廃れつつある。クライアント側フォントは、クライアント側でレンダリングするもので、XftやCairoライブラリを使ったり、XRender拡張を使ったりする。Xコアプロトコルにはクライアント側フォントに関する規定は存在しない。
X Window System コアプロトコル リソースと識別子
ウィンドウ、ピクスマップ、フォントなどに関するデータは全てサーバに格納されている。クライアントはそれらオブジェクトの識別子を知っており、サーバにそれらについて要求する際に名前として使用する。例えば、クライアントがウィンドウを生成したいとき、サーバに対して識別子を指定してウィンドウ生成を要求する。その識別子は後で、例えばウィンドウの描画時などクライアントからの要求で使用される。以下のオブジェクトはサーバ側にあり、識別子を使ってクライアントから指定される。
これらのオブジェクトを「リソース; resources」と呼ぶ。クライアントがこのようなリソースの生成を要求する場合、その識別子を常に指定する。例えば、新しいウィンドウを生成する場合、クライアントはそのウィンドウの属性（親、幅、高さなど）とウィンドウに関連付ける識別子を指定する。
識別子は32ビット整数であり、最上位ビットから3ビットは常にゼロとされる。クライアントごとに識別子の集合を持ち、新しいリソース生成時に使用する。この集合はサーバがコネクションの受理を知らせるパケット内で、2つの整数としてクライアントに通知される。クライアントは指定された範囲から、重ならないように識別子を選択して使う。ウィンドウ、ピクスマップ、フォント、カラーマップ、グラフィックコンテキストについて、2つのオブジェクトが同じ識別子を持つことはできない。
X Window System コアプロトコル リソースと識別子
あるリソースが生成されると、その識別子をクライアントが使い、サーバに対してそのリソースに関する何らかの操作を要求するときに指定する。操作には、リソースを変化させるもの（例えば、ウィンドウを移動させる要求）と、サーバからそのリソースに関するデータを得るもの（例えば、ウィンドウの属性を要求する場合）がある。
識別子はクライアント内だけでなく、サーバ内で一意である。例えば、2つのウィンドウがそれぞれ別のクライアントが生成したものであっても、同じ識別子を持つことはない。クライアントは識別子さえ指定できれば、任意のオブジェクトにアクセスでき、例えば別のクライアントが生成したリソースも識別子が分かっていればアクセスできる（サーバから与えられた範囲外の識別子をサーバへの要求パケットに指定可能である）。
X Window System コアプロトコル リソースと識別子
結果として、同じサーバに接続された2つのクライアントがあるとき、識別子によって一意にリソースが指定される。例えば、あるクライアントが識別子 0x1e00021 のウィンドウを生成し、その番号 0x1e00021 を別のアプリケーションに渡したとする（手段は何でも良い。例えば、ファイルに番号を書き込み、それを別のアプリケーションが読むという方法でもよい）。すると、その別のアプリケーションが同じウィンドウに対して操作可能となる。これは例えば Ghostviewの X 版で利用されている。Ghostview はサブウィンドウを生成し、その識別子を環境変数にセットして Ghostscript を呼び出す。Ghostscript は PostScript ファイルの内容をそのウィンドウに描画する。
リソースは、それを生成したクライアントがサーバとのコネクションをクローズしたときに正常に削除（破壊）される。ただし、コネクションをクローズする前にクライアントから破壊を要求することもできる。
X Window System コアプロトコル イベント
イベントとは、サーバからクライアントに送信されるパケットであり、クライアントが興味を持ちそうな事象が発生したことを通知するのに使われる。例えば、ユーザがキーを押下したり、マウスのボタンをクリックしたなどの事象である。イベントはユーザの入力だけではない。例えば、新たなサブウィンドウが生成された場合などにもイベントパケットが送信される。
イベントは常にいずれかのウィンドウに関連付けられている。例えば、マウスカーソルがあるウィンドウ上にあるときにクリックした場合、そのイベントはそのウィンドウと関連付けられる。イベントパケットにはそのウィンドウの識別子も含まれる。
クライアントはサーバに対してイベントパケットを他のクライアントに送るよう要求できる。これはクライアント間の通信に利用される。例えばマウスクリックで選択されたテキストをクライアントが要求する場合に、そのようなイベントが使われる。そのイベントは、その選択を保持しているウィンドウを制御しているクライアントに送られる。
X Window System コアプロトコル イベント
Expose イベントは、ウィンドウの一部の内容が破壊された領域が画面上見えるようになったとき送信される。ウィンドウの内容はいくつかの条件が重なると破壊される。例えば、ウィンドウが別のウィンドウに隠され、サーバがバッキングストアを保持していなかった場合などである。サーバが Expose をクライアントに送信すると、クライアントはその部分を再描画しなければならない。
多くのイベントは、クライアントがそれについて興味があることを事前に表明していないと送信されない。これは、クライアントが必ずしも全てのイベントを必要としないためである。例えば、キーボード入力は受け付けるが、マウス関連のイベントは受け付けないといった状況が考えられる。イベントには、クライアントが明示的に要求していなくても必ず送信されるものもある。
クライアントは、ウィンドウの属性としてどのイベントを受け付けるかを設定できる。例えば、Expose イベントはウィンドウの再描画が必要な場合に送られるが、クライアント側でこれを受け付けない状態にすることもできる。これは、ウィンドウのイベントマスク属性を適切に設定することでなされる。
X Window System コアプロトコル イベント
複数のクライアントが同じウィンドウのイベントを要求することもできる。その場合クライアント毎に異なるイベントマスクを設定できる。例えば、あるクライアントはキーボードのイベントだけを受け付け、別のクライアントがマウスのイベントだけを受け付けるといったことが可能である。サーバは各ウィンドウについてクライアント毎のイベントマスクを保持できるようになっている。ただし、ウィンドウ毎に1つのクライアントにしか送信できないイベントも存在する（特にマウスクリックについてのイベントやウィンドウ管理に関連した変化を知らせるイベント）。
xev プログラムは、ウィンドウに対応したイベントを表示する。特に xev -id WID とすれば、指定した識別子 WID に関わるイベントを全て表示する。
X Window System コアプロトコル 例
以下は、黒い四角形が描画されたウィンドウを生成し、キー押下で終了するクライアントとサーバ間のやり取りを例示したものである。この例では、クライアントの要求が応答を必要とするものではないため、サーバ側から応答パケットは送信されない。ただし、エラーパケットが生成される可能性はある。
このウィンドウが別のウィンドウに覆われ、再び前面に戻った場合、バッキングストアをサーバが保持していないと、次のようになる。
キーが押下されると、次のようになる。
X Window System コアプロトコル 色
プロトコルレベルでは、色は32ビットの符号なし整数で表され、ピクセル値（pixelvalue）と呼ばれる。以下のような要素から色の表現が影響を受ける。
最も容易な場合、カラーマップは各行にRGBの値が格納されたテーブルとなる。ピクセル値 x は、そのテーブルのx-行目の色を意味する。クライアントがカラーマップの内容を変更できる場合、この表現方法は PseudoColor visual class である。StaticColor visual class では、クライアントがカラーマップの内容を変更できない。
visual class は全部で6種類存在する。それぞれ、RGB値とピクセル値の対応付け方法が異なる。そのうち、2つが上述の PseudoColor と StaticColor である。他に GrayScale と StaticGray があり、これらは白、黒、灰色のみが表示可能である（前者ではクライアントによるカラーマップ変更が可能）。
残る2種類の visual class はこれらとは異なり、ピクセル値がそのままRGB値に対応している。この場合のピクセル値からRGB値への変換は次の通り。
X Window System コアプロトコル 色
この場合、カラーマップは赤/緑/青の光の三原色それぞれに対応した3つのテーブルで構成される。結果として得られるのは三原色それぞれの強さである。このような表現を使う visual class として DirectColor と TrueColor があり、前者はクライアントがカラーマップを変更でき、後者は変更できない。
いずれの機構でも、色をピクセル値で表現するには追加のパラメータが必要である。それらパラメータが visual type として集約されており、visual class の種類、その他のパラメータが格納されている。Xサーバには利用可能な visual type が固定個存在し、それぞれに識別子が割り当てられている。その識別子は32ビットの符号なし整数だが、リソースやアトムの識別子と重なっていても構わない。
X Window System コアプロトコル 色
クライアントからのコネクションを受理したとき、サーバが送信する受理パケットには、一連のブロックが含まれ、各ブロックは1つの画面（スクリーン）に対応している。各画面に対応したブロックは、さらにその画面でサポートしている色深度ごとのブロックに分かれている。色深度ごとのブロックは可能な visual type のリストを含む。まとめると、各画面には複数の色深度が対応し、その色深度ごとに複数の visual type が対応する。ある visual type は異なる色深度の複数の画面で使える場合もある。
それぞれの visual type について、受理パケットには識別子と実際のパラメータ（visual class その他）が格納されている。後でこの情報を要求できないので、クライアントはこの情報を格納しておく。さらに言えば、クライアントは visual type を変更したり、新たに生成したりできない。新たなウィンドウ生成の要求時、そのウィンドウの色を表現するのに使う色深度と visual type の識別子を指定する。
X Window System コアプロトコル 色
カラーマップは、その画面を制御するハードウェア（例えばビデオカード）がカラーパレットを使っているかどうかとは無関係に使われる。ハードウェアがパレットを使う場合は、常に制限されたカラーマップがインストールされ、無制限にピクセル値とRGB値の対応付けを増やすことはできない。クライアントはサーバに対してカラーマップのインストールを要求できるが、その場合、別のカラーマップのアンインストールが必要となる。これは、画面を見たとき、アンインストールされたカラーマップを使っていたウィンドウの色が変に表示されるという結果をもたらす（この現象を color flashing あるいは technicolor と呼ぶ）。この問題は標準カラーマップ（standard colormap）を使うことで解決する。標準カラーマップはピクセル値と色の事前に決められた対応付けをする。このため、異なるアプリケーション間で標準カラーマップを共用することが可能となっている。
カラーマップ生成はICCCMで規定されている。標準カラーマップは ICCCM でも規定されているし、Xlib 仕様にも定義されている。
X Window System コアプロトコル アトム
アトム（Atom）とは、文字列を表す32ビット整数である。文字列が任意の長さであるのに対してアトムは常に32ビット整数であり、プロトコル設計者は文字列を短い固定サイズで表すためにアトムを導入した。アトムは短いため、同じ文字列をパケットとして何度も送信するような場合に利用される。これによってネットワークの利用効率が向上する。アトムはまた、イベントパケットのような固定サイズのパケットで利用される。
正確には、アトムはサーバが保持する文字列の識別子である。リソース（ウィンドウやピクスマップ）の識別子に似ているが、2つの点で異なる。まず第一に、アトムの識別子はサーバが設定するのであって、クライアントは指定できない。つまり、クライアントが新たなアトム生成を要求するときは、サーバに文字列を送信するだけであり、識別子は指定しない。サーバはその文字列に識別子を割り当て、クライアントへの応答パケットでそれを返す。第二に、アトムは特定のクライアントとは関連しない。アトムは、生成されるとクライアントが終了しても存続し、サーバが終了するまで残る（リソースのデフォルトの振る舞いはそれとは異なる）。
X Window System コアプロトコル アトム
アトムは識別子であるから、一意である。しかし、アトムとリソースの識別子は同じになることがある。アトムに対応した文字列は「アトム名; atom name」と呼ばれる。アトム名は生成後に変更することはできないし、二つのアトムが同じアトム名となることもない。従って、アトム名はアトムを指すのにも使える。「アトム ABCD」と言った場合、正確には「文字列 ABCD に対応するアトム」あるいは「名前が ABCD のアトム」を意味する。クライアントは、新たなアトム生成を要求することもできるし、ある文字列のアトム（識別子）を要求することもできる（これらは同じ意味である）。事前定義されたアトムもある（特定の識別子と文字列でサーバが生成する）。
アトムは様々な用途で使われ、主に同じサーバに接続した複数のクライアント間の通信でよく使われる。特に、後述するウィンドウのプロパティに関連して使われる。
サーバ内に保持されている全アトムの一覧は xlsatoms プログラムを使って表示できる。特に、このプログラムはそれぞれのアトム（識別番号）とその名前（対応する文字列）を表示できる。
X Window System コアプロトコル プロパティ
各ウィンドウには、事前定義された属性群とプロパティ群があり、サーバに全て格納され、クライアントからは適当な要求でアクセスできる。属性はウィンドウに関するデータであり、サイズ、位置、背景色などがある。プロパティはウィンドウにアタッチされた任意のデータである。属性とは対照的に、プロパティはXコアプロトコルのレベルでは何の意味もない。クライアントはウィンドウのプロパティとして任意のデータを格納できる。
プロパティには、名前、データ型、値がある。プロパティは命令型プログラミングにおける変数に似ていて、クライアントが名前とデータ型を指定して生成でき、任意の値を格納できる。プロパティはウィンドウに対応しているため、同じプロパティ名を複数のウィンドウそれぞれで使い、それぞれ異なる型の異なる値を格納できる。
プロパティの名前、データ型、値は全て文字列である。より正確に言えば、これらは全てアトムであり、サーバに格納されている文字列に対応していて、クライアントからはその識別子でアクセス可能である。クライアントはあるプロパティに対して、その名前を格納したアトムの識別子を使ってアクセスする。
X Window System コアプロトコル プロパティ
プロパティは主にクライアント間通信に使われる。例えば、WM_NAME という名前のプロパティ（正確には、"WM_NAME" という文字列に対応したアトムをプロパティ名とするプロパティ）にはウィンドウの名前が格納される。ウィンドウマネージャは、一般にこのプロパティを読み、タイトルバーにウィンドウ名を表示する。
クライアント間通信には、ルートウィンドウのプロパティを使ったものもある。例えば、freedesktop.org のウィンドウマネージャ仕様によれば、ウィンドウマネージャは現在のアクティブウィンドウの識別子をルートウィンドウの _NET_ACTIVE_WINDOW というプロパティに格納するべきとしている。プログラムのパラメータを含むXリソースもルートウィンドウのプロパティとして格納される。そうすることで、（別のコンピュータ上で動作していても）全てのクライアントがそれらにアクセスできる。
xprop プログラムは指定されたウィンドウのプロパティ一覧を表示する。xprop -root とすれば、ルートウィンドウの各プロパティの名前、型、値を表示する。
X Window System コアプロトコル キー・マッピング
X Window System では、全ての個々の物理キー（キーボードのキー）に 8 から 255 の数が割り当てられていて、これを keycode と呼ぶ。keycode はキーを特定するだけであり、そのキーに印字されている特定の文字や用語（例えば "Page Up"）の識別はできない。それら文字や用語は keysym で識別される。keycode は実際の1つのキーに対応しているが、keysym は、例えばシフトキーなどの修飾キーが同時に押されたかどうかに対応して決定される。
キーが押下されたり、解放されたとき、サーバは KeyPress イベントあるいは KeyRelease イベントを適当なクライアントに送信する。これらのイベントには以下の情報が含まれる。
つまりサーバは、keycode と修飾状態を特定の文字に変換せずに送信する。この変換をするのは、クライアントの役割である。例えば、クライアントがあるキーとシフト修飾キーが押下されていることをイベントで通知されたとする。通常このキーが "a" という文字を生成するなら、クライアントは、このイベントによって文字 "A" を得る。
X Window System コアプロトコル キー・マッピング
keycode から keysym へのクライアントでの変換には、サーバが用意した対応表を使う。この表をどこか全クライアントから参照可能なところに置けばよい。典型的なクライアントは、このマッピングを要求し、キーイベントの内容（keycode と修飾状態）から keysym への変換を行う。ただし、クライアントはこのマッピングを自由に変更できる。
修飾キーは、押下されると他のキーの解釈を変化させる。シフトキーは、一般に "a" のような小文字を "A" のような大文字に変化させる。他の修飾キーとしては、「コントロールキー」、「Altキー」、「Metaキー」などがある。
Xサーバは、最大8種類の修飾キーを扱える。ただし、各修飾キーは必ずしも1つの物理キーに対応したものとは限らない。キーボードには、同じ修飾キーが複数個存在する場合があるからである。例えば、多くのキーボードには2つのシフトキーがある（左端と右端）。これらの keycode は異なるが、Xサーバはどちらもシフト修飾キーと認識する。
8個の修飾キーについて、Xサーバはその修飾キーと認識される keycode の一覧を持っている。例えば、第一修飾キー（シフト）の keycode 一覧で 0x37 が記載されている場合、その keycode 0x37 に対応したキーをXサーバがシフト修飾キーであると認識する
X Window System コアプロトコル キー・マッピング
修飾キーと解釈されるキーのマッピングはXサーバが管理するが、任意のクライアントが変更できる。例えば、クライアントからF1キーをシフト修飾キーとして解釈されるキー一覧に追加することができる。このような修正を加えると、F1キーが第3のシフトキーとして機能するようになる。しかし、F1キーを押下した場合の keycode はそのままである。したがって、F1キーを従来通りに解釈することもできるし（例えば、F1キー押下でヘルプウィンドウを開くなど）、同時にシフトキーとしても機能する（"a" キーを押下したときにF1キーが押下されていると "A" と解釈される）。
Xサーバは、マウスボタンについてもマッピングを管理し、使用する。ただし、ボタンはボタン同士での入れ替えだけが可能となっている。これは、左利きのユーザ向けに左端のボタンと右端のボタンを入れ替えるのに便利である。
xmodmap プログラムは、キー/修飾キー/マウスボタンのマッピングを表示・変更する。
X Window System コアプロトコル グラブ
グラブ（grab）とは、キーボードとマウスの全イベントを1つのクライアントに送信する状態である。クライアントは、キーボードのグラブ、マウスのグラブ、あるいは両方のグラブを要求できる。サーバがその要求を満たす場合、全キーボード/マウス・イベントはグラブしたクライアントに（グラブをやめるまで）送られる。その間、他のクライアントはそれらイベントを受け取れない。
グラブ要求時、クライアントはグラブウィンドウを指定する。全イベントはグラブしているクライアントがグラブウィンドウに関連しているかのように送信される。しかし、他のクライアントはたとえグラブウィンドウを選択していてもイベントを受け取れない。グラブには、以下の2種類がある。
アクティブ
グラブは即座に効力を発揮する。
パッシブ
グラブは事前に指定されたキーまたはマウスボタンが押下されたときのみ効力を発揮し、解放された時点で終了する。
X Window System コアプロトコル グラブ
クライアントはキーボードかマウスポインタ、あるいは両方についてグラブ状態を確立できる。グラブ要求にはキーボードやマウスポインタのフリーズ要求を含めることもできる。グラブとフリーズの違いは、グラブがイベント受信者を変更するのに対して、フリーズはイベントの配信そのものを停止する点である。デバイスがフリーズされると、それが生成するイベントはキューに格納され、通常はフリーズ状態が解除されたときに溜めておいたイベント群が送信される。
マウスポインタのイベントの場合、イベント配信に影響を与える別の要素として、イベントマスクがある。これは、イベントの種類ごとに配信するか捨てるかを指定するものである。
グラブ要求には、グラブが確立していない状態でグラブしようとしているクライアントにイベントが送られようとしたとき、どうすべきかを指定するフィールドもある。特に、クライアントはそのようなイベントを普通に送信してもらうか、グラブに従って送信してもらうかを指定できる。これらの状況は見た目にも異なる結果となる。例えば、クライアントが通常状態では第一ウィンドウでキーボードイベントを受け取っていて、第二ウィンドウによるキーボードのグラブを要求したとする。イベントを第一ウィンドウに送信するかグラブウィンドウ（第二ウィンドウ）に送信するかはグラブ要求のパラメータに依存する。
クライアントはサーバ全体のグラブを要求することもできる。この場合、グラブクライアントからの要求以外は受け付けなくなる。
X Window System コアプロトコル その他
他にもXコアプロトコルには要求やイベントが存在する。まず、ウィンドウ間の親子関係に関する要求がある。クライアントは、ウィンドウの親の変更要求が可能である。また、ウィンドウの親子関係に関する情報を要求することもできる。他にセレクションに関する要求があるが、これは主に他のプロトコルで扱われる。入力フォーカスやカーソル形状についての要求もある。クライアントは、特定のリソース（ウィンドウ、ピクスマップなど）の所有者を終了させる要求もでき、サーバはそのコネクションを終了させる。また、クライアントはサーバにNOP要求を送信することもできる。
X Window System コアプロトコル 拡張
X Window System コアプロトコルは、拡張性を考慮して設計された。Xコアプロトコルには、利用可能な拡張や、拡張の要求/応答/イベント/エラーパケットをどう作ればよいかを問い合わせる機構を備えている。
特に、特定の拡張に対応したデータについて利用可能な拡張の一覧を要求できる。拡張のパケットは、Xコアプロトコルのパケットとよく似ている。Xコアプロトコルでは、要求/応答/イベント/エラーパケット内にそのパケットのタイプを示す整数が含まれている。例えば、新たなウィンドウの生成要求は 1 である。この整数の一部範囲が拡張用に予約されている。
X Window System コアプロトコル 認可
クライアントがサーバとのコネクションを確立しようとした時、サーバのとりうる応答としては、受理するか、拒否するか、認証を要求するかのいずれかである。認証要求には、使用する認証手法の名称が含まれる。Xコアプロトコルでは認証プロセスは規定されておらず、使っている認証の種類に依存する。さもなくば、サーバは単に受理パケットか拒否パケットを送るだけである。
通常のクライアントとサーバのやり取りで認証に関わる要求は「ホストによるアクセス制御; host-based access method」だけである。クライアントは、この認証手法を有効にする要求ができ、接続を認可されているホスト（クライアント）の一覧を読んだり変更したりできる。一般のアプリケーションはこれらの要求を使うことはない。これらを使うプログラムとして xhost があり、ユーザやシェルスクリプトがアクセス可能ホスト一覧を読み書きできるようにする。ホストによるアクセス制御は、安全ではないと言われている。
X Window System コアプロトコル Xlib その他のクライアント・ライブラリ
多くのクライアントプログラムは、Xlibというクライアントライブラリを通してXサーバと通信する。クライアントは一般に Xaw、Motif、GTK、Qt といったライブラリを使うが、これらもXサーバとの通信には Xlib を使っている。Xlib を使うことで、以下のようになる。
Xlib を使うと、クライアントは応答とイベントの観点で同期的に動作可能となる。
Xlib では、要求を送信すると適当な応答があるまでブロックする。言い換えれば、Xlib を使っていないクライアントがあったとしたら、要求パケット送信後に応答を待つ間に他の処理が可能である。ただし、クライアントがマルチスレッド化されている場合は、Xlib を使っていても同様のことが可能である。
Xサーバは非同期にイベントを送信するが、Xlib はイベントをクライアント内のキューに蓄積する。クライアントは、明示的にライブラリ関数を呼び出したときだけそのキュー上のイベントにアクセスする。言い換えれば、クライアントがあるイベントを待っている場合、強制的にブロックまたはビジーウェイトとなる。
X Window System コアプロトコル Xlib その他のクライアント・ライブラリ
Xlib では要求をサーバに即座に送信せず、output buffer というキューに蓄積する。その内容が実際に送信されるのは、以下のタイミングである。
XFlashなどのライブラリ関数を使って明示的に送信を要求したとき。
Xサーバからの応答を待つ必要のあるライブラリ関数を呼び出したとき（例えば、XGetWindowAttributes）。
イベントキューにイベントがあるか問い合わせたとき（例えば、XNextEvent 呼び出し）で、かつブロックするような呼び出しをしたとき（例えば、XNextEvent はキューが空だとブロックする）。
Xtのような上位ライブラリ（さらに上位として Xaw や Motif がある）では、イベントに対応したコールバック関数を使うことができる。つまり、上位ライブラリがイベントキューを常時監視し、必要に応じて適切なコールバック関数を呼び出す。また、ウィンドウの再描画が必要となるようなイベントは Xt 内部で処理される。
XCB などの下位レベルのライブラリはプロトコルへの非同期アクセスを提供し、レイテンシ隠蔽効果が大きい。
X Window System コアプロトコル X Window System コアプロトコルで指定されないこと
X Window System コアプロトコルでは、クライアント間通信は規定されておらず、ウィンドウを使ってGUIに一般的に存在する視覚的要素（ボタンやメニューなど）をどう実現するかも規定していない。GUI要素は、ウィジェット・ツールキットと呼ばれるクライアントライブラリで実装される。クライアント間通信は、ICCCM や freedesktop.org の仕様など他の標準でカバーされている。
クライアント間通信は、セレクション、カットバッファ、ドラッグ・アンド・ドロップと関係がある。これらはユーザが利用するウィンドウ間のデータ転送手法である。ウィンドウが他のプログラムに制御されている場合もあるため、データ交換のためのプロトコルは必須である。クライアント間通信はXウィンドウマネージャとも関係がある。ウィンドウマネージャはウィンドウ群の見た目を制御し、GUIとしてのルック・アンド・フィール全般を制御する。他にもクライアント間通信に関わる問題として、Xセッションマネージャが関与する部分がある。
ユーザセッションの開始方法もXコアプロトコルではカバーされていない。通常、Xディスプレイマネージャが自動的に行う。しかし、ユーザが xinit や startx プログラムを手動で起動してセッションを開始することもできる。
大田区立田園調布中学校
大田区立田園調布中学校（おおたくりつ でんえんちょうふちゅうがっこう）は、東京都大田区田園調布二丁目に所在する区立中学校。
暗黒街戦士
『暗黒街戦士』（あんこくがいせんし）は、日本の伝奇小説作家菊地秀行が著した中編小説集。
暗黒街戦士 概要
〝死なずの醍醐〟と呼ばれる不死身の揉め事処理屋（トラブル・シューター）の活躍を描く、エロスとバイオレンスを盛り込んだ菊地秀行のアダルト向け作品。シリーズ第1作。
菊地作品には数少ない一人称（「おれ」）で語られる小説である。
なお、同じくトラブル・シューターの醍醐の甥・醍醐蘭馬を主人公としたシリーズもある。
バンディラ・ロッサ・グループ
バンディラ・ロッサ・グループ（Bandiera Rossa Association、BRA）は、イタリアの政党の一つである共産主義再建党（PRC）内部のグループ。政治的にトロツキズムを標榜しており、第四インターナショナル（統一書記局派）のイタリア支部として活動している。
1940年代後半に革命的共産主義グループ（GCR）として発足し、2004年までリヴィオ・マイタンがGCRおよび後継組織であるBRAの指導的地位にあった。
ドライアイス洗浄
ドライアイス洗浄（ドライアイスせんじょう）は、洗浄物の表面にドライアイスを吹きつけて洗浄する方法。
ドライアイス洗浄 概要
この洗浄手法を用いた装置をドライアイス洗浄機という。ドライアイス洗浄はコンプレッサーの圧縮空気を使い、ドライアイスの粒を噴射して洗浄する。サンドブラストに比べてアルミナなどの後処理に困らないと考えられ、粉塵公害なども起こりにくいものと考えられている。
ドライアイス洗浄機は機内でドライアイスペレット（⌀3 mmペレット）を弱い圧力で必要量にして集めた後、300 m/秒の速度で一気に放出される。粒状またはパウダー状のドライアイスを圧縮空気と一緒に洗浄対象物に吹きつけ、汚れを落とす。ドライアイス洗浄は欧米諸国では非常に実績が高く、この洗浄方法が生まれてから約25年の歴史になろうとしている。国内でも採用する企業が徐々に増えてきており、先進性の高い生産技術や保全部門などで採用されていたが、軽量コンパクトで低価格のモデルも発売されるなど、中小の工場にとっても手に届きやすくなってきた。しかし、大量の圧縮空気を利用するため、それに対応したコンプレッサーの使用が求められたり、ノズルが発する騒音と言った課題も抱えている。ドライアイスペレットは安価で流通しており、専用保冷容器に入れれば1週間ほど保管できる。
ドライアイス洗浄 2ホース式（ツーガンホース式）
洗浄機本体からガンまでのホースが2本。
ドライアイス洗浄の初期に使われた方式で、構造が簡単なので現在も作られている。
構造が簡単で作成コストは低いが、ホースは嵩張って取り扱いが困難で、ドライアイス消費量のコントロールも難しい。
ドライアイス洗浄 1ホース式（ワンガンホース式）
洗浄機本体からガンまでのホースが1本。
現在、主流となりつつある方式。構造が複雑な反面、ドライアイス消費量を完全にコントロールでき、ノズルの設計が自由にできるので威力が強い。ノズル噴出口の口径と形状、曲がり角は数種類あり、洗浄箇所による使い分けも可能。
構造が複雑で作成コストは高いが、ホースが軽く取り扱いが容易、ノズルの種類が豊富、ドライアイス消費量のコントロールが容易、と言った利点がある。
ドライアイス洗浄 ドライアイスペレット洗浄方式
直径3 mmのドライアイスペレット（米粒大）をエアーと混合してそのまま吹き付ける洗浄方法。
強く付着している付着物に対して適している。ノズルによって洗浄範囲は自由に変えられる。
ドライアイス洗浄 ドライアイスペレットを用いるドライアイスパウダー洗浄方式
同様のドライアイスペレットを洗浄機内、またはノズル内部で適切なサイズに粉砕し、エアーと混合して吹き付ける洗浄方法。
ペレット洗浄方式の洗浄物と比べて強く無く、ペレットを砕いた分、粒子の量が多くなるため、より広範囲または密度に高い洗浄に適する。
粉砕範囲も、ペレットの半分程度から砂粒程度の微粒子まで様々な大きさに出来る。
ドライアイス洗浄 液化CO2を用いるドライアイスパウダー洗浄方式
液化CO2から取り出したままの粉末状のドライアイス粉末を、本体、またはノズル内で混合し、エアーと混合して吹き付ける洗浄方法。
液化CO2タンクがあれば、何時でも洗浄が出来るが、ペレットやペレット粉砕式に比べて威力が落ちる。
ドライアイスの入手が困難か、洗浄が突然必要になる様な場所に適する。
ドライアイス洗浄 ブロックドライアイスからのドライアイスパウダー洗浄方式
ブロックドライアイスをかき氷の様に削ってドライアイスパウダーを作りだす。
これを本体、またはノズル内で混合し、エアーと混合して吹き付ける洗浄方法。
粒子がペレット洗浄方式と比べて細かく、面積当たりの粒子衝突数が多くなるので、強くは無い付着物を落とせる。
ペレット洗浄に耐えられない薄いフィンのある金型、ペレットでは破損する恐れのある硝子などの洗浄に用いられる。
田中はくどう
田中 はくどう（たなか はくどう）は、福岡県柳川市出身の、劇作家・演出家・プロデューサーである。田中 博道の表記を使っていた時期もある。
田中はくどう 主な代表作
日本芸能教育センターからメジャーデビューしたレッスン生
藤原忻子
藤原 忻子（ふじわら の よしこ / きんし）は平安時代末期の后妃。第77代後白河天皇中宮。父は徳大寺公能で、母は藤原豪子。妹に近衛天皇皇后（のち二条天皇后）多子がいる。
久寿2年（1155年）に入内し、後白河天皇即位と共に従四位上女御となる。保元元年（1156年）、中宮に冊立。保元3年（1158年）、後白河天皇譲位。平治元年（1159年）、姝子内親王が二条天皇中宮に立后したのに伴い皇后宮。承安2年（1172年）、平徳子が高倉天皇中宮に立后したのに伴い皇太后。承元3年（1209年）、76歳で崩御。『今鏡』は美貌であったと伝えるが、後白河天皇の寵愛は薄かった。
グローバルソフトウェア
株式会社グローバルソフトウェア（英: GlobalSoftware Inc,）は、埼玉県本庄市に本社を置き、主に技術者派遣、医療情報システム、基幹系業務開発、携帯電話評価などの業務を行う日本の企業である。
グローバルソフトウェア 概要
埼玉県本庄市に本社を置き、札幌、本庄、東京、川崎、大阪、福岡を拠点とし、全国展開を行っている。
創業者は狩野輝昭。狩野輝昭氏は神社本庁統理の鷹司氏が伊勢神宮大宮司になる前からの知り合い。
グローバルソフトウェア 事業所
2014年12月時点で新潟、長岡事業所は閉鎖している。
上棚矢駄インターチェンジ
上棚矢駄インターチェンジ（うわだなやだインターチェンジ）は、石川県羽咋郡志賀町上棚にあるのと里山海道のインターチェンジ (IC) である。
上棚矢駄インターチェンジ 料金所
有料道路時代は本線上と金沢方面入口および穴水方面出口にそれぞれ設置されていた。いずれもETCやクレジットカードは利用できず、かつて道路関係四公団が発行していたハイウェイカードも利用不可であった。
本線上
出入口
上棚矢駄インターチェンジ 隣
E86 のと里山海道
柳田IC - 上棚矢駄IC - 西山IC
川北英隆
川北 英隆（かわきた ひでたか、1950年7月27日 - ）は、日本の経済学者。専攻は、証券投資論・証券市場分析。学位は、博士（経済学）（京都大学・2009年）（学位論文『株式・債券投資の実証的分析』）。京都大学名誉教授。奈良県大和郡山市出身。
川北英隆 人物
株式持ち合いの実態に関する先駆的分析（この分析の集大成が『日本型株式市場の構造変化』（東洋経済新報社、1995年））で知られている。金融証券市場の分析、機関投資家等の投資家行動に関する分析、投資意思決定に関する分析、企業価値分析等が現在の研究テーマである。29年間勤めた日本生命保険相互会社時代にエコノミスト、証券アナリスト、投資理論の研究者、証券投資全体の責任者を経験し、金融証券市場の実態と実務に関する知見を得た。2002年に日本生命と中央大学国際会計研究科を掛け持ちした後、2003年から学界に本格的に転じる。ファイナンス担当の教員として3つの大学の専任教員を経験する。現時点においても投資家との交流が深く、実務界と学界の架橋を担っている。
元日本ファイナンス学会会長、元日本価値創造ERM学会会長、元日本証券アナリスト協会副会長、元企業会計基準委員会委員、元みずほ証券取締役（社外）。
登山（山歩き）と旅行が趣味。1994年に日本百名山を登る。現在、世界の山歩きと辺境の旅を実行し、世界の経済と社会を実地調査している。ホームグラウンドは山梨の滝子山と京都の大文字山。「山登りが本業」、「証券分析は趣味」をモットーとする。
2009年4月から、経済・証券、山・自然、猫・動物を主題としたブログが始まった。
川北英隆 略歴
略歴は以下の通り。
現在、日本証券アナリスト協会証券アナリストジャーナル編集委員会委員長、日本ファイナンス学会顧問、日本価値創造ERM学会評議員・理事、財政制度等審議会委員、日本私立学校振興・共済事業団資産運用検討委員会委員長、地方公務員共済組合連合会資金運用委員会委員、日本取引所自主規制法人理事（外部）、GCIアセット・マネジメント取締役（社外）、あすかコーポレイトアドバイザリー監査役（社外）、みやこキャピタル監査役（社外）などを務める
三河小栗氏
三河 小栗氏（みかわ おぐりし）は、酒井氏とともに松平氏の庶家に属する氏族。別名に又市系小栗氏。
松平一族が常陸小栗氏と婚姻し家を興したとされるが、小栗吉忠以前の系譜ははっきりしない。子孫に幕臣・小栗忠順などを輩出した。なお、結城秀康に付属し、以後越前松平家の中核を担った小栗正高や、その子で越後騒動の中心人物となった小栗正矩などを輩出した大六系小栗氏は常陸小栗氏の末裔になる。
三河小栗氏 沿革
三河小栗氏が同時代史料に登場するのは小栗吉忠（又市）からで、徳川家康の奉行人として浅井道忠・道多父子とともに名を連ねることになる。
『寛永諸家系図伝』（以下『寛永系図』）によれば、始祖は松平市郎という人物で、その子の仁右衛門が母方の小栗に改めたとする。
『寛政重修諸家譜』（以下『寛政譜』）編纂時に小栗家から提出された家譜では、松平郷松平家と結び付けた主張をおこなっている。松平泰親の長男・松平信広の末裔で岩津城主であった松平信吉が、筒針城主小栗正重（常陸小栗氏）の妹との間に設けた子が一郎忠吉（のちにニ右衛門。『寛永系図』の「松平市郎」に相当）とする。これよりさき、信吉は松平親忠の長男松平親長を養子に迎え、家督と岩津城を譲っていた。忠吉が7歳の時に信吉が没したが、親長と忠吉の母との折り合いが悪く、忠吉とその母は小栗正重のもとへ寓居した。忠吉と松平遠江守の妹との間に生まれた子供を正重が養ったのが小栗吉忠（ニ右衛門）であるという。
この家伝について『寛政譜』は、『寛永系図』との齟齬（仁右衛門が母の小栗氏に改めていたとしていたにもかかわわらず、今回の呈譜では仁右衛門＝ニ右衛門吉忠の母が松平氏と主張していることなど）を指摘、信吉の子の親長と親忠の子の岩津太郎親長を混同したのではないか、などと考証し、「今の家系疑はし」として本文では『寛永系図』の市郎から始まる系図を載せている。
三河小栗氏 沿革
小栗吉忠（又市、仁右衛門）は松平広忠に小姓として出仕し、ついで家康に仕えた。槍の功名があり、三河一向一揆の際には一族とともに筒針城を守った。掛川城攻めや小牧の戦いに従軍し、天正18年（1590年）に死去。吉忠の子・小栗忠政（又一）も、16歳で参陣した姉川の戦いで敵の首を取って以降、三方ヶ原の戦い、長篠の戦い、高天神城攻め、長久手の戦い、関ヶ原の戦い、大坂の陣などに従軍して多くの武功を挙げ、知行2550石。忠政の嫡男・小栗政信もまた上田城攻めや大坂の陣などで武功を挙げ、分知や加増を経て最終的に2500石を知行した。
忠政の二男・小栗信由（小栗正信、仁右衛門）も大坂の陣で敵を組み討ちにして武功を挙げ、旗本として別家を立てたが、武芸流派の小栗流の創始者としても名を残している。
『寛政譜』編纂時には、旗本として8家が存続していた。小栗家宗家（小栗又一家）の人物では、幕末期に外国奉行などを務めた小栗忠順が著名であり、近代以後は小栗貞雄（実業家、衆議院議員）や小栗かずまた（漫画家。本名は又一郎）を出している。
陸雲
陸 雲（りく うん、262年 - 303年）は、中国三国時代の呉から西晋にかけての政治家・文学者。字は士龍。本貫は揚州呉郡呉県。
陸雲 概要・人物
祖父・父がそれぞれ呉の重臣陸遜・陸抗で、陸機の弟である。兄と共に「二陸」と称されるほどの西晋時代きっての文学者であった。6歳で文を能くし生涯に著した文章は349編に及んだという。16歳で呉に出官するも3年後に呉が晋に降服すると、兄と共に郷里に蟄居してしまう。以後10年間は学問に励む生活を送ったのち、兄の陸機と共に上洛、晋に出仕し、陸機・顧栄と共に当時の人に「三俊」と称された。
温和な性格で、出身地の呉方言をからかわれその度にいきまく負けん気な陸機をなだめている。晋皇族の司馬晏の郎中令、尚書郎、侍御史、太子中舎人、中書侍郎、清河内史などを歴任した。その後八王の乱に巻き込まれ、陸機共々成都王司馬穎に殺された。
瀬畑茉有子
瀬畑 茉有子（せはた まゆこ、1984年8月24日 - ）は、日本の女性ファッションモデル。埼玉県出身。イデア所属。
瀬畑茉有子 略歴
文化服装学院在学中に2004年度ミス・ユニバース・ジャパン準グランプリに選ばれる。
テレビ東京系モデルオーディション番組『未来MODEL』第1回ファイナリスト。
2018年秋に結婚した。
粟崎インターチェンジ
粟崎インターチェンジ（あわがさきインターチェンジ）は、石川県金沢市にあるのと里山海道のインターチェンジ (IC) である。
のと里山海道旧線の起点で、0キロポストが立てられている。インターチェンジの名を有するものの、実態としては金沢市道と平面交差する大浜北交差点である。隣接する海浜緑台交差点と一体となっており、信号機制御もほぼ同一となっている。
粟崎インターチェンジ 隣
のと里山海道
粟崎IC（起点）- 海浜千鳥台交差点 - 海浜向陽台交差点 - 大根布JCT - 内灘IC
アルト (漫画)
『アルト』は、こいおみなとによる日本の漫画作品。『月刊少年シリウス』（講談社）にて連載された。完結後、作者のこいおは事実上断筆。
アルト (漫画) あらすじ
鳥のいない世界。人々は空に憧れたが、飛行機に乗ることを許されたのは若い乙女だけだった。主人公・アルトは、貴族に買われていった母の飛行機に乗るために、パブリックスクール・聖リュート校に入学する。
アルト (漫画) 登場人物
アルト・マッキ (Alto Macchi)
主人公。一人称は「ボク」。語尾に「です」とつけることがある。母親の飛行機に乗るため、自らを14歳の少女と偽りポルトグランテにやってくる。
アンジェラ・メリディオーネ (Angela Meridione)
ポルトグランテ一帯を治めていたメリディオーネ家の令嬢。飛行機を嫌っている。かつてはサンドラという名前の姉がいたが、飛行機事故で死亡している。
マリア・ベルガマスカ (Maria Bergamasca)
アルトが最初に出会った聖リュート校の女生徒で、アンジェラに仕えるメイドでもある。アルトの性別を知りつつも、彼をサポートする。
ビアンカ・ブレダ、ジョイア・ウンブラ
聖リュート校の女生徒たちで、アルトとマリアのルームメイトでもある。彼女たちはアルトが実は男性であることは知らない。
ナスターシャ・フォッカー
セルを使った発動機の開発により巨万の富を築いた、新興財閥の令嬢。アンジェラやアルトが転入する以前から聖リュート校に通い、生徒会長を務めている。
アルト (漫画) 用語
セル
この世界の乗り物の動力源で、ビー玉のような球形をしている。素手で触ることも可能だが、具体的な作動原理については不明。
新しいものは塩水に浸すと浮くが、古くなると塩水に浸しても沈む性質がある。
くびき
セルが機能しなくなるある一定の標高。高地に位置するポルトグランデ周辺の道路においては、くびきが近いことを示す道路標識も存在している。また、本作の世界においてセルを動力源とする自動車やバイクが存在するにもかかわらず、馬車が現役で広く使われている理由の一つとなっている。
アルト (漫画) 単行本
シリウス掲載時とは内容が大幅に異なる。全2巻
ソニック・ザ・ヘッジホッグ (OVA)
『ソニック・ザ・ヘッジホッグ』（SONIC THE HEDGEHOG）は1996年に発売されたOVA（オリジナルビデオアニメーション）。アニメ『ソニックX』の先駆けでもある国内制作でもある。ゲーム『ソニック・ザ・ヘッジホッグCD』が基になっており、ソニック、テイルス、ナックルズ、Dr.エッグマン、メタルソニックとこのOVAのみのオリジナルキャラクターが登場する。
ソニック・ザ・ヘッジホッグ (OVA) 概要
OVAはタキ・コーポレーションからVHSでリリースされた。各巻1話27分収録で全2話。北米ではDVD（編集して1本に纏められている）が発売されているが、日本では未だにビデオ版とバンダイチャンネルからの配信版のみ。Vol.1のセル版にはナイツ関連の特典映像が収録されている。
Vol.1「エッグマンランドへむかえ」（1996年1月26日発売、THC-16411、レンタル版）
Vol.2「ソニックVSメタルソニック!!」（1996年3月22日発売、THC-16421、レンタル版）
Vol.1「エッグマンランドへむかえ」（1996年5月31日発売、THC-16491、セル版）
Vol.2「ソニックVSメタルソニック!!」（1996年5月31日発売、THC-16501、セル版）
ソニック・ザ・ヘッジホッグ (OVA) あらすじ
世界一の俊足を誇るハリネズミのソニックと相棒のテイルス。ある日、彼らの元に大統領とその娘セーラを人質を盾に大統領官邸に立てこもる宿敵ドクター・エッグマンが現れる。そんな世界の危機にソニックたちが立ち上がり、新たな強敵ブラックエッグマンを止めるべく、闇の大地にあるというエッグマンランドへと向かう。そこに2人の旧知の仲でトレジャーハンターをしているナックルズも仲間に加わる。さらにはエッグマンが開発したソニックにそっくりな戦闘ロボットのメタルソニックまで現れ、ソニックは彼を相手に立ち向かうことになる。