| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Python: Общие вопросы > Строки |
| Автор: Karadul 14.5.2012, 09:52 | ||||
1. Почему в "сырых" строках работают юникодовые последовательности, хотя байтовые не работают? Не совсем они, получается, "сырые".
2.
Почему так? |
| Автор: Karadul 16.5.2012, 13:05 | ||||||
И что дальше? Указывать кодировку файла - неумное решение, т.к. во-первых тупо, а во-вторых, поменяется кодировка исходника - и программа перестанет работать. Юникодные сырые строки, во-первых, нелогичны, т.к. одни эскейпы работают, а другие нет, а во-вторых, реальных юникодных сырых строк, получается, нет, все равно надо что-то костылить. И не вижу особого смысла указывать в юникодных строках символы через эскейп, т.к. их можно указать напряму (а исходники хранить в utf8), а во-вторых, есть же не сырые юникодные строки.
А не cp866 в консоли? Тут немного неудобно как-то, неужели питон сам не знает кодировку своей сосноли? |
| Автор: VinniPuhh 17.5.2012, 12:10 | ||||||||
Може ты и прав, може и cp866 - не уверен насчет именно 1251
Не то чтобы "своей", скорее системной (stdin/stdout). По идее да, можно было бы системным API выяснить какая там кодировка по умолчанию. Я думаю что разработчики не сделали такого, чтобы избежать проблем при конструкциях myprg.exe file1 > pyhton myscript.py и тому подобным.
А вот тут (естественно imho) ты в корне не прав по идеологии. Ты задаешь литерал, значение которого используется в программе. Посмотри с точки зрения интерпретатора: Как понять, что именно (в байтовом представлении) ты имел в виду? Логично есть такие пути: 1. Задавать литерал явно в байтовом представлении (\u0514\u0213\u2231) 2. Указать явно, каким образом переводить набранное в редакторе в это представление (# -*- coding: utf-8 -*-) 3. Запретить набирать в редакторе неоднозначные символы (SyntaxError: Non-ASCII character '\xd1' in file test.py on line 1, but no encoding declared;) 4. Договориться, что всегда использовать определенный алгоритм перевода. (Пока в сообществе Python не договорились Как видишь, три из четырех придуманных мной путей питон поддерживает. Как раз наоборот, если не указывать кодировку явно, то будет эффект "поменяется кодировка исходника - и программа перестанет работать" - ведь вместо предполагаемого "Документы" будет преобразовано в крокозябры. Я бы решал вопрос так:
|
| Автор: Karadul 17.5.2012, 16:43 | ||
Мы друг друга не поняли, я имел в виду указывать в unicode() вторым параметром кодировку файла. Указывать в файле кодировку считаю - правильно, хорошо бы жавоидам это перенять. Сам переправил?
Кодировка сосноли в данном случае - кодировка исходника, т.к. вместо исходного файла - сосноль. Может быть, не хотели ошибок из-за того, что вместо кодировки бы автоматически подставлялась кодировка исходника там где надо и где не надо. Кстати, в 3.х стоковые литералы по умолчанию юникодные. Решает много проблем. И вообще, в 2.х юникод - больное место. Видите ли, в 2012 году, когда даже линупс юникод осилил, а 9х уже похоронили, программы не работают, если пути, где лежат они или файлы, с которыми они работают, содержат не-аски символы. А все потому, что у девелоперов все работало. Не, я в курсе, что так можно, но я ничего эскейпить не хочу. Короче, баг налицо, вопрос, будут ли его править. В 3.х, говорят, все работает. |