Я хочу, чтобы мой скрипт на Python мог читать аргументы командной строки Unicode в Windows. Но похоже, что sys.argv - это строка, закодированная в некоторой локальной кодировке, а не Unicode. Как я могу прочитать командную строку в полном Unicode?
Пример кода: argv.py
import sys
first_arg = sys.argv[1]
print first_arg
print type(first_arg)
print first_arg.encode("hex")
print open(first_arg)
На моем компьютере, настроенном для японской кодовой страницы, я получаю:
C:\temp>argv.py "PC・ソフト申請書08.09.24.doc"
PC・ソフト申請書08.09.24.doc
<type 'str'>
50438145835c83748367905c90bf8f9130382e30392e32342e646f63
<open file 'PC・ソフト申請書08.09.24.doc', mode 'r' at 0x00917D90>
Полагаю, это кодировка Shift-JIS, и она "работает" для этого имени файла. Но он разбивается на имена файлов с символами, которых нет в наборе символов Shift-JIS - последний вызов «open» завершается неудачно:
C:\temp>argv.py Jörgen.txt
Jorgen.txt
<type 'str'>
4a6f7267656e2e747874
Traceback (most recent call last):
File "C:\temp\argv.py", line 7,
in <module>
print open(first_arg)
IOError: [Errno 2] No such file or directory: 'Jorgen.txt'
Примечание. Я говорю о Python 2.x, а не Python 3.0. Я обнаружил, что Python 3.0 дает sys.argv
в качестве правильного Unicode. Но переход на Python 3.0 пока рано (из-за отсутствия поддержки сторонних библиотек).
Обновление:
В нескольких ответах говорилось, что я должен декодировать в соответствии с тем, в чем кодируется sys.argv
. Проблема в том, что это не полный Unicode, поэтому некоторые символы не представимы.
Вот пример использования, который меня огорчает: у меня включено перетаскивание файлов в .py файлы в проводнике Windows . У меня есть имена файлов со всевозможными символами, включая те, которые отсутствуют в системной кодовой странице по умолчанию. Мой сценарий Python не получает правильные имена файлов Unicode, переданные ему через sys.argv во всех случаях, когда символы не могут быть представлены в текущей кодировке кодовой страницы.
Конечно, есть некоторый Windows API для чтения командной строки с полным Unicode (и Python 3.0 делает это). Я предполагаю, что интерпретатор Python 2.x не использует его.