web-dev-qa-db-ja.com

端末に対する$ LANGの影響

私は学習をしようとしています$LANG変数はgnome-terminal（およびその文字エンコーディング設定オプション）で動作します。私はメインの文字セットとしてiso8859-1（latin1）を使用しており、すべてのファイル名はそのようにエンコードされています。

次のテストでは、ls -lファイル名にスペイン語のアクセント付き文字が含まれるディレクトリ：

ケース＃1：

  • iSO-8859-1用に構成されたgnome-terminal
  • LANGを「en_US-iso8859-1」に設定
  • 結果：すべてのファイルが正しく表示されます

ケース＃2：

  • uTF-8用に構成されたgnome-terminal
  • LANGを「en_US-iso8859-1」に設定
  • 結果：すべてのスペイン語の文字に文字化けが表示されます。端末の文字エンコーディングを変更したので、これは予想されます

ケース＃3：

  • iSO-8859-1用に構成されたgnome-terminal
  • LANG「en_US-UTF-8」に設定
  • 結果：すべてのスペイン語の文字に文字化けが表示されます。

この最後のケースで文字化けした文字が表示されるのはなぜですか？ lsの出力は、ファイル名をそのままgnome-terminalに直接送信しませんか？そして、gnome-terminalはISO-8859-1用に構成されているので、それらが正しく見えることを期待していました。

一瞬、多分bashが私の$LANG変数といくつかの変換を実行します。次に、端末をUTF-8に切り替えましたが、文字が正しく表示されません。私はlsの出力をxxdにパイプしましたが、驚いたことに、ファイルがISO-8859-1であるようにエンコードされているのがわかります。

まとめ：リストにISO-8859-1文字が含まれていて、ターミナルエミュレーターが同じ文字エンコード用に構成されている場合：LANGが設定されていない場合、誰が変換を行っていますか？

あなたが提供できるあらゆる助けをありがとう。

クラコニア

terminalcharacter-encodinggnome-terminallocaleterminal-emulator
11
Craconia

LANGの設定は、端末の設定と一致する必要があります。より正確には、LC_CTYPE（文字エンコーディング）の設定は端末のエンコーディングと一致する必要があり、他のロケール設定は一致する必要はありません。また、端末のエンコーディングは通常、ロケール変数ではなく、端末エミュレータのオプションによって指定されます。 LC_CTYPEは2つの指示を組み合わせます。これは、アプリケーションで端末で使用するエンコーディング（入力と出力の両方）を通知することと、ファイルで使用するエンコーディングをアプリケーションに通知します。ケース2と3では、ターミナルとは異なるエンコーディングで出力を表示するようにlsに指示したため、出力が文字化けします。

UTF-8エンコードとlatin-1エンコードの両方を別々に使用する場合は、UTF-8を使用するように端末を構成してください。これにより、LC_CTYPEがUTF-8を示す値に設定されます。この設定を上書きしないでください。 （ターミナルエミュレーターがLC_CTYPEを設定しない場合は、シェルのスタートアップファイルまたはセッション全体でオーバーライドしてください。）UTF-8ターミナルでlatin-1データを操作するには、 luit （Xユーティリティスイートに含まれています）。

LC_CTYPE=en_US.iso88591 luit

（LC_CTYPE=es_ES.iso88591 luitなど、同じエンコーディングのその他のロケールを使用できます。）

5
Gilles 'SO- stop being evil'

＃2と＃3のケースでは、2つの異なるエンコーディングUTF-8とLatin-1を混在させています。ケース1では、両方にLatin-1を使用しているので、問題はありません。

lsコマンド（および他のすべての正常に動作するプログラム）は、LANG設定を使用してencodingを決定します。

2つの異なる言語を混在させることはできますが、2つの異なるエンコーディングを混在させるべきではありません。

LC_ *環境変数もLANG変数と同じエンコーディングを使用していることを確認してください。

経験則として、最近はシステムをUTF-8のみを使用するように構成する必要があります。

古い形式のデータファイル（例Javaプロパティ））を編集する必要がある場合は、専用のエディタ（例Java ide））を使用するか、ツールでエンコードを確認する必要がありますiconvや `recode ..

5
H.-Dirk Schmitt

これはあなたのニーズの範囲外かもしれませんが、...

それはRHEL5で判明し、おそらく以前は、Gdの予見された理由により、多くのmanページが何らかの形でascii化されています。つまり、生のmanページは、ネイティブの文字セットから7ビットASCIIに変換されています。 LCおよびLANGをどのように使用するかに関係なく、latin1のマニュアルページは、事実上役に立たないマニュアルページを生成します。内部のすべての特殊（8ビット）文字は、 7ビットのプレースホルダー（通常は??）。これは面白いと思います。

ただし、これらのmanページのutf8バージョンは、言語固有のディレクトリに存在する場合があります。トリックは、正しい名前でそれらを求めることです。たとえば、latin1は実際にはiso_8859-1です。マニュアルページを作成し、LANG設定が正しい場合は、期待どおりの結果が得られます。 manページは、言語固有のサブディレクトリ（en/man7/iso_8859-1.7）にあります。しかし、何らかの理由でiso-8859-1を要求すると、ASCIIバージョンが表示されます。

0
Otheus