Python subprocess.check_output с символами ±

Question

Я использую subprocess.check_output вызов приложения командной строки MS DOS для возврата строки stdout из приложения.

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

b'0ms: Channel.#0.Range.SelectedItem?\r\n\xf150 mV\r\n'

Проблема заключается в \ xf1 после первой новой строки, этот символ должен быть ± (\ xb1), но всегда возвращается как - (\ xf1), и я не могу понять, почему.

Если я запускаю команду вручную в командной строке, я получаю ±, как и следовало ожидать, поэтому я не думаю, что приложение командной строки ошибочно.

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

Кто-нибудь получил какие-либо идеи о том, почему разница символов между командной строкой и python?

Answer 1

Приложения MS DOS используют другую кодировку символов, нежели Windows Latin (cp1252) или цивилизованный мир (web + unix: utf-8) - для целей обратной совместимости они используют кодовую страницу CP850.

Все, что вам нужно сделать, чтобы получить правильный юникод Python из этой строки, - это декодировать его с кодировкой CP850, как в:

>>> print '0ms: Channel.#0.Range.SelectedItem?\r\n\xf150 mV\r\n'.decode("cp850")
0ms: Channel.#0.Range.SelectedItem?
±50 mV

Answer 2

Вероятно, программа, которую вы запускаете, выводит кодировку, отличную от той, которую вы используете в своем скрипте Python.Если я прав, и вы узнаете, какая это кодировка, вы можете использовать методы .decode(<origin-encoding>) и .encode(<target-encoding>), чтобы обойти процесс.

Редактировать: Кажется, я нашел кандидатакодировка:

>>> print s.decode('cp850')
0ms: Channel.#0.Range.SelectedItem?
±50 mV

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

Edit2: Пока я дурачился с кодеками, jsbueno пришел к тому же выводу, но с «исторической точки зрения» относительно того, почему этот кодек может быть тем, который вы используете.нужно использовать ...

HTH!