【ITニュース解説】BiDirectional text in the terminal emulators and console programs(2020)

ターミナルエミュレータやコンソールプログラムにおける双方向テキスト（BiDirectional text、略してBiDi）の扱いに関するニュース記事の内容は、日々の開発作業で使う身近なツールに潜む、多言語対応の複雑な技術的課題を明らかにしている。システムエンジニアを目指す皆さんにとって、この問題はコンピュータシステムの設計がいかに奥深いかを理解する良いきっかけとなるだろう。

まず、ターミナルエミュレータとは、皆さんが普段コマンドを入力したり、プログラムの実行結果を表示したりする、黒い画面のアプリケーションのことだ。これは、かつて物理的な端末装置として存在したものをソフトウェアで再現している。多くのターミナルは、文字を固定された幅（モノスペースフォント）で、格子状（グリッド）に並べて表示するという、比較的シンプルな仕組みで動いている。

次に、この問題の核心である双方向テキスト（BiDiテキスト）について説明する。世界には、日本語や英語のように左から右へ文字を書く言語（LTR言語）と、アラビア語やヘブライ語のように右から左へ文字を書く言語（RTL言語）が存在する。BiDiテキストとは、これら異なる記述方向のテキストが混在している状態を指す。例えば、アラビア語の文章の中に英語の単語や数字が挿入されているようなケースだ。現代のウェブブラウザやテキストエディタでは、このようなテキストが自然に表示されるが、これは背後で高度な処理が行われているためだ。

ここで重要な概念が、「論理的な順序」と「視覚的な順序」の違いだ。コンピュータのメモリ上では、文字は常に一定の順序で並んでおり、これが「論理的な順序」である。しかし、BiDiテキストの場合、画面に表示される際には、特定のルールに基づいて文字の並び順が入れ替わる。これが「視覚的な順序」だ。この表示順序を決定するために、世界中の文字を扱うための国際規格であるUnicodeが定めた「BiDiアルゴリズム」という複雑なルールが用いられる。このアルゴリズムは、RTL言語とLTR言語の区別、数字や記号の扱いなどを考慮して、最終的な表示順序を計算する。

では、なぜターミナルでBiDiテキストの表示が難しいのだろうか。その主な理由は、ターミナルが、文字をグリッド上に単純に表示することを前提とした設計になっているためだ。つまり、「メモリ上の文字データを左から順にグリッドに配置する」という非常に簡素な表示モデルが一般的である。このモデルでは、UnicodeのBiDiアルゴリズムが要求する複雑な文字の並べ替えや、それに伴う文字の形の変化（文字の結合や変形、いわゆる「合字（リガチャ）」や「再整形（リシェイピング）」）をうまく処理できないのだ。

具体的な課題として、いくつか挙げられる。 一つはカーソルの移動だ。RTL言語とLTR言語が混在する行で、右矢印キーを押した場合、カーソルは論理的に次の文字に進むべきだが、視覚的にはどの方向に動くべきかをターミナルがBiDiアルゴリズムを理解していなければ判断できない。結果として、カーソルが直感とは異なる動きをしたり、テキストの途中を飛び越えたりする現象が発生しうる。

もう一つはコピー＆ペーストの問題だ。ターミナル上でBiDiテキストの一部を選択してコピーし、別の場所に貼り付ける際、表示されている視覚的な順序でコピーされるべきなのか、それとも意味を保つための論理的な順序でコピーされるべきなのかという問題がある。一般的には論理的な順序が望ましいが、ターミナルがこの違いを正しく扱えないと、貼り付けられたテキストが混乱したものになる可能性がある。

さらに、**文字の整形（リシェイピング）**も大きな課題だ。特にアラビア語のような言語では、文字が前後の文字と結合して形を変えたり、文脈に応じて文字の形が変化したりする「合字」や「再整形」が不可欠だ。現代のウェブブラウザやワードプロセッサではこれらが当たり前だが、文字を単純なグリッドセルに配置するターミナルでは、このような高度なテキスト整形機能を持つことが稀だ。そのため、BiDiテキストに含まれるRTL言語の文字が不自然な形で表示されたり、本来の文字の繋がりが失われたりすることがある。

現在の多くのターミナルエミュレータは、BiDiテキストに対して限定的なサポートしか提供していない。人気の高い「xterm」や「Gnome Terminal」なども、部分的な対応にとどまっており、前述のグリッドベースのシンプルな表示モデルという根本的な制約が影響している。一部の高度なテキストエディタのターミナルモード（EmacsやVimなど）や、特定のターミナル（mltermなど）では、外部のライブラリ（FriBidiやICUなど）を利用してBiDiアルゴリズムを処理することで、より進んだサポートが実現されている場合もある。

この問題に対する理想的な解決策としては、二つのアプローチが考えられる。一つは、ターミナルエミュレータ自体が、Unicode BiDiアルゴリズムと、HarfBuzzのような高度なテキスト整形エンジンを完全に実装することだ。これにより、ターミナルは表示するテキストの論理的な意味を理解し、複雑なBiDiルールや文字の再整形を適切に処理できるようになる。もう一つは、ターミナルで動作するアプリケーション側が、BiDiテキストの処理と整形をすべて行い、最終的に整形済みのグリフ（表示される最小単位の図形）をターミナルに送るというアプローチだ。しかし、これはターミナルの役割を逸脱し、アプリケーション側に大きな負担をかけることになる。

Gnome TerminalのバックエンドであるVTEやiTerm2など、最近のターミナルエミュレータではBiDiサポートの改善に向けた取り組みが進められている。しかし、ターミナルが持つ基本的な制約と、既存のシステムとの互換性を維持する必要性から、この課題は依然として完全に解決されているわけではない。

このBiDiテキストの問題は、システムエンジニアを目指す皆さんにとって、単なる表示の不具合以上の意味を持つ。これは、コンピュータシステムの設計が、いかに多様な言語や文化に対応する必要があるか、そしてその対応がいかに技術的な複雑さを伴うかを示している。また、既存のシステムの制約の中で、いかに新しい要件（ここでは多言語対応）を実現していくかという、設計と実装の課題の典型例とも言える。普段何気なく使っているターミナルにも、このような深い技術的課題が潜んでいることを知ることで、皆さんの技術的な視野が広がることを期待する。