🚀 go-pugleaf

On 2010-03-02, Mirosław Zalewski <miniopl@CUT_THIS.gmail.com> wrote:
> Kod który dobrze obrazuje mój problem znajduje się pod adresem:
> http://wklej.fluxboxpl.org/10633
>
> Problem zaś polega na tym, że w obecnej formie funkcja wywołana na
> drugim adresie wywala
> „Wide character in subroutine entry at /usr/lib/perl/5.10/Encode.pm
> line 174.”
> przy próbie dekodowania z ISO-8859-2.
>
> Powodem są dwa znaki — \x{2019} (apostrof — ’) oraz \x{2026}
> (wielokropek — …) które w tym tekście się znajdują, a które nie
> wchodzą w skład ISO-8859-2. Na stronie są one encjami HTML (&rsquo; oraz
> &hellip;), jednak TreeBuilder zamienia je na notację \x{...} (nie wiem
> jak to nazwać).

Unicode.

> Gdybym w TreeBuilderze (57. linia powyższego kodu) nie
> podał żadnego argumentu as_HTML, wtedy te dwa znaki dalej pozostałyby
> encjami, i dzięki decode_entities uzyskałbym ładne znaki z zakresu
> UTF-8, ale z kolei pierwsze wywołanie funkcji zwróci sieczkę.

W kod się nie wgryzałem, ale na moje oko najpierw powinieneś zamienić
tekst na UTF (encje bez rozwijania), a potem encje w tekście UTF na
tekst UTF.

-- 
Secunia non olet.
Stanislaw Klekot

On Tue, 2 Mar 2010 21:35:35 +0100, Mirosław Zalewski wrote:

> Problemem jest wyraźnie HTML::TreeBuilder, który z jakiegoś powodu źle
> zamienia polskie znaki diakrytyczne zapisane w ISO-8859-2 na encje HTML
> (ą -> ± -> ±). Tak więc alternatywnym rozwiązaniem może być
> transliteracja tak zniekształconego tekstu na poprawny (liczba polskich
> znaków diakrytycznych jest skończona i znana mi). Jednak to rozwiązanie
> też nie wydaje mi się najlepszym z możliwych...
> 
> Może ktoś z Grupowiczów ma pomysł na inne rozwiązanie tego problemu?
> Może mi powiedzieć coś czego nie wiem, a co być może mnie na nie
> nakieruje?

Mhm. Nie wiesz tego, że metoda content(), której używasz w linii 32,
kompletnie olewa charset pobranej strony i traktuje zawartość tak, jakby
była w ISO-8859-1. Jeśli w tekście źródłowym było "ą", które ma kod 177 w
8859-2, to content() przyjmie, że chodziło o znak ± (plusminus), który ma
ten sam kod w 8859-1, i na wyjściu da ten właśnie znak (tylko już w
Unicode), a HTML::TreeBuilder (dokładnie zaś metoda as_HTML) zrobi z niego
encję ± zupełnie słusznie. 

Użyj decoded_content() zamiast content(), pomiń całkowicie linie 64 i 68, bo
nie masz już czego rozkodowywać, a wszystko będzie w porządku. 

-- 
Szymon Sokół (SS316-RIPE) -- Network Manager                                 B
Computer Center, AGH - University of Science and Technology, Cracow, Poland  O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982  F
Free speech includes the right not to listen, if not interested -- Heinlein  H

marzec roku pamiętnego 2010, prawdopodobnie 02. Wielka mądrość na
czytelników pl.comp.lang.perl spłynęła, gdy tako rzekł(a) Szymon Sokół:

> Mhm. Nie wiesz tego, że metoda content(), której używasz w linii 32,
> kompletnie olewa charset pobranej strony i traktuje zawartość tak,
> jakby była w ISO-8859-1. 

Nie wiedziałem tego. Do głowy mi nie przyszło żeby wertować
dokumentację do LWP::UserAgent i modułów zależnych z HTTP (konkretniej
HTTP::Message, gdzie opis tejże funkcji się znajduje). Byłem przekonany
że powinienem coś gdzieś przełączyć przy TreeBuilderze. Jak widać
szukałem w złym miejscu.

> Użyj decoded_content() zamiast content(), pomiń całkowicie linie 64 i
> 68, bo nie masz już czego rozkodowywać, a wszystko będzie w porządku. 

Masz rację. Zrobiłem tak i faktycznie wszystko działa tak jak
oczekiwałem.

Dziękuję bardzo za tak rzeczową i szybką pomoc :) .
-- 
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
                       Mirosław Zalewski