Jak powiedzieli inni, # coding:
określa kodowanie, w jakim zapisywany jest plik źródłowy. Oto kilka przykładów ilustrujących to:
Plik zapisany na dysku jako cp437 (moje kodowanie konsoli), ale nie zadeklarowano kodowania
b = 'über'
u = u'über'
print b,repr(b)
print u,repr(u)
Wynik:
File "C:\ex.py", line 1
SyntaxError: Non-ASCII character '\x81' in file C:\ex.py on line 1, but no
encoding declared; see http://www.python.org/peps/pep-0263.html for details
Wyjście pliku z # coding: cp437
dodanymi:
über '\x81ber'
über u'\xfcber'
Początkowo Python nie znał kodowania i narzekał na znak spoza ASCII. Gdy już poznał kodowanie, ciąg bajtów pobierał bajty, które faktycznie znajdowały się na dysku. W przypadku ciągu znaków Unicode, Python odczytał \ x81, wiedział, że w cp437 był to ü i zdekodował go do punktu kodowego Unicode dla ü, czyli U + 00FC. Gdy łańcuch bajtów został wydrukowany, Python wysłał wartość szesnastkową 81
bezpośrednio do konsoli. Po wydrukowaniu łańcucha Unicode Python poprawnie wykrył kodowanie mojej konsoli jako cp437 i przetłumaczył Unicode ü na wartość cp437 dla ü .
Oto, co dzieje się z plikiem zadeklarowanym i zapisanym w UTF-8:
├╝ber '\xc3\xbcber'
über u'\xfcber'
W UTF-8 ü jest kodowane jako bajty szesnastkowe C3 BC
, więc ciąg bajtów zawiera te bajty, ale łańcuch Unicode jest identyczny z pierwszym przykładem. Python odczytał dwa bajty i poprawnie je zdekodował. Python niepoprawnie wydrukował łańcuch bajtów, ponieważ wysłał dwa bajty UTF-8 reprezentujące ü bezpośrednio do mojej konsoli cp437.
Tutaj plik jest zadeklarowany jako cp437, ale zapisany w UTF-8:
├╝ber '\xc3\xbcber'
├╝ber u'\u251c\u255dber'
Ciąg bajtów nadal zawiera bajty na dysku (bajty szesnastkowe UTF-8 C3 BC
), ale zinterpretował je jako dwa znaki cp437 zamiast jednego znaku zakodowanego w UTF-8. Te dwa znaki zostały przetłumaczone na punkty kodowe Unicode i wszystko jest drukowane nieprawidłowo.
# coding: utf8
jest wystarczająco dobry, nie ma potrzeby-*-