python 3.6.7 UnicodeEncodingError в машине Centos 7 - PullRequest
Новая
       18

python 3.6.7 UnicodeEncodingError в машине Centos 7

0 голосов
/ 05 февраля 2020

Прежде чем приступить к проблеме, я хотел бы сообщить, что я видел много вопросов о StackOverflow и python сообщалось об этой проблеме, но я не могу root вызвать проблему

Я получение UnicodeEncodingError на машине Centos. Python не встроен в машину, но виртуальная среда с требуемой python версией (3.6.7) создается где-то еще и копируется здесь. Таким образом, при запуске сервера мы активируем виртуальную среду и запускаем сервер.

проблема наблюдается в двух сценариях ios

  1. запись параметра запроса ввода, который содержит символы Unicode в это
  2. мы передаем операторы печати в файл журнала, и я вижу там ошибку при попытке напечатать эту строку Unicode через код

ошибка выглядит следующим образом 

print("\u6211\u7684\u7535\u8111\u603b\u662f\u51fa\u73b0Windows\u9700\u8981\u6fc0\u6d3b")
UnicodeEncodeError: 'ascii' codec can't encode characters in position 56-63: ordinal not in range(128)

Я подтвердил следующее через python терминал

  • sys.getdefaultencoding () - utf-8
  • sys.getfilesystemencoding () - utf-8
  • sys.stdout.encoding
  • LANG установлен в en_us.utf-8
  • LC_ALL не установлен

Я рассмотрел некоторые решения с просьбой изменить LC_ALL или добавить PYTHONIOCODING в переменных среды, но я не уверен в том, чтобы изменять их, не зная побочных эффектов, поскольку среда является производственной средой.

Edit - Я попытался напечатать тот же набор символов, повторный ввод кода через консоль осуществляется путем открытия терминала python и его печати без каких-либо проблем. Пробовал печатать таким образом 

import sys
print("日本語")
sys.stdout.write("日本語\n")

, но через код он вызывает UnicodeEncodingError

Я хотел бы знать, как решить эту проблему?

Спасибо

Ответы [ 2 ]

1 голос
/ 05 февраля 2020

большинство терминалов ascii не могут отображать символы Юникода (вы можете попробовать изменить шрифт ... возможно, это сработает) ... поэтому даже если вы преодолеете ошибку кодирования, ваш отпечаток, вероятно, будет выглядеть как �������Windows�������

если запустить его в режиме ожидания, это сработает ...

я бы настоятельно рекомендовал бы просто print(repr(string_that_might_have_unicode)), поскольку это гарантирует печатное представление ascii ... и нет ничего хуже, чем сбой вашего приложения из-за того, что вы пытались напечатать некоторую отладочную информацию ... (при печати repr появится что-то более похожее на b"'\\u6211\\u7684\\u7535\\u8111\\u603b\\u662f\\u51fa\\u73b0Windows\\u9700\\u8981\\u6fc0\\ u6d3b'"

, вы также можете попробовать encode вручную, прежде чем распечатать его

print(my_unicode_string.encode("utf8"))

, что может работать ... в некоторых терминалах ... но на самом деле ... просто распечатайте repr, если вы не показываете это пользователю ( но поскольку вы говорите о сервере, я представляю, что это не клиентское приложение терминала, а отладочная информация, которая печатается (и перенаправляется в лог-файл?))

, если вам действительно нужно печатать точный юникод к терминалу вместо repr, тогда я думаю, что вам нужно выполнить шаг ручного декодирования, чтобы отправить utf8 на реальный терминал ... но гораздо проще просто всегда печатать repr при регистрации (это имеет преимущество, показывая вы невидимые и пробельные символы ... но не здорово, если это часть клиентского приложения)

0 голосов
/ 26 февраля 2020

Наконец-то избавился от этой проблемы следующим образом

Я заметил проблему, упомянутую в вопросе, при двух разных обстоятельствах

Первый сценарий - со всеми настройками, опубликованными в вопросе, все язык- связанные кодировки - UTF-8, он работал после перезагрузки нашего сервера без каких-либо изменений. До сих пор не знаю, что заставило его не работать раньше и работать после перезагрузки машины.

Второй сценарий - Все переменные L C установлены в POSIX в нашей клиентской среде. Я прошел через множество решений, в которых предлагалось изменить LANG или LC_ALL до UTF-8. Но изменение всех конфигураций кодирования может привести к таким проблемам, как преобразование даты и времени и т. Д. c ..., которые основаны на локали.

Fix - только LC_CTYPE изменен на UTF-8, в нашем случае это en_US.UTF-8

export LC_CTYPE="en_US.UTF-8"

и это сработало.

...