Zdravim,
Jak je mozne, ze "rot13" se zde zapisuje nerotovane a presto to funguje?
dozvi se prosty lid jake je spravne resni nebo bude dale tapat, o osviceny?
vitas
Ale ano, kdyz tak pekne prosis, prosty lide, zde je to, co povazuju za reseni:
Na zaklade petikrokoveho postupu bodu 3 kapitoly Concepts dokumentu
http://www.python.org/dev/peps/pep-0263/ dochazi k tomu, ze retezcove literaly
jsou nejdrive pomoci zadaneho kodovani dekodovany do UTF-8 a pak zpatky do
zadaneho kodovani souboru. Pro runtime jsou tedy k dispozici jako bajtove
sekvence tak, jak jsou zapsane v souboru. Pak ta runtime operace
.encode("rot13") prevede ten prvni retezec do citelne podoby (vlastne uz
podruhe).
Kdyby byly retezce zadane jako unicodove literaly u"...", tak by to takhle
nefungovalo.
Hezky blogpost: http://domnit.org/2007/10/encoded-python
Ke vsem dvema respondendum: Gratuluji, nebot jste vubec napsali. :-)
Vitasova prvni myslenka byla vlastne spravna, pak se nechal zviklat
interpretaci neuplne dokumentace.
Semik zacal urazkou Pythonu (kdo by to od toho vypelichance necekal, ze? :).
Pokracoval tez zarodkem dobre myslenky, i kdyz take nicim nepodlozene.
Skoncil opet stylove vykrikem jednookeho mezi slepymi. :)
Vyzadane vysvetleni smyslu: Rot-13 je jedna z hodne starych sifer. Jako
skryti souboru se zdrojakem by ji pouzil jen zoufalec. Zde jde o hricku.
Kodovani souboru se zdrojaky Pythonu je velmi uzitecne, potrebuji-li zadavat
do zdrojaku retezcove literaly v kodovani jinem nez ASCII.
Jeste zajimavost: Autor vyse zmineneho blogpostu se podivuje nad tim, ze
podobny priklad s kodovanim souboru base64 nefunguje. Problem je v tom, ze
znacka komentaru '#' se rot13-uje na '#', kdyz v base64 ma krizek zcela jinou
interpretaci:
>>> '#'.encode('base64')
'Iw==\n'
>>>
Takze zpracovani souboru
#!/usr/bin/env python
# coding: base64
cGFzcw==
selze uz na prvnim radku. PEP to pokryva touto zminkou:
Any encoding which allows processing the first two lines in the
way indicated above is allowed as source code encoding, ...
T.
|
