2014-05-14 2 views
0

C 확장의 버그로 인해 유니 코드 데이터가 str 인스턴스 또는 순서없이 인코딩되지 않고 str에 유니 코드 리터럴로 전달됩니다.유니 코드 리터럴에서 유니 코드 인스턴스를 만드는 방법

그래서, 예를 들어,이 유효한 문자 유니 코드

>>> u'\xa1Se educado!' 

그리고 UTF-8 인코딩 STR이 될 것입니다 : 그러나

>>> '\xc2\xa1Se educado!' 

, 나는 문자 유니 코드와의 str을 얻을이 :

>>> '\xa1Se educado!' 

그리고 유니 코드 인스턴스를 만들어야합니다. unicode()을 사용하면 인코딩이 필요하기 때문에 작동하지 않습니다. 나는 ''.join(unichr(ord(x)) for x in s)이 내가 필요한 것을 수행하지만 실제로는보기 흉한 것을 알았다. 더 나은 해결책이 있어야합니다. 어떤 아이디어?

+0

함께 작업하는 Python 버전은 무엇입니까? 문제를 만드는 확장 기능은 무엇입니까? 거기에서 그것을 고칠 수 있습니까? –

+0

파이썬 2.7. 확장은 실제로 관련이 없습니다. –

답변

1

의심 스럽지만, 파이썬이 유니 코드에 사용하는 "인코딩"이 무엇이든간에이를 디코딩하는 방법이 있어야합니다. 이는 raw_unicode_escape입니다.

>>> unicode('\xa1Se educado!', 'raw_unicode_escape') 
u'\xa1Se educado!' 
1

나는 문자 유니 코드와 함께 STR을 얻을 :

'\xa1Se educado!' 없음 정말 \xa1는 유니 코드 특정 탈출하지 않습니다. 바이트 문자열의 \xa1은 바이트 번호 161을 의미하며 유니 코드 문자열의 \xa1은 문자 (코드 포인트) 번호 161- 즉 \u00A1과 같습니다.

갖고있는 것은 UTF-8 인코딩 대신 ISO-8859-1 인코딩이 ¡Se educado! 인 바이트 문자열입니다. ISO-8859-1 인코딩에서 각 바이트 번호는 동일한 코드 포인트 번호의 유니 코드 문자와 일치합니다. 실제로 Windows를 사용하는 경우 비록

>>> '\xa1Se educado!'.decode('iso-8859-1') 
u'\xa1Se educado!' 

다음 인코딩 코드 페이지 1252 ('windows-1252') 될 가능성이 오히려 ISO-8859-1 이상 : 유니 코드 문자열 사용에 ISO-8859-1 바이트 문자열을 디코딩하는 방법 . 그것들은 비슷한 인코딩이지만 똑같은 것은 아닙니다. 코드 페이지 1252는 Windows가 서유럽 및 미국 로캘의 비 유니 코드 응용 프로그램에 사용하는 기본 'ANSI'코드 페이지입니다. 같은 컴퓨터에서 실행중인 Windows 비 유니 코드 응용 프로그램에서이 데이터를 가져 오는 경우 로케일 별 기본 코드 페이지가 무엇이든지 상관없이 인코딩 'mbcs'을 사용하여 디코딩해야합니다.

이들은 모든 유니 코드 문자를 수용 할 수없는 레거시 인코딩입니다. C 확장이 현재 코드 페이지 외부의 문자를 전혀 처리 할 수 ​​없다는 것을 알 수 있습니다.

+0

Nope. 이 예제는 ISO-8859-1과 일치한다는 점에서 좋지 않지만, 유니 코드 전용 문자가 생기 자마자 끊어져서 이스케이프 시퀀스가 ​​생깁니다. 예를 들어, '95.00'은 '\ u20ac95.00'으로 나타납니다. 나는 누군가가 원시 파이썬 유니 코드를 어떻게 든 쓰고 있다고 확신한다. 어쨌든 도움을 주셔서 감사합니다. –

+0

바이트 문자열에는'\ u' 이스케이프가 없습니다. '\\ u20ac95.00''라고 말하고 싶습니까? 그럼에도 U + 0000에서 U + 00FF까지의 문자에 대해 '\ xa1'(즉 '\\ xa1'이 아닌 리터럴 바이트 161)이 있습니까? – bobince

+0

작전 ... 예, 정확하게. –

관련 문제