witam, poszło również na pl.comp.lang.python, ale tam jakby mniejszy ruch
jest...

mam kilkaset plików tekstowych, które muszę połączyć w jeden plik, usuwając
wcześniej określone linie i dokonując zmian w poszczególnych polach w
tekście (taka forma tekstowej bazy danych).

Na początku zająłem się usuwaniem samych linii:

outfile=open("name.txt",'w')
for file in filenames:
text=open(file)
lines=text.readlines()
outfile.writelines(lines[3:]) #zapisz wszystkie linie począwszy od
3-ciej
text.close
outfile.close


I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
decode byte ... in position ...:character mapt to <undifined>

czyli wg mnie w jednym z plików pojawiło się inne kodowanie niż standardowe.
Stąd program się wykrzaczył. Nie potrafię określić, jakiego rodzaju
kodowanie pojawi się w plikach wejściowych, nie jest to zależne ode mnie.


Kombinowałem z text=open(file,'rb') a następnie jakiś split('\r\n'), żeby
uzyskać podział na linie i jednocześnie uniezależnić się od kodowania.
Niestety za każdym razem dostawałem komunikat o braku możliwości użycia
funkcji operujących na stringu na buforze API.

Jakaś podpowiedź koledzy?


--
didi

do góry

Użytkownik "didi" <d...@d...com> napisał w wiadomości
news:h2hvke$456$1@news.wp.pl...
> outfile=open("name.txt",'w')
> for file in filenames:
> text=open(file)
> lines=text.readlines()
> outfile.writelines(lines[3:]) #zapisz wszystkie linie począwszy od
> 3-ciej
> text.close
> outfile.close
>
>
> I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
> decode byte ... in position ...:character mapt to <undifined>
>


Zamiast Pythona 3xx użyłem wersję 2xx, które z defaultu nie konwertuje do
postaci Unicode. Głupie, ale w moim przypadku bardzo skuteczne i
wystarczające.


--
didi

do góry

On 2 Lip, 14:01, "didi" <d...@d...com> wrote:
> Użytkownik "didi" <d...@d...com> napisał w
wiadomościnews:h2hvke$456$1@news.wp.pl...
>
> > outfile=open("name.txt",'w')
> > for file in filenames:
> >    text=open(file)
> >    lines=text.readlines()
> >    outfile.writelines(lines[3:])  #zapisz wszystkie linie począwszy od
> > 3-ciej
> >    text.close
> > outfile.close
>
> > I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
> > decode byte ... in position ...:character mapt to <undifined>
>
> Zamiast Pythona 3xx użyłem wersję 2xx, które z defaultu nie konwertuje do
> postaci Unicode.

Oj wygląda na to, że Python zmierza w złym kierunku ... Szkoda.

Przeczytałem twój post jakiś czas temu i zastanawiałem się jak to
możliwe...
100 razy pisałem coś podobnego i działało.

A tu okazuje się, że dla Pythona NG wszystko to tekst. Brawo... No i
brawo
za stabilne API ... a właśnie przymierzałem się do sprawdzenia py3k,
odłożę
na nigdy.

ZZ

do góry

On 02.07.2009, Zbigniew Zagórski wrote:
> On 2 Lip, 14:01, "didi" <d...@d...com> wrote:
>> Użytkownik "didi" <d...@d...com> napisał w
wiadomościnews:h2hvke$456$1@news.wp.pl...
>>
>> > outfile=open("name.txt",'w')
>> > for file in filenames:
>> >    text=open(file)
>> >    lines=text.readlines()
>> >    outfile.writelines(lines[3:])  #zapisz wszystkie linie począwszy od
>> > 3-ciej
>> >    text.close
>> > outfile.close
>>
>> > I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
>> > decode byte ... in position ...:character mapt to <undifined>
>>
>> Zamiast Pythona 3xx użyłem wersję 2xx, które z defaultu nie konwertuje do
>> postaci Unicode.
>
> Oj wygląda na to, że Python zmierza w złym kierunku ... Szkoda.
>
> Przeczytałem twój post jakiś czas temu i zastanawiałem się jak to
> możliwe...
> 100 razy pisałem coś podobnego i działało.
>
> A tu okazuje się, że dla Pythona NG wszystko to tekst. Brawo... No i
> brawo
> za stabilne API ...

A myślisz że niby czemu to jest 3.x, a nie 2.8? Właśnie przez zmianę
sposobu działania łamiącą kompatybilność ze starszymi wersjami.

> a właśnie przymierzałem się do sprawdzenia py3k,
> odłożę
> na nigdy.


--
Stanislaw Klekot

do góry

Zbigniew Zagórski <z...@g...com> writes:

> On 2 Lip, 14:01, "didi" <d...@d...com> wrote:
>> Użytkownik "didi" <d...@d...com> napisał w
wiadomościnews:h2hvke$456$1@news.wp.pl...
>>
>> > outfile=open("name.txt",'w')
>> > for file in filenames:
>> >    text=open(file)
>> >    lines=text.readlines()
>> >    outfile.writelines(lines[3:])  #zapisz wszystkie linie począwszy od
>> > 3-ciej
>> >    text.close
>> > outfile.close
>>
>> > I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
>> > decode byte ... in position ...:character mapt to <undifined>
>>
>> Zamiast Pythona 3xx użyłem wersję 2xx, które z defaultu nie konwertuje do
>> postaci Unicode.
>
> Oj wygląda na to, że Python zmierza w złym kierunku ... Szkoda.

Taki wielgachny wnioch na podstawie tak drobnego nieporozumienia? ;)

> Przeczytałem twój post jakiś czas temu i zastanawiałem się jak to
> możliwe...
> 100 razy pisałem coś podobnego i działało.
>
> A tu okazuje się, że dla Pythona NG wszystko to tekst. Brawo... No i
> brawo

No chyba po to wymyślono dwa tryby otwarcia pliku:
1. tekstowy - do czytania właśnie *tekstu*
2. binarny - do czytania bajtów

> za stabilne API ... a właśnie przymierzałem się do sprawdzenia py3k,
> odłożę
> na nigdy.

Masz na myśli stabilne API pomiędzy 2.x i 3.x?
Cały sens powstania wersji 3.x sprowadza się do tego,
aby nie być zmuszonym wstecznej kompatybilności z 2.x.
Akurat w kwestii I/O i "bajty vs stringi vs unicode" w 3.x nastąpiły
bardzo znaczące zmiany:
http://docs.python.org/3.1/whatsnew/3.0.html#text-vs
-data-instead-of-unicode-vs-8-bit

Aczkolwiek nie jakieś znowu rewolucyjne. Model bardzo zbliżony do java'owego.
W tym konkretnym przypadku, który doprowadził Cię do tak drastycznych
wniosków wystarczyło zamiast:

open(file)

napisać:

open(file, errors='replace')

co jest napisane wołami w dokumentacji.
Java różni się tym, że przy błędnym kodowaniu nie rzuca wyjątku,
lecz traktuje taką sytuację jako niezdefiniowaną.
Python dodaje tu dodatkową możliwość kontroli i jeszcze zbiera
za to cięgi. Echhh... ;)

RW

do góry

On 2 Lip, 22:40, Rob Wolfe <r...@s...pl> wrote:
> Zbigniew Zagórski <z...@g...com> writes:
> > On 2 Lip, 14:01, "didi" <d...@d...com> wrote:
> >> Użytkownik "didi" <d...@d...com> napisał w
wiadomościnews:h2hvke$456$1@news.wp.pl...
>
> >> > outfile=open("name.txt",'w')
> >> > for file in filenames:
> >> >    text=open(file)
> >> >    lines=text.readlines()
> >> >    outfile.writelines(lines[3:])  #zapisz wszystkie linie począwszy od
> >> > 3-ciej
> >> >    text.close
> >> > outfile.close
>
> >> > I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
> >> > decode byte ... in position ...:character mapt to <undifined>
>
> >> Zamiast Pythona 3xx użyłem wersję 2xx, które z defaultu nie konwertuje do
> >> postaci Unicode.
>
> > Oj wygląda na to, że Python zmierza w złym kierunku ... Szkoda.
>
> Taki wielgachny wnioch na podstawie tak drobnego nieporozumienia? ;)

No może trochę za wielgachny... Ale i tak trochę mi śmierdzi ... o tym
niżej

>
> > Przeczytałem twój post jakiś czas temu i zastanawiałem się jak to
> > możliwe...
> > 100 razy pisałem coś podobnego i działało.
>
> > A tu okazuje się, że dla Pythona NG wszystko to tekst. Brawo... No i
> > brawo
>
> No chyba po to wymyślono dwa tryby otwarcia pliku:
> (...)
> Masz na myśli stabilne API pomiędzy 2.x i 3.x?
> Cały sens powstania wersji 3.x sprowadza się do tego,
> aby nie być zmuszonym wstecznej kompatybilności z 2.x.
> Akurat w kwestii I/O i "bajty vs stringi vs unicode" w 3.x nastąpiły
> bardzo znaczące zmiany:http://docs.python.org/3.1/whatsnew/3.0.html#
text-vs-data-instead-of-...

Zgoda ...

> Aczkolwiek nie jakieś znowu rewolucyjne. Model bardzo zbliżony do java'owego.
> W tym konkretnym przypadku, który doprowadził Cię do tak drastycznych
> wniosków wystarczyło zamiast:
>
> open(file)
>
> napisać:
>
> open(file, errors='replace')

No sorka, to jest odczytywanie z translacją. Całkowicie odpada.

> co jest napisane wołami w dokumentacji.
> Java różni się tym, że przy błędnym kodowaniu nie rzuca wyjątku,
> lecz traktuje taką sytuację jako niezdefiniowaną.
> Python dodaje tu dodatkową możliwość kontroli i jeszcze zbiera
> za to cięgi. Echhh... ;)

Przeczytałem o tym wszystkim - po napisaniu postu - i ... oryginalny
poster pisał coś o tym, że próbował open(...,"rb"), i że też nie
działa.
Wygląda na to, że to on nie przeczytał dokumentacji - ani nie
pochwalił
się, że odpala to na py3k.

A wracając do cięgów. Nie siedzę ostatnio w Pythonie - jakoś mi się
z nim drogi rozeszły ale ... (nie czytałem żadnego flejma na ten temat
Py3k
więc opinia jest bardzo "IMHO") i tak uważam, że włożenie Unicode do
"normalnych" plików - i to domyślnie - jest nie na miejscu. Kodowanie
I/O
jest rzeczą wysoce zależną od aplikacji i powinno być używane w sposób
świadomy a nie gdzieś pod spodem korzystając z aktualnego locale.
To nie jest sprawa języka tylko projektu biblioteki. Mogli zostawić
jak było (czyli domyślnie "bytes") bez szkody dla innowacyjności Py3k
jako całości.

Z drugiej, strony podział na "text" i "bytes" (czy jak to tam
było) jest świetnym posunięciem.

BR,
ZZ

do góry