有効なシェル\u（bash +4.3、ksh93、またはzsh）では、Unicode文字を印刷できます。
$ printf 'a b c \ua0 \ua1 \ua2 \ua3 \n'
a b c ¡ ¢ £
どれ出身かラテン語-1_補足範囲。
ただし、Unicode文字が追加されると、Unicodeが9f印刷されるまで印刷は停止します。9c
そして（APCとST）\u9fは\u9cC1制御文字。
$ printf 'a b c \u9f d e f \u9c \ua0 \ua1 \ua2 \ua3 \n'
a b c ¡ ¢ £
キャラクターは必ず消えるようになります。
確かに、printfすべての文字が生成され、端末の代わりに別のソフトウェアに出力をリダイレクトすると、生成された文字が表示されます。
$ printf 'a b c \u9f d e f \u9c \ua0 \ua1 \ua2 \ua3 \n' | od -A n -tx1
61 20 62 20 63 20 c2 9f 20 64 20 65 20 66 20 c2
9c 20 c2 a0 20 c2 a1 20 c2 a2 20 c2 a3 20 0a
これはキャラクターが作成されているという十分な証拠です。それでは、なぜ印刷されないのですか（いくつかの目立つ文字の形で表示されます）？
私の質問は次のとおりです
- 実際には.where
APCに接続されていますST。定義されていますか？ - これらの間の文字は一部のアプリケーションに送信されますか？
- では、どのアプリケーションに適用されますか？
- このリダイレクトの責任は誰にありますか？シェル、ターミナルなど。
編集する
xterm端末または端末の両方が文字をkonsole削除しません。d e f
これは、シェルではなく端末アプリケーションの内部問題であることを確認します。まだ定義された場所が見つかりませんでした。
答え1
APCは実際にSTに接続されていますか？どこで定義されていますか？
これらの制御文字は実際には Unicode の基本文字ではありませんが、次のような古い文字セット仕様から継承されます。ECMA-48、ISO/IEC 6429およびISO/IEC-8859文字エンコーディングシリーズ。広く言えば、これらの標準は基本的にC1制御文字で互いに一致します（お互いといくつかの以前の仕様とは以前のバージョンと互換性があるため）。
ISO/IEC 6429のコピーが販売されているため、インターネット上で無料で合法的なコピーを見つけることは期待できませんが、ECMA-48では次のように述べています。
8.3.2 APC - アプリケーションコマンド
記号: (C1)
代表者：09/15またはESC 05/15
APC は、アプリケーションで使用される制御文字列の開始区切り文字として使用されます。次のコマンド文字列は、00/08〜00/13および02/00〜07/14の範囲のビットの組み合わせで構成できます。制御文字列は終了区切り記号STRING TERMINATOR（ST）で閉じられます。コマンド文字列の解釈は、関連するアプリケーションによって異なります。
そして：
8.3.143 ST——文字列終端者
記号: (C1)
代表者：09/12またはESC 05/12
STは、APC（アプリケーションコマンド）、DCS（デバイス制御文字列）、OSC（オペレーティングシステムコマンド）、PM（個人メッセージ）、またはSOS（文字列の開始）によって開かれる制御文字列の終了区切り文字として使用されます。
Unicode は、C1 制御文字範囲内の 1 つの制御文字 (U+0085 次行 (NEL)) のみを定義します。 C1の範囲内の他の文字の場合、仕様のこの部分適用可能：
制御コードの意味は、通常、そのコードが使用されるアプリケーションによって決まります。ただし、特定の適用がない場合は、ISO / IEC 6429：1992で指定されている制御機能の意味に従って解釈されることがあります。
ここでは確認できませんが、上記のように、ISO / IEC 6429はECMA-48が言うものと非常に似ていると予想しています。また、ターミナル作成者は、「ECMA-48などのUnicode以前の7ビットおよび8ビット文字エンコーディングとの逆互換性」を検討した可能性があります。特定のアプリケーション。
したがって、端末はAPCとSTの間の文字を「この文字の目的はわかりませんが、この文字が一般出力として表示されることを意図されていない」と合法的に解釈することができます。
端末は、特定の方法で反応するようにプログラムされても、プログラムされなくてもよい。特定の文字列APCとSTの間をラップし、一致しない文字列を無視します。ターミナルウィンドウは「人類以前の最後の段階」なので、当然どんな推測も可能だ。アプリケーションコマンドここに到達する文字列は、端末がタスクを解釈して実行するためのものです（該当する場合）。端末が認識しない文字列はエラーでなければなりません。
文字列が「アプリケーション固有の制御文字列」として有効にエンコードされているため、「無効なエンコード」文字やその他のエラーメッセージを表示することは不適切です。展示用ではありませんだから、タイトルの質問「キャラクターはどこに行きますか？」「答えはおそらくこれです。無効な制御文字列の一部として削除されます。。
しかし、Unicode仕様には「...可能「...」の代わりに「...」と解釈されます。〜しなければならない解釈済み...". したがって、他の端末実装で適用可能な意味のない印刷できない制御文字でAPCおよびST文字を無視するように選択することは必ずしも有効ではない。
スタックオーバーフローに関するこの質問APCおよびST制御文字に関連する制御シーケンスも説明します。
そこに許容される答えは次のとおりです。
現実は、APCがほとんど実装されていないということです。ほとんどのシステムはAPCシーケンスを生成せず、受信したシーケンスを自動的に無視します。接続のもう一方の端が設定オプションを介して有効にするなど、特定の方法でAPCシーケンスを使用していることを知らない限り、どのアプリケーションもAPCシーケンスを送信または解釈しないでください。端末エミュレータは特定の意味を割り当てます[...]
答え2
この文字はどこにも送信されず、まったく送信されません。見せるために出力にありますが、端末を介して次のことを行います。
$ printf 'a b c \u9f d e f \u9c \ua0 \ua1 \ua2 \ua3 \n' | od -c
0000000 a b c 302 237 d e f 302
0000020 234 302 240 302 241 302 242 302 243 \n
0000037
ファイルにリダイレクトしてからファイルを調べて、出力にそのエントリがあるかどうかを確認することもできます。
$ printf 'a b c \u9f d e f \u9c \ua0 \ua1 \ua2 \ua3 \n' > file
$ od -c file
0000000 a b c 302 237 d e f 302
0000020 234 302 240 302 241 302 242 302 243 \n
0000037
端末が実装\u9fに応じて組み合わせて行うことのように見えます。\u9cそんなことが起こるあなたの端末は数文字後ろに移動し、そこから印刷を続けてそれを処理するので、他の文字を上書きします。これが次の理由です。
$ printf 'a b c \u9f d e f \u9c \ua0 \ua1 \ua2 \ua3 \n'
a b c ¡ ¢ £
これを で再現できますが、空白だけがgnome-terminator印刷xtermされます。
$ printf 'a b c \u9f d e f \u9c \ua0 \ua1 \ua2 \ua3 \n'
a b c d e f ¡ ¢ £
スクリーンショットにも同じことがあります。
これは、より明確なケースで発生するものと似ています。入力する（\r）の役割は、行の先頭に戻すことです。これがまさにあなたが得る理由です：
$ printf '12345\r67890\n'
67890
端末は印刷を開始して12345から\r上書きして行の先頭に戻します。12345したがって67890、表示されるのはこれがすべてです67890。しかし、132345それは他のプログラムに転送されず、まだそこにあり、他の文字がそれを覆っているので、見えないだけです。
$ printf '12345\r67890\n' | od -c
0000000 1 2 3 4 5 \r 6 7 8 9 0 \n
0000014
答え3
UTF8文字シーケンスを出力するコマンドと、ターミナルエミュレータウィンドウ（しばしば「マイターミナルウィンドウ」と呼ばれる）に表示されるディスプレイを解釈しています。
すると、説明した文字のセットが端末エミュレータウィンドウに結果を表示しないようです。 「この文字はアプリケーションに送信されていますか？」と尋ねます。
はい、端末エミュレータに渡され、受信した文字の順序を解釈し、ウィンドウに表示する文字の外観を決定します。