画面からでも、端末がサポートするUnicodeの量を検出します
ここに問題があります：私の端末がまともなユニコードに対応しているかどうかを確認できるようにしたいのですが、Glanceのように、一部の文字を使用するために、色や下線を使用することがあります。
どんな種類の仮想端末でもまともなフォントを取得するために動機が生じますが、基本的なLinuxコンソールには256または512の同時シンボルの文字セットがあることを理解しているため、完全なフォントのサポートは期待できません。
最初は$TERMまたはttyですが、ここに問題があります。私はbyobuも使用しているので、$TERMは常に「screen.linux」です。 ttyの出力もあまりわかりません：/dev/pts/<some number>「現実」と仮想の両方の用語で。
$BYOBU_TTYも役に立ちません。たとえば、そうかも知れない /dev/tty1そしてセッションが開かれたとき Ctrl+Alt+F1 文字は表示されませんが、あるX用語から同じセッションにアタッチすると、正しく表示され、それでも$BYOBU_TTYは変わりません。また、屏風の有無を推測せずに検出できるようにしたいと思います。
また、ロケールはすべての場合にen_US.UTF-8を表示します
それでも、byobuの内部であっても、どういうわけか（特定のツールでこれを検出しているように見えます）は、byobuセッションに接続している端末に応じて異なる出力を使用します。
ターミナルとttyがあまりにも一般的な検索用語のように見えるので、私はグーグルで問題を抱えています。せいぜい$TERMまたはtty。
さて、最初に私は、最近のほとんどすべての端末は、あなたが話す意味で「仮想」であると指摘します...端末が真正なシリアルポートの反対側にある場合でもです。つまり、 VT-1 s、 Wyse 端末、およびその他の「物理的な」「本物の」端末の時代はほとんどなくなっています。
それはさておき、端末がどのようなUnicodeサポートを持っているかを検出したいとします。これを行うには、テスト文字をisに書き込み、何が起こるかを確認します。 （その時点で書き込んだ後でテスト文字を消去するように努力することはできますが、それでもユーザーに短時間表示されるか、そもそも消去が適切に機能しない可能性があります。）
アイデアは、端末にカーソル位置を教えてもらい、テスト文字を出力し、もう一度端末に位置を教えてもらい、2つの位置を比較して、端末のカーソルがどれだけ移動したかを確認することです。
端末にその位置を尋ねるには、 ここ を参照してください。基本的に：
echo -e "\033[6n"; read -d R foo; echo -en "\nCurrent position: "; echo $foo | cut -d \[ -f 2
「é」を出力してみてください。この文字はUTF-8では2バイトかかりますが、画面の1列にしか表示されません。 「é」を出力するとカーソルが2桁移動することが検出された場合、端末はUTF-8をまったくサポートしておらず、おそらく何らかのゴミを出力しています。カーソルがまったく移動しなかった場合、端末はおそらくASCIIのみです。1ポジション移動した場合、おめでとうございます。フランス語の単語が表示される可能性があります。
「あ」を出力してみてください。この文字はUTF-8では3バイトかかりますが、画面の2列にしか表示されません。カーソルが0または3移動すると、上記と同様に悪いニュースになります。 1移動すると、端末はUTF-8をサポートしているように見えますが、ワイド文字（固定幅フォント）については認識していません。 2列移動すれば問題ありません。
あなたが発することができる他のプローブ文字があり、それは有用な情報につながると確信しています。これを自動的に行うツールを私は知りません。
OPの実際の質問は次のとおりです。LinuxコンソールがサポートするUnicode値は何ですか。また、screenの実行中にこれらの値を検出できます。原則として、コンソールのUnicodeマップを取得することでこれを行うことができます。
kbdソースツリーには getunimap （およびそのマニュアルページ）が含まれています。マニュアルページには、
Getunimapプログラムは古く、時代遅れです。現在はsetfontの一部です
これは正確には当てはまりません。 setfont には、大まかに同じことを行うオプションがあります。
-ou file
Save previous Unicode map in file
違い：
setfontはファイルに書き込み、getunimapは標準出力に書き込みますgetunimapは、マップされる文字をコメントとして示します。
例えば：
0x0c4 U+2500 # ─
0x0c4 U+2501 # ━
0x0b3 U+2502 # │
0x0b3 U+2503 # ┃
0x0da U+250c # ┌
0x0da U+250d # ┍
0x0da U+250e # ┎
0x0da U+250f # ┏
0x0bf U+2510 # ┐
0x0bf U+2511 # ┑
0x0bf U+2512 # ┒
0x0bf U+2513 # ┓
0x0c0 U+2514 # └
0x0c0 U+2515 # ┕
0x0c0 U+2516 # ┖
0x0c0 U+2517 # ┗
versus
0xc4 U+2500
0xc4 U+2501
0xb3 U+2502
0xb3 U+2503
0xda U+250c
0xda U+250d
0xda U+250e
0xda U+250f
0xbf U+2510
0xbf U+2511
0xbf U+2512
0xbf U+2513
0xc0 U+2514
0xc0 U+2515
0xc0 U+2516
0xc0 U+2517
screenで実行している場合（または、たとえば、コンソールでxtermおよびnotを実行している場合）、次のようになります。 Sudoを使用して回避できる権限エラー。
ロードされたフォントがわかっている場合は、 psfgettable を使用して（特別な権限なしで）確認できます。例：
zcat /usr/share/consolefonts/Lat2-Fixed16.psf.gz | psfgettable -
setfontがフォントをロードするために使用するマッピングデータを確認します（Unicodeマッピングを使用）。
#
# Character table extracted from font -
#
0x000 U+00a9
0x001 U+00ae
0x002 U+00dd
0x003 U+0104
0x004 U+2666 U+25c8 U+fffd
0x005 U+0105
0x006 U+0111
0x007 U+0150
0x008 U+0151
0x009 U+0162
0x00a U+0164
0x00b U+0170
0x00c U+0171
0x00d U+021a
0x00e U+02dd
0x00f U+2014 U+2015
0x010 U+2020
0x011 U+2021
0x012 U+2022 U+25cf
...
getunimapとsetfontはどちらもデータを並べ替えずに提供しますが、psfgettableは並べ替えられているように見えます（同じグリフにマップするUnicode値の行を組み合わせる場合も同様です）。したがって、違いはありますが、情報にはアクセスできます。
さらに読む（この問題を解決するためにshowconsolefontを使用できない理由を説明する）：
同じことを達成しようとしているときにこの質問に出くわしましたが、画面に何も残さずに変数を設定したくなかったので、次のコードをソースのシェルスクリプトに追加しました。
function test_unicode {
echo -ne "\xe2\x88\xb4\033[6n\033[1K\r"
read -d R foo
echo -ne "\033[1K\r"
echo -e "${foo}" | cut -d \[ -f 2 | cut -d";" -f 2 | (
read UNICODE
[ $UNICODE -eq 2 ] && return 0
[ $UNICODE -ne 2 ] && return 1
)
}
test_unicode
RC=$?
export UNICODE_SUPPORT=`[ $RC -eq 0 ] && echo "Y" || echo "N"`
unset test_unicode