Utf 8 ошибка кодировки

При запуске скрипта выдается ошибка:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 0: 
    invalid continuation byte

Все работало на винде, но сейчас перешел на убунту и словил ошибку. IDE PyCharm.

#!/usr/bin/python
# -*- coding: utf8 -*-

import vk
import time

token = "8723b7"
session = vk.Session(access_token=token)
api = vk.api.API(session, v='5.80', land='ru')
adres2 = '//home//sergey//Рабочий стол//Alfa-Forex MetaTrader 
4//MQL4//Files//text.txt' #открытая группа

position2 = 0 #открытая группа

with open(adres2) as fh2:
    while True:
        fh2.seek(position2) #открытая группа

        data2 = fh2.read() #открытая группа

        position2 = fh2.tell() #открытая группа

        if data2:
            api.wall.post(owner_id='-11', message=data2)# открытая 
группа

        time.sleep(3)

ошибка:

/usr/bin/python3.6 /home/sergey/bin/Signal.py
Traceback (most recent call last):
 File "/home/sergey/bin/Signal.py", line 39, in <module>
   data2 = fh2.read() #открытая группа
 File "/usr/lib/python3.6/codecs.py", line 321, in decode
  (result, consumed) = self._buffer_decode(data, self.errors, final)
 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 
 0: invalid continuation byte

Объясните как это исправить?

If you need to store UTF8 data in your database, you need a database that accepts UTF8. You can check the encoding of your database in pgAdmin. Just right-click the database, and select «Properties».

But that error seems to be telling you there’s some invalid UTF8 data in your source file. That means that the copy utility has detected or guessed that you’re feeding it a UTF8 file.

If you’re running under some variant of Unix, you can check the encoding (more or less) with the file utility.

$ file yourfilename
yourfilename: UTF-8 Unicode English text

(I think that will work on Macs in the terminal, too.) Not sure how to do that under Windows.

If you use that same utility on a file that came from Windows systems (that is, a file that’s not encoded in UTF8), it will probably show something like this:

$ file yourfilename
yourfilename: ASCII text, with CRLF line terminators

If things stay weird, you might try to convert your input data to a known encoding, to change your client’s encoding, or both. (We’re really stretching the limits of my knowledge about encodings.)

You can use the iconv utility to change encoding of the input data.

iconv -f original_charset -t utf-8 originalfile > newfile

You can change psql (the client) encoding following the instructions on Character Set Support. On that page, search for the phrase «To enable automatic character set conversion».

If you need to store UTF8 data in your database, you need a database that accepts UTF8. You can check the encoding of your database in pgAdmin. Just right-click the database, and select «Properties».

But that error seems to be telling you there’s some invalid UTF8 data in your source file. That means that the copy utility has detected or guessed that you’re feeding it a UTF8 file.

If you’re running under some variant of Unix, you can check the encoding (more or less) with the file utility.

$ file yourfilename
yourfilename: UTF-8 Unicode English text

(I think that will work on Macs in the terminal, too.) Not sure how to do that under Windows.

If you use that same utility on a file that came from Windows systems (that is, a file that’s not encoded in UTF8), it will probably show something like this:

$ file yourfilename
yourfilename: ASCII text, with CRLF line terminators

If things stay weird, you might try to convert your input data to a known encoding, to change your client’s encoding, or both. (We’re really stretching the limits of my knowledge about encodings.)

You can use the iconv utility to change encoding of the input data.

iconv -f original_charset -t utf-8 originalfile > newfile

You can change psql (the client) encoding following the instructions on Character Set Support. On that page, search for the phrase «To enable automatic character set conversion».

Зачем эта статья?

Об обработке текстов на естественном языке сейчас знают все. Все хоть раз пробовали задавать вопрос Сири или Алисе, пользовались Grammarly (это не реклама), пробовали генераторы стихов, текстов… или просто вводили запрос в Google. Да, вот так просто. На самом деле Google понимает, что вы от него хотите, благодаря штукам, которые умеют обрабатывать и анализировать естественную речь в вашем запросе.

При анализе текста мы можем столкнуться с ситуациями, когда текст содержит специфические символы, которые необходимо проанализировать наравне с «простым текстом» (взять даже наши горячо любимые вставки на французском из «Война и мир») или формулы, например. В таком случае обработка текста может усложниться.

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

Обратите внимание на следующий запрос:

Запрос содержит символ с модифицирующим акутом, однако во втором результате мы можем заметить, что выделено найденное слово из запроса, только вот оно не содержит вышеупомянутый символ, просто букву «о».

Конечно, уже есть много готовых инструментов, которые довольно неплохо справляются с обработкой текстов и могут делать разные крутые вещи, но я не об этом хочу вам поведать. Я не буду рассказывать про nltk, стемминг, лемматизацию и т.п. Я хочу опуститься на несколько ступенек ниже и обсудить некоторые тонкости кодировок, байтов, их обработки.

Откуда взялась статья?

Одним из важных составляющих в области ИИ является обработка текстов на естественном языке. В процессе изучения данной тематики я начал задавать себе вопросы, которые в конечном итоге привели меня к изучению кодировок, представлению текстов в памяти, как они преобразуются, приводятся к нормальной форме. Я плохо понимал эту тему в начале, потребовалось немало времени и мозгового ресурса, чтобы понять, принять и запомнить некоторые вещи. Написанием данной статьи я хочу облегчить жизнь людям, которые столкнутся с необходимостью чтения и обработки текстов на Python и самому закрепить изученное. А некоторыми полезными поинтами своего изучения я постараюсь поделиться в данной статье.

Важная ремарка: я не являюсь специалистом в области обработки текстов. Изложенный материал является результатом исключительно любительского изучения.

Проблема чтения файлов

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

with open("some_text.txt", "r") as file:
    content = file.read()

print(content)

В файле содержится вот такое вот изречение:

pitón

что переводится с испанского как питон. Однако консоль OC Windows 10 покажет нам немного другой результат:

C:myhabrTextsInPython> python .script1.py
pitón

Сейчас мы разберёмся, что именно пошло не так и по какой причине.

Кодировка

Думаю, это не будет сюрпризом, если я скажу, что любой символ, который заносится в память компьютера, хранится в виде числа, а не в виде литерала. Это число определяется как идентификатор или кодовая позиция символа. Кодировка определяет, какое именно число будет ассоциировано с символом.

Предположим, у нас есть некоторый файл с неизвестным содержимым, и нам нужно его прочитать, однако мы не знаем, какая у файла кодировка. Попробуем декодировать содержимое файла.

with open("simple_text.txt", "r") as file:
    text = file.read()
print(text)

Посмотрим на результат:

C:myhabrTextsInPython> python .script2.py
ÿþ<♦8♦@♦

Очень интересно, ничего непонятно. По умолчанию Python использует кодировку utf-8, но видимо запись в файл происходила не с её помощью. Здесь нам придёт на помощь дополнительный параметр функции open — параметр encoding, который позволяет указать конкретную кодировку, в которой следует прочитать файл (или записывать в него). Попробуем перебрать несколько кодировок и найти подходящую.

codecs = ["cp1252", "cp437", "utf-16be", "utf-16"]

for codec in codecs:
    with open("simple_text.txt", "r", encoding=codec) as file:
        text = file.read()
    print(codec.rjust(12), "|", text)

Результат:

C:myhabrTextsInPython> python .script3.py
      cp1252 | ÿþ<8@
       cp437 |  ■<8@
    utf-16be | 㰄㠄䀄
      utf-16 | мир

Разные кодировки расшифровывают байты из файла по-разному, то есть разным кодовым позициям могут соотвествовать разные символы. Пример примитивный, несложно догадаться, что истинная кодировка файла — это utf-16.

Важный поинт: при записи и чтении из файлов следует указывать конкретную кодировку, это позволит избежать путаницы в дальнейшем.

Ошибки, связанные с кодировками

При возникновении ошибки, связанной с кодировками, интерпретатор выдаст одно из следующих исключений:

• UnicodeError. Это общее исключение для ошибок кодировки.

• UnicodeDecodeError. Данное исключение возбуждается, если встречается кодовая позиция, которая отсутствует в кодировке.

• UnicodeEncodeError. А это исключение возбуждается, когда символ, который необходимо закодировать, незнаком для кодировки.

Попытка выполнения вот такого кода (в файле всё ещё содержится испанский питон):

with open("some_text.txt", "r", encoding="ascii") as file:
    file.read()

даст нам следующий результат:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)

Кодировка ASCII не поддерживает никакой алфавит, кроме английского. Поэтому декодирование символа «ó» вызывает у ASCII сложности. Однако Python всемогущ и есть механизм, который позволяет обработать ошибки кодировок. Это дополнительный параметр методов encode и decode — параметр errors. Он может принимать следующие значения:

Для обеих функций:

Только для метода encode:

Также отдельно выделены значения surrogatepass и surrogateescape.

Приведём пример использования таких обработчиков:

>>> text = "pitón"
>>> text.encode("ascii", errors="ignore")
b'pitn'
>>> text.encode("ascii", errors="replace")
b'pit?n'
>>> text.encode("ascii", errors="xmlcharrefreplace")
b'pitón'
>>> text.encode("ascii", errors="backslashreplace")
b'pitxf3n'
>>> text.encode("ascii", errors="namereplace")
b'pitN{LATIN SMALL LETTER O WITH ACUTE}n'

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

Cворачивание регистра

Сворачивание регистра — это попытка унифицировать текст любого представления к канонической форме. Например, приведение всего текста в нижний регистр. Также над текстом производятся некоторые преобразования (например, немецкая «эсцет» — «ß» — преобразуется в «ss»). В Python 3.3 появился метод str.casefold(), который как раз выполняет сворачивание регистра. Если текст содержит только символы кодировки latin1, результат применения этого метода будет аналогичен методу str.lower().

И по классике приведём пример:

>>> text = "Die größte Stadt der Welt liegt in China"
>>> text.casefold()
'die grösste stadt der welt liegt in china'

В результате применённый метод не только привёл весь текст к нижнему регистру, но и преобразовал специфический немецкий символ.

Важный поинт: привести текст можно не только методом str.lower(), но и методом str.casefold(), который может выполнить дополнительные преобразования текста.

Нормализация

Нормализация — это полноценное приведение текста к единому представлению.

Чтобы обозначить важность нормализации, приведём простой пример:

letter1 = "µ"
letter2 = "μ"

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

В Python есть отличный встроенный модуль, который содержит данные о символах Unicode, их имена, являются ли они цифрамии и т.п. (методы по типу str.isdigit() берут информацию из этих данных). Воспользуемся данным модулем, чтобы вывести имена символов, исходя из информации, которая содержится в базе данных Unicode.

import unicodedata

letter1 = "µ"
letter2 = "μ"
print(unicodedata.name(letter1))
print(unicodedata.name(letter2))

Результат выполнения данного кода:

C:myhabrTextsInPython> python .script7.py
MICRO SIGN
GREEK SMALL LETTER MU

Итак, интерпретатор Python’a видит эти символы как два разных, но в стандарте Unicode они имеют одинаковое отображение.Такие символы называют каноническими эквивалентами. Приложения будут считать два этих символа одинаковыми, но не интерпретатор.

Посмотрим на ещё один пример:

>>> s1 = 'café'
>>> s2 = 'cafeu0301'
>>> s1, s2
('café', 'café')
>>> s1 == s2
False
>>> len(s1), len(s2)
(4, 5)

Данные символы также будут являться каноническими эквивалентами. Из примера мы видим, что символ «é» в стандарте Unicodeможет быть представлен двумя способами, которые к тому же имеют разную длину. Символ «é» может быть представлен одним или двумя байтами.

Решением таких конфликтов занимается нормализация. Она реализована в Python в функции unicodedata.normalize.Первым аргумент является так называемая форма нормализации — нормализации строк Unicode, которые позволяют определить, эквивалентны ли какие-либо две строки Unicode друг другу. Всего предлагается четыре формы:

Разберём каждую форму немного подробнее.

• NFC

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

>>> unicodedata.normalize("NFC", s1), unicodedata.normalize("NFC", s2)
('café', 'café')
>>> len(unicodedata.normalize("NFC", s1)), len(unicodedata.normalize("NFC", s2))
(4, 4)
>>> unicodedata.normalize("NFC", s1) == unicodedata.normalize("NFC", s2)
True
>>> len(unicodedata.normalize("NFC", s1)) == len(unicodedata.normalize("NFC", s2))
True

Итак, нормализация обеих строк внешне их не изменила, однако длина строки s2 стала равной 4 (т.е. на один байт меньше). Была произведена композиция байтов eu0301, которые являлись отображением «é». Данная последовательность была заменена на минимальное представление символа, т.е. теперь представление этого символа для интерпретатора выглядит как в строке s1. Как результат, мы видим, что длина нормализованных строк стала равной, и сами строки также стали равны.

• NFD

С этой формой ситуация аналогичная, только происходит декомпозиция байтов, т.е. разложение символа на несколько байт.

>>> unicodedata.normalize("NFD", s1), unicodedata.normalize("NFD", s2)
('café', 'café')
>>> len(unicodedata.normalize("NFD", s1)), len(unicodedata.normalize("NFD", s2))
(5, 5)
>>> unicodedata.normalize("NFD", s1) == unicodedata.normalize("NFD", s2)
True
>>> len(unicodedata.normalize("NFD", s1)) == len(unicodedata.normalize("NFD", s2))
True

Здесь мы видим, что длина строки s1 увеличилась на один байт. Думаю, уже несложно догадаться, почему.

На данном этапе настал момент ввести понятие символа совместимости. Символы совместимости (compatibility characters) были введены в Unicode ради совместимости с другими стандартами, в частности, стандарты, которые предшествовали Unicode. Это означает, что некоторые символы могут встречаться в стандарте несколько раз. Мы уже могли наблюдать это явление в начале этого раздела на примере с символом «мю». Он считается символом совместимости.

• NFKC и NFKD

При данных формах нормализации символы совместимости заменяются на его более предпочтительное представление, что также называется совместимой декомпозицией. Однако при данных формах нормализации может быть потеряно форматирование.

Немного модифицируем наш пример из начала раздела. Выведем кодовые позиции символов до и после нормализации:

import unicodedata

letter1 = "µ"
letter2 = "μ"
print("Before normalizing:", ord(letter1), ord(letter2))
letter1 = unicodedata.normalize("NFKC", letter1)
letter2 = unicodedata.normalize("NFKC", letter2)
print("After normalizing:", ord(letter1), ord(letter2))

И результат выполнения кода:

Before normalizing: 181 956
After normalizing: 956 956

Итак, мы видим, что первый символ (который являлся знаком «микро») был заменён на греческую «мю», т.е. более предпочтительное представление символа. Таким образом, если необходимо, например, провести частотный анализ текста, формы нормализации, которые затрагивают символы совместимости, могут помочь с этим, приводя символы совместимости к единому представлению.

Важный поинт: нормализация может очень помочь для поиска валидных документов или индексирования текста. Если вы занимаетесь разработкой таких систем, не стоит сбрасывать алгоритмы нормализации со счетов.

Дополнительные материалы: что использовалось в статье и что почитать по теме

«Fluent Python», Лучано Ромальо

В этой книге целая глава посвящена изучению строк, байтов и Unicode (Глава 4. Тексты и байты). Она есть на русском и английском языках, но в русском переводе допущено немало ошибок, так что открывайте русский вариант на свой страх и риск. Материал статьи в большей степени опирается на данную книгу. Некоторые примеры также взяты оттуда.

Документация для Unicode на официальном сайте Python

Куда ж без неё, родимой. Там тоже можно найти немало полезной информации, если вам понадобится работать с текстами и делать больше, чем просто считывание из файла. Хотя в некоторых случаях и на этом можно споткнуться.

Unicode® Standard Annex

Это части стандарта Unicode, которые выложены в открытый доступ в виде отдельных статей. Почитать их можно вот здесь.

Когда я только начинал изучать тему разработки сайтов, кракозябры были одной из моих постоянных проблем. Создал HTML-страницу — в браузере кракозябры, установил денвер и попробовал создать сайт на PHP — снова вместо букв кракозябры. Скачал иностранную тему, подключился к базе данных — та же проблема.

На своих сайтах я обычно использую UTF-8 (это такая кодировка текста, она ещё называется юникод), соответственно она будет присутствовать во всех примерах в этой статье.

1. UTF-8 без BOM

Начнём с самой простой проблемы. Вы создали какой-то HTML-файл, открыли его в браузере и получили:

Проблема актуальна в основном для пользователей Windows, на маке я с таким ни разу не сталкивался.

Решение проблемы зависит в основном от того, каким редактором вы пользуетесь. Для пользователей Windows я рекомендую бесплатный офигительный Notepad++.

Значит, открываем файл в Notepad++ и переходим в Кодировки > Преобразовать в UTF-8 без BOM. Вопрос — почему без BOM? Потому что с BOM у вас будут постоянно вставляться пустые символы (на самом деле они не пустые, у них тоже есть своя функция, но нам она в данном случае не нужна) куда не надо, а для PHP это уже критично.

2. Мета тег charset

Если вы сделали то, что я описывал в предыдущем шаге и ваша проблема не разрешилась, тогда самое время испробовать второй метод устранения кракозябров.

Всё, что нам требуется, это вставить следующий код между тегами <head> сайта. Прежде всего проверьте, возможно этот метатег у вас уже присутствует. Если да, то посмотрите какое у него стоит значение параметра charset.

В темах WordPress обычно этот тег уже имеется по умолчанию и выглядит следующим образом:

<meta charset="<?php bloginfo('charset'); ?>" />

3. .htaccess

Если русские буквы до сих пор отображаются кракозябрами, тогда открываем ваш .htaccess, который лежит в корне сайта и вставляем туда с новой строки это:

4. Заголовки сервера через header()

Ещё один способ определения кодировки. На этот раз через PHP. На WordPress никогда не приходилось им пользоваться.

header('Content-Type: text/html; charset=utf-8');

Важно! Этот код должен вставляться до того, как будет что-либо выведено на странице сайта, иначе — ошибка.

5. Проблемы с последним символом при обрезке строки

На многих сайтах встречаются блоки с популярными записями, последними комментариями, отзывами и так далее. Обычно в таких обзорных блоках выводится часть записи/комментария/отзыва и кнопка «читать далее». Так вот, для того, чтобы вывести первые несколько предложений или первые несколько слов текста, используется функция PHP substr(). Конечно же в основном я имею ввиду англоязычные темы, которых так много в интернете. Даже если у этих тем есть локализация — то есть вроде бы она на русском — переведена админка, переведён практически весь сайт, но при этом мы встречаем такие вот косяки:

Как решить эту проблему?

Легко — всё что нам нужно, это найти функцию substr() в коде и поменять её на mb_substr().

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

6. MySQL

У меня не раз бывало такое, что я подключался к MySQL, вытаскивал какие-нибудь данные, и при их выводе на сайте, текст отображался кракозябрами.

Такое может произойти, если кодировка вашего сайта не совпадает с кодировкой базы данных, к которой вы подключаетесь. В WordPress обычно таких проблем не бывает.

Для того, чтобы исправить это, после подключения к БД, делаем следующее:

mysql_query("SET NAMES 'UTF8'");

Если ни один из вышеперечисленных методов вам не помог, оставляйте комментарий и попробуем вместе разобраться.

Back to top

In [32]: hi_unicode = 'привет'

In [33]: hi_unicode.encode('ascii')
---------------------------------------------------------------------------
UnicodeEncodeError                        Traceback (most recent call last)
<ipython-input-33-ec69c9fd2dae> in <module>()
----> 1 hi_unicode.encode('ascii')

UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5: ordinal not in range(128)

In [34]: hi_unicode = 'привет'

In [35]: hi_bytes = hi_unicode.encode('utf-8')

In [36]: hi_bytes.decode('ascii')
---------------------------------------------------------------------------
UnicodeDecodeError                        Traceback (most recent call last)
<ipython-input-36-aa0ada5e44e9> in <module>()
----> 1 hi_bytes.decode('ascii')

UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)

In [37]: de_hi_unicode = 'grüezi'

In [38]: utf_16 = de_hi_unicode.encode('utf-16')

In [39]: utf_16.decode('utf-8')
---------------------------------------------------------------------------
UnicodeDecodeError                        Traceback (most recent call last)
<ipython-input-39-4b4c731e69e4> in <module>()
----> 1 utf_16.decode('utf-8')

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte

In [40]: hi_unicode = 'привет'

In [41]: hi_bytes = hi_unicode.encode('utf-8')

In [42]: hi_bytes
Out[42]: b'xd0xbfxd1x80xd0xb8xd0xb2xd0xb5xd1x82'

In [43]: hi_bytes.decode('utf-16')
Out[43]: '뿐胑룐닐뗐苑'

In [44]: de_hi_unicode = 'grüezi'

In [45]: de_hi_unicode.encode('ascii', 'replace')
Out[45]: b'gr?ezi'

In [46]: de_hi_unicode = 'grüezi'

In [47]: de_hi_unicode.encode('ascii', 'namereplace')
Out[47]: b'gr\N{LATIN SMALL LETTER U WITH DIAERESIS}ezi'

In [48]: de_hi_unicode = 'grüezi'

In [49]: de_hi_unicode.encode('ascii', 'ignore')
Out[49]: b'grezi'

In [50]: de_hi_unicode = 'grüezi'

In [51]: de_hi_utf8 = de_hi_unicode.encode('utf-8')

In [52]: de_hi_utf8
Out[52]: b'grxc3xbcezi'

In [53]: de_hi_utf8.decode('ascii', 'ignore')
Out[53]: 'grezi'

In [54]: de_hi_unicode = 'grüezi'

In [55]: de_hi_utf8 = de_hi_unicode.encode('utf-8')

In [56]: de_hi_utf8.decode('ascii', 'replace')
Out[56]: 'gr��ezi'

Пишу в PyCharm и вроде как там с кодировкой проблем не должно возникать, однако удача меня обошла стороной.
При запуске локального сервера возникает следующая ошибка:

Unhandled exception in thread started by .wrapper at 0x035B1B28>
Traceback (most recent call last):
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libsite-packagesdjangoutilsautoreload.py», line 227, in wrapper
fn(*args, **kwargs)
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libsite-packagesdjangocoremanagementcommandsrunserver.py», line 149, in inner_run
ipv6=self.use_ipv6, threading=threading, server_cls=self.server_cls)
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libsite-packagesdjangocoreserversbasehttp.py», line 164, in run
httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libsite-packagesdjangocoreserversbasehttp.py», line 74, in __init__
super(WSGIServer, self).__init__(*args, **kwargs)
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libsocketserver.py», line 453, in __init__
self.server_bind()
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libwsgirefsimple_server.py», line 50, in server_bind
HTTPServer.server_bind(self)
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libhttpserver.py», line 138, in server_bind
self.server_name = socket.getfqdn(host)
File «C:UsersTonyAppDataLocalProgramsPythonPython36-32libsocket.py», line 673, in getfqdn
hostname, aliases, ipaddrs = gethostbyaddr(name)
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xcf in position 5: invalid continuation byte

Заморочился и пересохранил все файлы в UTF-8 — не помогло. Пересмотрел кодировку каждого файла в самом PyCharm’e — везде UTF-8. Нашел на некоторых форумах такую же проблему — в качестве решения предлагалось переименовать имя компьютера в ASCII кодировку (на латинице короче говоря). Весь путь на латинице — ноль изменений. В каждом файле писал комментарий с кодировкой:
# coding: utf8
и вот так, что одно и то же
# -*- coding: utf-8 -*- .
Результата как не было, так и нет. Весь день копаюсь, так до сих пор и без понятия в чем дело.
Использую фреймворк Django (может что на нем завязано).
Надеюсь на вашу помощь. Заранее спасибо!