Poprawny sposób definiowania kodowania kodu źródłowego w Pythonie

163

PEP 263 definiuje sposób deklarowania kodowania kodu źródłowego w Pythonie.

Zwykle pierwsze 2 wiersze pliku Pythona powinny zaczynać się od:

#!/usr/bin/python
# -*- coding: <encoding name> -*-

Ale widziałem wiele plików zaczynających się od:

#!/usr/bin/python
# -*- encoding: <encoding name> -*-

=> kodowanie zamiast kodowania .

Jaki jest więc prawidłowy sposób deklarowania kodowania pliku?

Czy kodowanie jest dozwolone, ponieważ używane wyrażenie regularne jest leniwe? Czy jest to po prostu kolejna forma deklarowania kodowania pliku?

Zadaję to pytanie, ponieważ PEP nie mówi o kodowaniu , po prostu mówi o kodowaniu .

python encoding Oli
źródło
4
Nawiasem mówiąc, dla większej elastyczności i przenośności zaleca się używanie #!/usr/bin/env pythonzamiast#!/usr/bin/python
glarrain
7
Podoba mi się sposób, w jaki żadna z odpowiedzi na tej stronie nie ma prostego, działającego przykładu, na przykład UTF8. StackOverly w najlepszym wydaniu.
aaa90210
2
Chciałem tylko dodać, że Python 3 zmienił domyślne kodowanie z asciina UTF-8. Porównaj: dokumentacja Pythona 2.7 z dokumentacją Pythona 3.7 . Oznacza to, że możesz bezpiecznie pominąć to kodowanie, jeśli chcesz to określić UTF-8.
gertvdijk

Odpowiedzi:

161

Sprawdź dokumenty tutaj :

„Jeśli komentarz w pierwszej lub drugiej linii skryptu Pythona pasuje do wyrażenia regularnego coding[=:]\s*([-\w.]+), komentarz ten jest przetwarzany jako deklaracja kodowania”

„Zalecane formy tego wyrażenia to

# -*- coding: <encoding-name> -*-

który jest rozpoznawany również przez GNU Emacs i

# vim:fileencoding=<encoding-name>

który jest rozpoznawany przez VIM Brama Moolenaara. "

Możesz więc umieścić prawie wszystko przed częścią „kodowanie”, ale trzymaj się „kodowania” (bez przedrostka), jeśli chcesz być w 100% zgodny z zaleceniami python-docs.

Mówiąc dokładniej, musisz użyć wszystkiego, co jest rozpoznawane przez Python i określone oprogramowanie do edycji, z którego korzystasz (jeśli w ogóle coś potrzebuje / akceptuje). Np. codingForma jest rozpoznawana (po wyjęciu z pudełka) przez GNU Emacsa, ale nie przez Vima (tak, bez powszechnej zgody, jest to zasadniczo wojna o wpływy ).

Rafał Dowgird
źródło
10
Dlaczego -*-?
Iulian Onofrei
10
W -*-gwarantuje, że linia jest rozpoznawane przez GNU Emacs (edytora tekstu popularnej w niektórych programistów). Zauważ, że w przeciwieństwie do tej odpowiedzi, zarówno formularz Emacsa, jak i formularz Vima są w 100% kompatybilne z rekomendacjami python-docs (ponieważ oba pasują do wyrażenia regularnego - "dopasuj", zgodnie z długotrwałą konwencją, oznacza "dopasuj w dowolnym miejscu w string ”, w przeciwieństwie do API Pythona).
martinjs
1
Specyficzne wymagania Emacsa dla wbudowanych dyrektyw są udokumentowane na gnu.org/software/emacs/manual/html_node/emacs/… . W skrócie, format na początku pliku jest: <prefix>-*- var: value[; ...] -*-.
ivan_pozdeev
38

PEP 263:

pierwsza lub druga linia musi pasować do wyrażenia regularnego „kodowanie [: =] \ s * ([- \ w.] +)”

Zatem „en coding: UTF-8 ” pasuje.

PEP podaje kilka przykładów:

#!/usr/bin/python
# vim: set fileencoding=<encoding name> :

 

# This Python file uses the following encoding: utf-8
import os, sys
vartec
źródło
31

Po prostu skopiuj poniższą instrukcję wklej w górnej części programu, aby rozwiązać problemy z kodowaniem znaków

#!/usr/bin/env python
# -*- coding: utf-8 -*-
Harun ERGUL
źródło
3

Stan na dzień dzisiejszy - czerwiec 2018 r

PEP 263 sam wspomina wyrażenie regularne, które następuje:

Aby zdefiniować kodowanie kodu źródłowego, w plikach źródłowych należy umieścić magiczny komentarz jako pierwszy lub drugi wiersz w pliku, na przykład:

# coding=<encoding name>

lub (przy użyciu formatów rozpoznawanych przez popularne edytory):

#!/usr/bin/python
# -*- coding: <encoding name> -*-

lub:

#!/usr/bin/python
# vim: set fileencoding=<encoding name> :

Dokładniej, pierwsza lub druga linia musi pasować do następującego wyrażenia regularnego:

^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)

Tak więc, jak już podsumowano w innych odpowiedziach, będzie pasować codingdo dowolnego przedrostka, ale jeśli chcesz być tak zgodny z PEP, jak to tylko możliwe (nawet jeśli, o ile wiem, używanie encodingzamiast codingnie narusza PEP 263 w jakikolwiek sposób) - trzymaj się „zwykłego” coding, bez przedrostków.


źródło
1

Jeśli się nie mylę, oryginalna propozycja kodowania plików źródłowych polegała na użyciu wyrażenia regularnego w pierwszych kilku wierszach, co pozwoliłoby na jedno i drugie.

Myślę, że wyrażenie regularne było czymś w rodzaju, coding:po którym następuje coś.

Znalazłem to: http://www.python.org/dev/peps/pep-0263/ Co jest oryginalną propozycją, ale nie mogę znaleźć ostatecznej specyfikacji określającej dokładnie, co zrobili.

Z pewnością przywykłem encoding:do świetnego efektu, więc oczywiście to działa.

Spróbuj zmienić na coś zupełnie innego, na przykład duhcoding: ...sprawdź, czy to działa równie dobrze.

Lasse V. Karlsen
źródło
0

Podejrzewam, że jest podobny do Rubiego - każda metoda jest w porządku.

Dzieje się tak głównie dlatego, że różne edytory tekstu używają różnych metod (tj. Tych dwóch) oznaczania kodowania.

W Rubim, o ile pierwsza lub druga, jeśli istnieje linia shebang, zawiera ciąg pasujący:

coding: encoding-name

i ignorując wszelkie spacje i inne kłaczki w tych wierszach. (Często może to być również = zamiast:).

Matthew Schinckel
źródło