eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › kolejne pytanie z pythona
Ilość wypowiedzi w tym wątku: 11

  • 1. Data: 2020-04-15 02:58:06
    Temat: kolejne pytanie z pythona
    Od: fir <p...@g...com>

    mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
    takich bledow)

    generalnie moj bot (w pythonie 2.7)
    czyta linijke z czata przez

    ircmsg = ircsock.recv(2048)

    i nic na tym nie robie nie wywoluje ani zadnego decode ani encode

    i np polskie litery w tym dzialaja (są) choc nie wiem jaki to format, moge wyciac z
    tego np kawalek i wyslac do translatora google, odeslany tekst tez zawiera egzotyczne
    znaki

    ten wygenerowany tekst odsylam przez

    ircsock.send(s.encode('UTF-8'))

    bez tego encode to to raczej nie dziala
    ale z tym encode dziala

    problem pojawia sie gdy te linijki w srodku
    wstawiam do slownika ktory zapisuje do pliku json na dysk

    czytam i zapisuje ten json ze tak powiem normalnie bez zadnych udziwnien

    bo jesli chce dodac "KóKó" do tego slowniek ai zapisac toz apisze sie to normalnie,
    natomiast gdy chce to odczytac i wyslac na kanal to robie

    s = bot_memory[key]
    say(s.decode('UTF-8'))

    bez tego decode nie dziala (leci blad)
    z tym decode co prawda tez leci blad tylko inny

    (przy czym moze dodam ze slownik czytam tylko raz na strcie programu z dsku,
    natomiast zapisuje przy kazdym wstawieniu tekstu)

    jesli jest to decode to moge zapisywac wpisy na dysk i moge je czytac ze slowniek i
    wyswietlac na kanal - ale tylko poki nie zamkne bota i nie wczytam tego z dysku,
    wtedy przy probie odczytania wpisu i wyslania go na kanal z tego leci blad (ascii
    codect cant encode...)

    z kolei jak to decode wywale jest
    odwrotnie, po uruchomieniu boyta moge
    wysylac zapisane za poprzednim razem wpisy na kanal ale nie moge zapisac i odczytac
    nowego, tj dokladniej w pliku tez sie zapisuje ale odczytanie go ze slownika i proba
    poslania na kanal dale blad (ascii codec cant decode...)

    o co tu chodzi? jak to naprawic?


  • 2. Data: 2020-04-15 03:36:35
    Temat: Re: kolejne pytanie z pythona
    Od: fir <p...@g...com>

    W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
    takich bledow)
    >
    > generalnie moj bot (w pythonie 2.7)
    > czyta linijke z czata przez
    >
    > ircmsg = ircsock.recv(2048)
    >
    > i nic na tym nie robie nie wywoluje ani zadnego decode ani encode
    >
    > i np polskie litery w tym dzialaja (są) choc nie wiem jaki to format, moge wyciac
    z tego np kawalek i wyslac do translatora google, odeslany tekst tez zawiera
    egzotyczne znaki
    >
    > ten wygenerowany tekst odsylam przez
    >
    > ircsock.send(s.encode('UTF-8'))
    >
    > bez tego encode to to raczej nie dziala
    > ale z tym encode dziala
    >
    > problem pojawia sie gdy te linijki w srodku
    > wstawiam do slownika ktory zapisuje do pliku json na dysk
    >
    > czytam i zapisuje ten json ze tak powiem normalnie bez zadnych udziwnien
    >
    > bo jesli chce dodac "KóKó" do tego slowniek ai zapisac toz apisze sie to normalnie,
    natomiast gdy chce to odczytac i wyslac na kanal to robie
    >
    > s = bot_memory[key]
    > say(s.decode('UTF-8'))
    >
    > bez tego decode nie dziala (leci blad)
    > z tym decode co prawda tez leci blad tylko inny
    >
    > (przy czym moze dodam ze slownik czytam tylko raz na strcie programu z dsku,
    natomiast zapisuje przy kazdym wstawieniu tekstu)
    >
    > jesli jest to decode to moge zapisywac wpisy na dysk i moge je czytac ze slowniek i
    wyswietlac na kanal - ale tylko poki nie zamkne bota i nie wczytam tego z dysku,
    wtedy przy probie odczytania wpisu i wyslania go na kanal z tego leci blad (ascii
    codect cant encode...)
    >
    > z kolei jak to decode wywale jest
    > odwrotnie, po uruchomieniu boyta moge
    > wysylac zapisane za poprzednim razem wpisy na kanal ale nie moge zapisac i odczytac
    nowego, tj dokladniej w pliku tez sie zapisuje ale odczytanie go ze slownika i proba
    poslania na kanal dale blad (ascii codec cant decode...)
    >
    > o co tu chodzi? jak to naprawic?

    ok po napisaniu tego wyzej jakas luzna dedukcja sklonila mnie do wniosku ze skoro w
    pliku jest dobrze (a chyab mozna tak zalozyc) to wersja

    s = bot_memory[key]
    say(s)

    jest poprawniejsza (chwilowo te leko zagmatwane dedukcje mi sie lekko zgubily)

    i ze widac cos ze wstawianiem do slwnika moze jest nie tak

    sprobowalem
    bot_memory[key]=value.decode('UTF-8')
    save_bot_memory()

    przy wstawianiu i chyba dziala ok, nie zebym super do konca rozumial o co tu chodzi

    trzeba dodac ze te nazwy encode i decode sa dosyc mylace

    wyglada na to ze tw stringi ktore lataja w srodku programu to utf8 , a te wstawiane
    do slownika nalezy przerabiac na bajty? inna lekka dziwnosc to tak jakby z tego
    socketa do czytania juz wychodzilo utf-8 przy wysylaniu przerabiam na bajty a przy
    czytaniu nie musze z bajtow na utf8?

    dibrze ze chociaz chyba dziala


  • 3. Data: 2020-04-15 12:54:14
    Temat: Re: kolejne pytanie z pythona
    Od: g...@g...com

    W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
    takich bledow)
    [...]
    > o co tu chodzi? jak to naprawic?

    Python 2.7 jest od tego roku oficjalnie niewspierany.
    Nie wiem, po co go używać, zwłaszcza do nowego projektu.

    Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
    poprawione.

    Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').

    Może pomoże.


  • 4. Data: 2020-04-15 13:45:23
    Temat: Re: kolejne pytanie z pythona
    Od: fir <p...@g...com>

    W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com napisał:
    > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
    takich bledow)
    > [...]
    > > o co tu chodzi? jak to naprawic?
    >
    > Python 2.7 jest od tego roku oficjalnie niewspierany.
    > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
    >
    > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
    poprawione.
    >
    > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
    >
    > Może pomoże.

    powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
    glupia - roznie to bywa

    ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te starsze sa
    czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle szybsze i
    prostsze)

    moge oczywiscie przeniesc sie i porownac

    ten problem chyba naprawilem jak wyzej,
    sek w tym ze czasem jak cos koduje to nie bardzo mam czas zatrzymywac sie i
    uczyc lyb przemysliwac pewne rzeczy co
    poki mam pare jest slusznym wyborem bo
    lpiej gnac do przodu
    (kiedy sie da, a zatrzymywac kiedy sie nie da.. powinienem moze dodac slowko
    'pewnie', pewni elepiej gnac do przodu gdy sie da)

    python ogolnie dosyc ciekawy, faktycznie warto sie nauczyc..kodowanie w nim jest
    osobliwie bezstresowe, ma sie wrazenie ze te uzywane biblioteczki kompletnie zdejmuja
    stres z czlowieka, rowniez reportowanie bledow jest jakies dobre,
    za to brakuje pewnych elementow cukru z c







  • 5. Data: 2020-04-15 14:48:23
    Temat: Re: kolejne pytanie z pythona
    Od: g...@g...com

    W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
    > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
    napisał:
    > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony
    do takich bledow)
    > > [...]
    > > > o co tu chodzi? jak to naprawic?
    > >
    > > Python 2.7 jest od tego roku oficjalnie niewspierany.
    > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
    > >
    > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
    poprawione.
    > >
    > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
    > >
    > > Może pomoże.
    >
    > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
    > glupia - roznie to bywa

    Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie sprawdza.

    Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest "lepsze".

    > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te starsze sa
    czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle szybsze i
    prostsze)

    W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
    Żadna nie jest bardziej "true" czy "raw".
    Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
    (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej skopane, niż
    w Pythonie 2)


  • 6. Data: 2020-04-15 15:01:34
    Temat: Re: kolejne pytanie z pythona
    Od: fir <p...@g...com>

    W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik g...@g...com napisał:
    > W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
    > > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
    napisał:
    > > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony
    do takich bledow)
    > > > [...]
    > > > > o co tu chodzi? jak to naprawic?
    > > >
    > > > Python 2.7 jest od tego roku oficjalnie niewspierany.
    > > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
    > > >
    > > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
    poprawione.
    > > >
    > > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
    > > >
    > > > Może pomoże.
    > >
    > > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
    > > glupia - roznie to bywa
    >
    > Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie sprawdza.
    >
    > Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest
    "lepsze".
    >
    > > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te starsze
    sa czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle szybsze i
    prostsze)
    >
    > W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
    > Żadna nie jest bardziej "true" czy "raw".
    > Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
    > (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej skopane,
    niż w Pythonie 2)

    moze kolega podac przyklady i konkretne opinie bo inaczej taka dyskusja jest troche
    pusta.. moge przecztac bo sie interesuje oststnie pare dni tym pythionem (poki mi nie
    minie pewnia za jakies 2-3 dni)


  • 7. Data: 2020-04-15 15:53:09
    Temat: Re: kolejne pytanie z pythona
    Od: g...@g...com

    W dniu środa, 15 kwietnia 2020 15:01:37 UTC+2 użytkownik fir napisał:
    > W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik g...@g...com
    napisał:
    > > W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
    > > > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
    napisał:
    > > > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > > > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem
    przyzwczajony do takich bledow)
    > > > > [...]
    > > > > > o co tu chodzi? jak to naprawic?
    > > > >
    > > > > Python 2.7 jest od tego roku oficjalnie niewspierany.
    > > > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
    > > > >
    > > > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach
    zostało poprawione.
    > > > >
    > > > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
    > > > >
    > > > > Może pomoże.
    > > >
    > > > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
    > > > glupia - roznie to bywa
    > >
    > > Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie
    sprawdza.
    > >
    > > Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest
    "lepsze".
    > >
    > > > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te
    starsze sa czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle
    szybsze i prostsze)
    > >
    > > W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
    > > Żadna nie jest bardziej "true" czy "raw".
    > > Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
    > > (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej skopane,
    niż w Pythonie 2)
    >
    > moze kolega podac przyklady i konkretne opinie bo inaczej taka dyskusja jest troche
    pusta.. moge przecztac bo sie interesuje oststnie pare dni tym pythionem (poki mi nie
    minie pewnia za jakies 2-3 dni)


    Jeżeli idzie o Pythona jako takiego, to np. to:

    >>> def f(x={})
    ... return x

    >>> a = f()
    >>> a
    {}

    >>> b = f()
    >>> b
    {}

    >>> a['x'] = 5
    >>> a
    {'x':5}

    >>> b
    {'x':5}

    Strasznie głupie.

    Albo GIL.

    Albo "piekło wersji", które zmusza do instalowania virtualenv.

    Albo upośledzone lambda-wyrażenia.

    Albo skopane zasięgi w "comprehensions" - na przykład, jeżeli napiszesz

    powers = [lambda x: x**i for i in range(10)]

    to jaką wartość będzie miało wyrażenie

    powers[3](2)

    ?

    I tak dalej.


    Jeżeli zaś idzie o przejście z Pythona 2 do Pythona 3, to sądzę, że uspójnienie
    instrukcji "print" z innymi funkcjami i wymaganie, żeby pisać

    print(x)

    zamiast

    print x

    było samo w sobie strasznie głupie.


  • 8. Data: 2020-04-15 17:01:32
    Temat: Re: kolejne pytanie z pythona
    Od: fir <p...@g...com>

    W dniu środa, 15 kwietnia 2020 15:53:11 UTC+2 użytkownik g...@g...com napisał:
    > W dniu środa, 15 kwietnia 2020 15:01:37 UTC+2 użytkownik fir napisał:
    > > W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik g...@g...com
    napisał:
    > > > W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
    > > > > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
    napisał:
    > > > > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
    > > > > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem
    przyzwczajony do takich bledow)
    > > > > > [...]
    > > > > > > o co tu chodzi? jak to naprawic?
    > > > > >
    > > > > > Python 2.7 jest od tego roku oficjalnie niewspierany.
    > > > > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
    > > > > >
    > > > > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach
    zostało poprawione.
    > > > > >
    > > > > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
    > > > > >
    > > > > > Może pomoże.
    > > > >
    > > > > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest
    dosyc
    > > > > glupia - roznie to bywa
    > > >
    > > > Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie
    sprawdza.
    > > >
    > > > Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest
    "lepsze".
    > > >
    > > > > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te
    starsze sa czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle
    szybsze i prostsze)
    > > >
    > > > W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
    > > > Żadna nie jest bardziej "true" czy "raw".
    > > > Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
    > > > (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej
    skopane, niż w Pythonie 2)
    > >
    > > moze kolega podac przyklady i konkretne opinie bo inaczej taka dyskusja jest
    troche pusta.. moge przecztac bo sie interesuje oststnie pare dni tym pythionem (poki
    mi nie minie pewnia za jakies 2-3 dni)
    >
    >
    > Jeżeli idzie o Pythona jako takiego, to np. to:
    >
    > >>> def f(x={})
    > ... return x
    >
    > >>> a = f()
    > >>> a
    > {}
    >
    > >>> b = f()
    > >>> b
    > {}
    >
    > >>> a['x'] = 5
    > >>> a
    > {'x':5}
    >
    > >>> b
    > {'x':5}
    >
    > Strasznie głupie.
    >
    > Albo GIL.
    >
    > Albo "piekło wersji", które zmusza do instalowania virtualenv.
    >
    > Albo upośledzone lambda-wyrażenia.
    >
    > Albo skopane zasięgi w "comprehensions" - na przykład, jeżeli napiszesz
    >
    > powers = [lambda x: x**i for i in range(10)]
    >
    > to jaką wartość będzie miało wyrażenie
    >
    > powers[3](2)
    >
    > ?
    >
    > I tak dalej.
    >
    >
    > Jeżeli zaś idzie o przejście z Pythona 2 do Pythona 3, to sądzę, że uspójnienie
    instrukcji "print" z innymi funkcjami i wymaganie, żeby pisać
    >
    > print(x)
    >
    > zamiast
    >
    > print x
    >
    > było samo w sobie strasznie głupie.

    do tego wyzej jeszcze nie dotarlem atk ze nie wiem

    co do ostatniego to samo zrobienie drugeigo bardzo podobnego jezyka ale
    niekompatybilnego bylo straszna rzeczą

    jeli robic drugi to mogli poczekaz az zbierze sie tak duzo niekompatybilnych zmien az
    uczyni to inny jezyk .. i wtedy trzeba ciagnac oba (jakoz e pierwszy juz byl
    popularny) ..
    produkowanie dwu podobnych zakrawa na powazny (uciazliwy dla userow) blad

    na szczescie nie zmienia to sytuacji ze bota sie koduje w tym naprawde swietnie


  • 9. Data: 2020-04-15 21:14:29
    Temat: Re: kolejne pytanie z pythona
    Od: Piotr Chamera <p...@p...onet.pl>

    W dniu 2020-04-15 o 02:58, fir pisze:
    > (...)>
    > jesli jest to decode to moge zapisywac wpisy na dysk i moge je czytac ze slowniek i
    wyswietlac na kanal - ale tylko poki nie zamkne bota i nie wczytam tego z dysku,
    wtedy przy probie odczytania wpisu i wyslania go na kanal z tego leci blad (ascii
    codect cant encode...)
    >
    > z kolei jak to decode wywale jest
    > odwrotnie, po uruchomieniu boyta moge
    > wysylac zapisane za poprzednim razem wpisy na kanal ale nie moge zapisac i odczytac
    nowego, tj dokladniej w pliku tez sie zapisuje ale odczytanie go ze slownika i proba
    poslania na kanal dale blad (ascii codec cant decode...)
    >
    > o co tu chodzi? jak to naprawic?

    Zwróć uwagę, że w pythonie 2.x są dwa rodzaje stringów: ośmiobitowe
    (bajtowe) i unikodowe, a z jednych na drugie przechodzisz przez encode()
    i decode().
    Jeśli nie zachowasz dyscypliny i nie wiesz jakie kodowania masz w
    poszczególnych stringach bajtowych, to dzieją się ,,cuda" o których
    piszesz wyżej.


    przykład:

    Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500
    64 bit (AMD64)] on win32

    >>> import sys
    >>> sys.stdin.encoding # sprawdzamy jakie jest domyślne kodowanie konsoli
    'cp1250'

    >>> s1 = "aą" # zwykły ośmiobitowy string, kodowanie cp1250
    >>> s2 = u"aą" # string unicode, automatycznie przekodowany z konsoli
    na unicode

    >>> s1
    'a\xb9'

    >>> s2
    u'a\u0105'

    s1 nie ,,pamięta" swojego kodowania, można go dowolnie zinterpretować

    >>> s1.decode(encoding="cp1250")
    u'a\u0105'

    >>> s1.decode(encoding="iso8859-2")
    u'a\u0161'

    >>> s1.decode(encoding="cp1256")
    u'a\xb9'

    s2 też można ,,spaprać", jeśli się go przepuści przez niekompatybilne
    kodowania bajtowe, np.:

    >>> s2.encode(encoding="utf8").decode(encoding="cp1250")
    u'a\xc4\u2026'
    >>> print s2.encode(encoding="utf8").decode(encoding="cp1250")
    aÄ...


    Rozwiązanie problemu jest takie jak w innych językach:
    - znać kodowania wejściowe
    - dekodować wejścia do jednego wspólnego dla całej aplikacji kodowania
    (najczęściej unicode, ewentualnie utf-8) i na nim pracować
    - znać kodowania wyjściowe i wyjścia kodować odpowiednio do wymagań


  • 10. Data: 2020-04-15 21:27:41
    Temat: Re: kolejne pytanie z pythona
    Od: Piotr Chamera <p...@p...onet.pl>


    Postscriptum odnośnie:
    > W dniu 2020-04-15 o 02:58, fir pisze: >>... leci blad (ascii codect cant encode...)
    Widocznie robisz jakąś automatyczną konwersję, np zapisywanie stringa
    unikodowego do pliku itp. jeśli nie podasz kodowania, to domyślne jest
    "ascii" i każdy znak w tekście z kodem powyżej 127 wyrzuci błąd

    >>> s2.encode()

    Traceback (most recent call last):
    File "<pyshell#26>", line 1, in <module>
    s2.encode()
    UnicodeEncodeError: 'ascii' codec can't encode character u'\u0105' in
    position 1: ordinal not in range(128)

    trzeba podać kodowanie bajtowe do jakiego chcesz tekst przekształcić

    >>> s2.encode(encoding="utf8")
    'a\xc4\x85'

    >>> s2.encode(encoding="iso8859-2")
    'a\xb1'

    albo zignorować błędy

    >>> s2.encode(encoding="ascii", errors="ignore")
    'a'

    >>> s2.encode(encoding="ascii", errors="replace")
    'a?'

strony : [ 1 ] . 2



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: