Поддержка Unicode

Click должен проявлять особую заботу о поддержке текстовых данных Unicode в различных средах.

Командная строка в Unix традиционно использует байты, а не Unicode. Хотя есть подсказки кодировки, существуют ситуации, когда это может привести к ошибкам. Наиболее распространённый случай — это подключение SSH к машинам с различными локалями.

Неправильно настроенные среды могут вызвать множество проблем с Unicode из-за отсутствия поддержки обратного преобразования эскейпов суррогатных пар. Этот недостаток не будет исправлен в самом Click!
Стандартный ввод и вывод по умолчанию открываются в текстовом режиме. Click должен переоткрывать поток в двоичном режиме в определённых ситуациях. Поскольку нет стандартного способа сделать это, это может не всегда работать. Прежде всего, это может стать проблемой при тестировании командно-строчных приложений.

Это не поддерживается:
```
sys.stdin = io.StringIO('Input here')
sys.stdout = io.StringIO()
```
Вместо этого вам нужно сделать так:
```
input = 'Input here'
in_stream = io.BytesIO(input.encode('utf-8'))
sys.stdin = io.TextIOWrapper(in_stream, encoding='utf-8')
out_stream = io.BytesIO()
sys.stdout = io.TextIOWrapper(out_stream, encoding='utf-8')
```
Помните, в этом случае вам нужно использовать out_stream.getvalue() и не sys.stdout.getvalue(), если вы хотите получить доступ к содержимому буфера, так как обертка не передаст этот метод.
sys.stdin, sys.stdout и sys.stderr по умолчанию основаны на тексте. Когда Click требует двоичный поток, он пытается определить базовый двоичный поток.
sys.argv всегда текстовый. Это означает, что родной тип для значений входных данных в типах Click — Unicode, а не байты.

Это вызывает проблемы, если терминал неправильно настроен, и Python не определяет кодировку. В этом случае строка Unicode будет содержать ошибочные байты, закодированные как эскейпы суррогатных пар.
При работе с файлами Click всегда использует API файловой системы Unicode, используя указанную или угаданную операционной системой кодировку файловой системы. Суррогатные пары поддерживаются для имён файлов, поэтому файлы должны открываться через тип File, даже если среда настроена неправильно.

Обработка суррогатных пар

Click выполняет всю обработку Unicode в стандартной библиотеке и подчиняется её поведению. Unicode требует особой осторожности. Причина в том, что обнаружение кодировки выполняется в интерпретаторе, а на Linux и некоторых других операционных системах обработка кодировки проблематична.

Наибольшие трудности возникают при использовании скриптов Click, запускаемых системами инициализации, инструментами развертывания или задачами cron, которые откажутся работать, если не экспортирована локаль Unicode.

Если Click обнаружит такую среду, он предотвратит дальнейшее выполнение, чтобы заставить вас установить локаль. Это делается потому, что Click не может знать о состоянии системы после запуска и восстановить значения до того, как запустилась обработка Unicode в Python.

Если вы видите ошибку такого рода:

Traceback (most recent call last):
  ...
RuntimeError: Click will abort further execution because Python was
  configured to use ASCII as encoding for the environment. Consult
  https://click.palletsprojects.com/unicode-support/ for mitigation
  steps.

Вы работаете в среде, где Python считает, что вы ограничены данными ASCII. Решение этих проблем различается в зависимости от локали, используемой вашим компьютером.

Например, если у вас немецкая машина Linux, вы можете исправить проблему, экспортировав локаль в de_DE.utf-8:

export LC_ALL=de_DE.utf-8
export LANG=de_DE.utf-8

Если вы работаете на американской машине, en_US.utf-8 — это предпочтительная кодировка. На некоторых новых системах Linux вы также можете попробовать C.UTF-8 в качестве локали:

export LC_ALL=C.UTF-8
export LANG=C.UTF-8

На некоторых системах сообщалось, что UTF-8 нужно писать как UTF8 и наоборот. Чтобы увидеть поддерживаемые локали, вы можете вызвать locale -a.

Вам нужно экспортировать значения перед запуском вашего скрипта Python.

В Python 3.7 и более поздних версиях вы больше не получите RuntimeError во многих случаях благодаря PEP 538 и PEP 540, которые изменили предположения по умолчанию в неконфигурированных средах. Это не меняет общей проблемы неправильной настройки вашей локали.