私は（顔を合わせて）見つけたこれ質問）入力方法に関連する2つの単語は次のとおりです。シム&まあ。私はX入力方式と汎用入力方式という名前だけを知っています。
知りたい使い方、機能、作業の面でximとuimの違いは何ですか？
答え1
主な違いは、ほとんどの入力システムがサーバークライアント実装であり、uimが単なるライブラリであることです。
ほとんどのユーザーには、入力方式のシステムがまったく必要ないか、単純なテーブルベースのコンバータが必要です。これらのユーザーは、複雑な入力方式システムをインストールする必要もなく、インストールしたくないので、私たちはuimを単純に保ちたいと思います。
詳細な手順については、公式Githubページをご覧ください。
Uimは、さまざまなスクリプトをサポートし、anthy、canna、prime、またはskk（日本語）、pinyin（中国語）、byeoru（韓国語）など、さまざまな入力方法のフロントエンドとして使用できる入力メソッドモジュールライブラリです。とm17n（他の多くの場合）言語）。ほとんどの機能はソリューションを使用して実装されているため、非常にシンプルで柔軟です。源泉
XIMはどうですか？ XIMはかなり古い入力方式プロトコルです。 ibusとfcitxは、従来のサポートの理由でのみこれを実装します。今、これら2つの代わりにXIMを使用する理由はありません。 GTK_IM_MODULE="xim" を設定する唯一の理由は、GTK のハードコードされた ComposeKey 設定をオーバーライドするためです。源泉
答え2
この質問に答える方法はさまざまです。これは不完全で偏った答えです。
長い話を短くシム古くて古く、テキスト交換にUnicodeを使用している多言語の世界には適していません。まあこれらのすべての制限を解決するように設計された多言語キーボード入力が前進しています。
ASCII文字セットで話を始めましょう。 1970年代とそれ以前のASCIIには、一連の文字を8ビットにエンコードする2つの方法があり、別の競合他社はEBCDICでした。私の考えでは、ASCIIがEBCDICよりも勝利する原因は2つありました。 1つ目はASCIIには7ビットしか必要ないため、8番目のビットをパリティに使用できることです。データ接続が毎秒300ビットを送信し、エラーが発生しやすいモデムを使用する場合は、12.5％の圧縮を達成し、エラー検出と修正を提供することが重要です。 EBCDICは8ビットをすべて使用します。もう一つのことは、EBCDICが当時大きな独占であったIBMによって設計され、宣伝されたことです（多くの人は、Windowsがほとんど独占に近い勝利を収めず、単独で独占から抜け出すためにIBMに提供したと言います）。 ASCIIはテレタイプマシンに由来していましたが、AT&Tはそれと多くの関係があり、AT&TはIBMにとっても友好的ではなく、Unixを発明しました。
何らかの理由で、ASCIIはインターネット、Unix、最終的にWindowsおよびAppleコンピュータで勝利しました。しかし、これらのツールが広がるにつれて、標準ローマ以外の文字を含める必要性が生じ始めました。民族中心的だが当時関心を集めた実用的な解決策は、ASCII（256文字は8ビットまたは1バイト（コンピュータ処理の自然単位）で表される）に予約された128文字スペースを使用して英語以外の言語バリアントを追加することでした。 à、ç、ñ、Öなどのローマのアルファベットは、当時は良いことでしたが、後でUnicodeに深刻な問題を引き起こしました。
それにもかかわらず、XIMはある意味ではX11の元の入力方法である古代のものであり、この時代精神に構築されました。ここで、「文字」は8ビットと文字エンコーディングテーブルで表されると仮定しました。 （文字エンコーディングテーブルを使用すると、128の非ASCII文字コードを異なる方法で解釈できます。有名なWindowsの使用Windows-1252Appleが使用するときマイクロロマン。 ISOは次のように標準化を試みます。ISO-8859-1しかし、それはうまくいかず、結果としてUnicodeとUTF-8が誕生しました。 )
それ以来、長年にわたり、Unicodeコンソーシアムは、世界中のすべての言語（および一部の構成言語）のすべての文字をカバーし、数十年間のレガシーコード以前のバージョンとの互換性を維持する文字エンコーディングシステムを設計するための優れた作業を行ってきました。来ました。 。バイトあたり1文字です。シムのように。 ASCIIは依然としてコンピューティングの分野で支配的な英語で書かれているので、多くの人々は今も古いツールを使用して今日でも探しています。
Unicodeのサポートを追加することは、言語が複雑で多数の規則を持っているので難しいです。一部は左から右に、一部は右から左に、一部は双方向に、一部は上から下に進みます。その後、文字に追加のマークがあります。たとえば、¨ドイツ語では のようにウムラウトですが、üオランダでは のようにトレマですë。では、ドイツ語でuとüをどのように並べ替えますか？オランダ語のeとëにも同じ規則が適用されますか？これは継続して行われます。したがって、この種のタスクにさまざまなサポートを提供する多くのツールがあります。
特に、ximおよびuimの場合、最初に切り取られた文字（例えば、îやñ）は、今日のほとんどのソフトウェアで文字と見なされる単一のUnicode「コードポイント」として表されます。 Unicodeでñを調べると、「チルダ付きのラテン小文字N」というコードポイントであることがわかります。しかし、ある時点で、Unicodeは文字とトークンの組み合わせが多すぎて単一のコードポイントにするには多すぎることに気づきました。だから彼らは「分音符を結合する」というアイデアを出しました。文字と表示を組み合わせて表示文字を形成する方法です。人々が文字だと思うもの（Unicodeでは文字小文字と呼ばれる）は、文字と1つ以上の結合トークンで構成できるようになりました。これは、次のようにさまざまな文字を生成する方法を提供します。この投稿。これでñ（U + 00F1）またはñ（U + 006E U + 0303）を入力でき、形状と意味も同じですが、コンピュータで異なる処理を行うため、まだ問題があります。ただし、少なくとも現在、Unicodeコンソーシアムに別の文字ペアを追加するように要求することなく、Gəまたはgəを入力できます。
ただし、これを行うと、単一文字が単一のコードポイントと同じであるというximと多くの関連コードが書かれている基本的な仮定が壊れます。 X11とximは単一文字のñ出力に適応できますが、~nこれはかなりの書き換えなしで達成できる制限です。 uimは、すべてのUnicodeの複雑さを処理するためにUnicodeの世界に構築されたオーバーライドです。
ximの代わりにuimを使用するには、プロファイル、xprofile、またはxinitrcに次を追加します。
export GTK_IM_MODULE=uim
export QT_IM_MODULE=uim
uim-xim &
export XMODIFIERS=@im=uim
これはシステムによって異なりますが、Googleを介して特定の状況に合ったより完全なガイドラインを見つけることができます。