キーボードがラテン文字またはキリル文字でラベル付けされており、特に複雑なアルファベット以外のスクリプトを使用して別の言語でテキストを入力する必要がある場合は、Linux入力システムに関するこのメモ（簡略化された「キーボードレイアウト」）が役立ちます。
あいまいな用語については事前におaび申し上げますが、包括的な技術的な説明のふりをすることはありません。 この記事の主な目的は、実装ではなく可能性の説明です。
入力方法
Linuxの主な入力方法（IM）はXKBであり、デフォルトでインストールされ、オペレーティングシステムのインストール後すぐにアクティブになります。 XKBはアルファベットのスクリプトで動作するように設計されており、インドやアフリカでは中国語の文字や音節などの複雑なスクリプトを提供できません。 システムは、4つ以下のレイアウトで動作するように構成できます。 最後の制限は、ホットキー上の各言語に必要なパラメーターの組み合わせでコマンド呼び出しを行うことにより回避できます。
さらに柔軟性が必要な場合は、フレームワーク（入力メソッドフレームワーク）に移動する必要があります。 Linuxのこのようなシステムの主な代表者：IBus、SCIM、Fcitx。 フレームワーク自体はテキストの入力方法を認識していないため、さまざまなスクリプトをプラグイン（エンジン）の形式で接続する必要があります。 IBusとFcitxを使用した経験から、両方のシステムがほぼ同じ数のプラグインをサポートしていると言えます。 多くの場合、これらはほとんど同じプラグインです。 たとえば、中国語のピンイン入力メソッドはスタンドアロンのlibpinyinライブラリとして実装されており、IBusまたはFcitxを介して接続すると、同じ機能が提供されます。
過去6〜7年間で、いくつかの機能が登場する可能性がありますが、フレームワークの違いは平準化されたと推測できます。 次に、メインのIBusプラグインをより馴染みのあるシステムとしてリストします。
まず、IBusはxkbとそのすべての機能を透過的に使用できます。 唯一の問題は、IBusがXKB構成を動的に生成できないことです。 最も一般的なものは、ファイル/usr/share/ibus/component/simple.xml
で事前定義されており、必要に応じて変更および補足できます。 （IBusを更新すると、ファイルは標準のファイルに置き換えられます。）
たとえば、ロシア語のレイアウトは次のとおりです。
<engine> <name>xkb:ru::rus</name> <language>ru</language> <license>GPL</license> <author>Peng Huang <shawn.p.huang@gmail.com></author> <layout>ru</layout> <longname>Russian</longname> <description>Russian</description> <icon>ibus-keyboard</icon> <rank>99</rank> </engine>
layout
加えてlayout
layout_variant
を指定できます。他のsetxkbmap
オプションsetxkbmap
利用できません。これには、 misc:typo
引数を介してxkbで指定されるIlya Birmanの有名なタイポグラフィレイアウトが含まれます。 この制限を回避するか、タスクのレイアウトを作成するには、完全に記述する必要があります。 これを行うには、 /usr/share/X11/xkb/symbols
フォルダーで、 custom
ファイルを作成し（既存のファイルを補足する場合、システムが更新されると上書きされます）、レイアウト構成を設定する必要があります。 たとえば、イリヤバーマンを追加したロシア語：
partial alphanumeric_keys xkb_symbols "ru-typo" { include "ru(winkeys)" include "typo(base)" include "level3(ralt_switch)" // 1th keyboard row key <TLDE> { [ NoSymbol, NoSymbol, U0301, NoSymbol ] }; // "~" };
include
文字列include
、既製のテンプレートから構成を収集します。 したがって、ロシア語のレイアウト「winkeys」のバリアントは、ファイル「ru」から取得されます。 次に、「typo」ファイルの「base」レイアウトで補足され、3番目のレイヤーAltGrのスイッチが設定されます（ファイル「level3」を参照）。これはコマンドに似ています。
setxkbmap -layout ru -variant winkeys -option lv3:ralt_switch,misc:typo
必要に応じて、独自の変更を加えることができます。 上記の例では、アクセント記号 "U + 0301"（結合急性アクセント）はAltGr +〜にレンダリングされています。 NoSymbol
が示される位置は、前のパターンの定義を使用します：「winkeys」の「」と「」、「typo」の「≈」：
key <TLDE> { [ Cyrillic_io, Cyrillic_IO, NoSymbol, NoSymbol ] }; // winkeys key <TLDE> { [ NoSymbol, NoSymbol, NoSymbol, approxeq ] }; // typo key <TLDE> { [ NoSymbol, NoSymbol, U0301, NoSymbol ] }; // custom
次に、作成したレイアウトを次の形式で/usr/share/ibus/component/simple.xml
ファイルに入力する必要が/usr/share/ibus/component/simple.xml
ます。
<engine> <name>xkb:ru:typo:rus</name> <language>ru</language> <layout>custom,us</layout> <layout_variant>ru-typo,</layout_variant> <longname>Russian (with Typo)</longname> <description>Russian (with Typo)</description> <icon>ibus-keyboard</icon> <rank>1</rank> </engine>
ここで、 custom
はフォルダー/usr/share/X11/xkb/symbols
内のファイルの名前で、 ru-typo
はその中に含まれるレイアウトを示します。 ホットキーが正しく機能するように、追加のレイアウトが示されています（Ctrl + C、Ctrl + Vなど）。 IBusを再起動した後（ibus ibus restart
）、新しいレイアウト「ロシア語（タイポ付き）」が設定に表示されます。
2番目の入力方法はm17nです。 これは、さまざまなスクリプト用のキーボードレイアウトのかなり豊富なライブラリです。 IBusには独自の同様のibus -table入力メソッドがあり、これは「わずかに低い機能」と説明されています。 後者を使用して、複雑なロジックを使用せずにラテン文字と必要なアルファベットの文字との間の一意の対応を使用してレイアウトを作成する必要があったため、2つのシステムのどちらがより機能的で表現力があるかを判断できません-m17nまたはibus-table形式でのレイアウトの説明 ibus-tableメソッドには、対応する表記法で文字を入力するための興味深いレイアウト「LaTeX」が含まれています。「 \Delta
」は「Δ」、「 \ge
」は「≥」などです。
次の汎用入力メソッドはKMFLです。 これは、Windows用のKeymanの入力方式の Linuxバージョンです。 最もまれなスクリプトをサポートするあまり一般的なIMではありません。 元のKeymanとは異なり、1000を超えるスクリプトで印刷することが記載されているため、KMFLはそれほど開発されていませんが、有用な場合もあります。 レイアウト記述形式はテキストです。MsWindowsで作成するためのプログラムがあります。 EuroLatinレイアウトを使用します。このレイアウトでは、テキスト「 2//3
」が分数「⅔」に変換され、シーケンス「 -a
」がマクロン「ā」に変換されます。 xkbのComposeキーを思い出させますが、別個の修飾子は必要ありません-KMFL自体がダイヤル中にシーケンスを認識します。
他の入力メソッドは、個別のスクリプトに特化しています：中国語の場合はibus-libpinyin、ベトナム語の場合はibus-unikeyなど。 これらのプラグインの設定も/usr/share/ibus/component/
ます。 対応するファイルでは、基本的なキーボードレイアウトを指定する必要がある場合があります。そうしないと、非ラテン語レイアウトから切り替えると、それらが動作しなくなります。 たとえば、 libpinyin.xml
「layout」パラメーターを見つけて、QWERTYキーボードの場合は「us」、AZERTYの場合は「fr」などを入力する必要があります。
<layout>us</layout>
レイアウトを切り替える
ほとんどの場合、ロシア語-英語、中国語-スペイン語などの言語ペアで作業します。 したがって、最後の2つのレイアウト（CapsLock）を切り替えるホットキーが1つあり、レイアウト自体は個別のホットキー（デジタルブロックではWin + 1 ... 9）によって切り替えられます。 したがって、まず、作業レイアウトWin + 1（en）とWin + 2（ru）を設定し、次にCapsLockで切り替えます（en <-> ru）。
IBusでは、2つのホットキーを設定できます。1つはレイアウトのリストを循環的に切り替えるためのもので、もう1つは最後の2つのレイアウトのためのものです。 コンソールから目的のレイアウトを選択し、それに応じてスクリプトをホットキーに割り当てることもできます。
IBusがこれらの設定をリセットするため、xmodmapを使用したxmodmap
再割り当ては機能しないことに注意してください。 したがって、私はudev
介してCapsLockをF14（ファイル/etc/udev/hwdb.d/90-custom-keyboard.hwdb
）としてグローバルに再定義udev
ことを好みます。
evdev:input:b0003v1A2Cp0E24* # my keyboard id KEYBOARD_KEY_70039=f14 # bind capslock to f14
そして、IBusで既にF14をホットキーとして使用します。 私の経験では、これは最も安定した構成を提供します。
udevの構成の詳細については、記事の最後を参照してください。
仮想キーボード
特定の書記体系用にマークアップされたキーボードは、ロシア語（YTsUKEN）など、多数のユーザーがいる言語でのみ工業的に生産されています。 アルメニアでもジョージアでも、国のアルファベットの文字で署名されたキーを備えたキーボードを購入することはできません。 同様に、カザフスタンとウズベキスタンでは、ロシア語と英語のキーボードを使用し、標準のラテンまたはキリル文字に含まれていない文字がどこにあるかを学ぶことを余儀なくされています。
新しいレイアウトをマスターしている場合は、仮想キーボードを使用することをお勧めします。 Onboardは、アクティブなレイアウトに適応し、別のレイアウトに切り替えると更新されるため、気に入っています。 ただし、これはxkbでのみ機能します（IBus経由でxkbを使用する場合も同様）。
オンボードは、xkbレイアウトのテストに非常に便利で、すべてのレイヤー（AltGrなど）で割り当てられたシンボルを確認できます。
おわりに
すべてのプログラムが言語フレームワークを正しくサポートしているわけではありません。 特に、Sublime Text 3はSCIMでのみ動作し、IBusを使用すると、選択されたレイアウトに関係なく、ラテン文字のみが印刷されます。
私はかなり前からIBusを使用していますが、他のシステムを非常に表面的に知っています。 インターネットのレビューによると、Fctixはより機能的で、中国語のテキストを入力するのにより適していると説明されています。 いずれにせよ、中国語のテキストを使用する場合、IBusは私に完全に合っており、違いは原則としてはなりません。 前回Fctixを使用する必要があった（2年前）とき、このフレームワークでは、カーソルがテキストフィールドにない場合にレイアウトを切り替えることができませんでした。 このバグが修正されたことを願っています。
さまざまなスクリプトを操作するためのもう1つの助けは、シリコンキーボードオーバーレイです。 中国のオンライン市場では、さまざまなスクリプト用のApple Magic Keyboard用のオーバーレイ（保護护膜または键盘膜）が提供されています。 中国以外のディストリビューターの例。 しかし、3世代のApple Magicが生産され（そして、それぞれアメリカ、ヨーロッパ、および日本のバージョンで）、中国のレプリカは線形の寸法とキーの配置が異なることに注意してください。 時々、コンピューターのキーボードに単一の標準がないことを後悔しています。
押されたキーのデジタルコードは、その値を数回変更します。
- scancode：キーが押されると、キーボード（またはドライバー？）がLinux カーネルにスキャンコードを送信します 。
- キーコード：次に、カーネルで、 スキャンコードが キーコードに変換されます（Linux入力APIサブシステム）。 プログラムudev 、 keyfuzz 、 setkeycodesを使用して変換を制御できます。
- keysym： X Window Systemは、カーネルからキーコードを受け取り、それをkeysymに変換します-これは、クライアントプログラムが入力として受け取る最終文字です。 変換は、XKBまたはxmodmap（非推奨）を介して構成されます。
上記のシーケンスから、 スキャンコード > キーコードの段階でキーを再割り当てすることが望ましいことがわかります。これは、KXBとの交差を引き起こさないためです。
スキャンコードからキーコードへの変換は、各入力デバイスごとに個別に変換されるため、最初にキーボードの一意の識別子を見つける必要があります（実際、evdevは、マウスからプリンター、ウェブカメラまでのボタンを備えた大規模な周辺機器でも動作します）。 Arch Linuxユーザーは次のスクリプトを使用できます（他のディストリビューションの場合、パスの調整が必要な場合があります）。
#!/bin/sh for DEVICE in /dev/input/by-id/*; do echo $(basename $DEVICE) DEVID=$(basename $(readlink $DEVICE)) printf "evdev:input:b%sv%sp%se%s*\n\n" \ `cat /sys/class/input/$DEVID/device/id/bustype` \ `cat /sys/class/input/$DEVID/device/id/vendor` \ `cat /sys/class/input/$DEVID/device/id/product` \ `cat /sys/class/input/$DEVID/device/id/version` done
同じデバイスは、異なる名前で複数のインスタンスでシステム内に表すことができますが、識別子は同じになります。 たとえば、私のキーボードは2つのデバイスとして定義されています。
usb-SEM_USB_Keyboard-event-if01 evdev:input:b0003v1a2cp0e24e0110* usb-SEM_USB_Keyboard-event-kbd evdev:input:b0003v1a2cp0e24e0110*
注：識別子は（たとえば、 b0003v1a2cp0e24*
）減らすことができます。これは、同じタイプの一連のモデルの統一ルールを作成するときに役立ちます。 ここでのアスタリスク「*」はワイルドカードの役割を果たします。
ここで、 90-custom-keyboard.hwdb
ファイルを/etc/udev/hwdb.d/
に次の内容で作成する必要があります（サンプルについては/usr/lib/udev/hwdb.d/60-keyboard.hwdb
参照してください）。
evdev:input:b0003v5c0ap0003e0110* # KEYBOARD_KEY_70039=f14 #
行KEYBOARD_KEYはスペースで始まります。これは重要です。 構成を更新します。
sudo udevadm hwdb --update && udevadm trigger
その後、デバイスを再起動または再接続すると、構成が自動的に更新されます。
キーの再割り当ては、 KEYBOARD_KEY_<scancode>=<keycode>
ペアで定義されます。 キーコード値（小文字で必要）は/usr/include/linux/input-event-codes.h
14.04の場合/usr/include/linux/input.h
）にあります。
evtestプログラムを使用してスキャンコードを取得できます。 まず、eventXX番号を特定する必要があります。これを行うには、コマンドを実行してキーボードを見つけます。
> ls -l /dev/input/by-id/ … usb-SEM_USB_Keyboard-event-if01 -> ../event11 usb-SEM_USB_Keyboard-event-kbd -> ../event10 …
「Keyboard-event-kbd」を選択し、目的の番号（この例では10）を見つけます。 これで、evtestを使用できます。
> sudo evtest /dev/input/event10 … Event: time 1531562530.720076, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70039 …
「CapsLock」キーを押すと、コードは「70039」になります-これが目的のスキャンコードです。