Windowsコンソール備考

Changelog

バージョン 6.0 で追加.

Clickは、個別のAPIを介してWindowsコンソールへのUnicodeをサポートするために、Windows上で出力ストリームをシミュレートし、異なるパラメータ復号を実行します。

以下にその動作原理とあなたに対するそれの意味を簡単に紹介します。

Unicodeパラメータ

内部クリックは、一般に、任意のパラメータがバイト文字列またはUnicode文字列として入り、タイプの期待値への変換をできるだけ遅く実行することができるという概念に基づく。これは、オペレーティングシステムとPythonバージョンに最適な形でデータを受け取ることを可能にするため、いくつかの利点があります。

これはWindows上で問題となり，最初に誤ったコードを用いてしまい，最終的に入力データにゴミが発生する.私たちはコード部分を修復しただけでなく sys.argv それがそうです。

これにはもう一つの制限があります sys.argv クリック処理プログラムを呼び出す前に修正され、通常のバイト入力に戻さなければならないが、この場合、すべてのUnicode値が利用可能であるわけではなく、パラメータのためのコードページのサブセットにすぎない。

Unicode出力と入力

Windows上のUnicode出力と入力は，テキストストリームの概念をスケジューリングすることで実現される.これは，Click firstがWindows上のテキスト出力(または入力)ストリームを必要とする場合，Windowsコンソールが接続されているかどうかを決定するために何度かチェックされることを意味する.Windowsコンソールが存在しない場合は、テキスト出力ストリームを返し、ストリームの符号化を設定します。 utf-8 すべてのプラットフォームにあるように。

しかし，コンソールに接続するとストリームをシミュレートし，cmd.exe Unicode APIを用いてテキスト情報を出力する.この場合、ストリームはまた使用されます utf-16-le 内部コードとして。しかしながら、いくつかのハッカーは、下位の元のIOバッファを攻撃してもUnicode APIを迂回しており、間接的にバイト出力を行う可能性がある。

• This unicode support is limited to click.echo, click.prompt as well as click.get_text_stream.

• Unicode値かバイト文字列かを渡すことにより，制御フローは内部でまったく異なる位置に到達し，データが部分的にバッファリングされると奇妙なアーチファクトが出現する可能性がある.クリックして手動で常にリフレッシュすることで、このようなことを防止しようとしていますが、異なる文字列タイプを混合して一致させる場合 stdout あるいは…。 stderr 手動で現像する必要があります。

• オリジナル出力ストリームはバイナリモードに設定されており，これはWindows上のグローバル動作であるため， print 通話は影響を受けます。むしろ click.echo 超過 print それがそうです。

• Windows 7以降では、バイナリモードで1回の呼び出しで最大64 k文字を書き込むことができる制限があります。この場合には sys.stdout そして sys.stderr この制限を迂回した包装器に置き換える。

もう1つ注意すべき重要なことは、Windowsコンソールのデフォルトフォントが多くの文字をサポートしていないことであり、これは、絵文字や特殊な文字を使用することなく、国際文字しか使用できないことを意味します。