-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrelatorio.tex
125 lines (75 loc) · 5.29 KB
/
relatorio.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
\section{Parser}
O parser deveria ser mais do que um simples extrator de URL de tags 'a'.
Como não era possível usar um parser HTML pronto nem depender de expressões regulares, acaba sendo necessário então escrever um pequeno parser \emph{push} para HTML.
Toda a infra-estrutura criada para esse parar será futuramente re-utilizada para o indexador. Dessa forma, preferimos no extender um pouco mais na sua criação, garantindo assim ganho de tempo na versao do indexador e, ao mesmo tempo, garantindo que o nosso parser seja mais do que capaz de lidar com a tarefa que lhe é solicitada no momento.
Observer os documentos HTML existentes na Web atual não totalmente válidos e/ou bem formado se confrontados com os padroes existentes e publicados pela W3C para html. Mais Do que isso, os documentos da web atual são uma mistura de documentos HTML e XML e nem todos eles são documentos bem formados. Dessa forma
\begin{itemize}
\item Devido a essa mescla de XML e HTML, o parser deveria ser capaz de lidar com a maioria das construções de XML e HTML e ser capaz de lidar com documentos de se situam no interim desses dois padrões, mesmo em se tratando de erros.
\item Mais do que isso, o parser deve ser capaz de lidar dom
\item o parser deveria ser bem toleante a erros e tolerar documentos mal-formados da mesma forma com que os navegadores toleram.
Oscilar entre os padrões.... Tags de fechamento, de abertura, atributos sem
valor, com seu conteudo não delimitado por \" ou \'. Tentamos conciliar o
compromisso de pegar todo o texto que um navegador fosse capaz de interpretar
mas lidar com erros corretamente.
\end{itemize}
Dessa forma, para que o parser cumprisse sua função de extrair o máximo de informação útil possível de páginas, de maneira similar ao navegadores. Para isso, tentamos garantir que ele se comporta-se tão próximo dos modelos de fererência quanto possível (Firefox, BeautifulSoup). Entretanto, isso nos levou a algumas escolhas quanto á forma de lidar com erro que vão de encontro até mesmo com a especificação de XML e HTML.
No fragmento abaixo, de acordo com as especificaçõe de XML, não existe nenhuma tag:
\verbatim{<a&whatever duplas="x" simples='what' html=antigo attrhtml />}
Isso deve-se pela especificação do que pode ser o nome (\emph{Name}) de uma tag, e o caractere \& não faz parte dele. Entretanto, para esse exemplo, o firefox reconhece a existência de uma tag 'a&whatever', enquanto o BeautifulSoup reconhece a existência de uma tag 'a'.
Nossa queremos seguir o firefox tanto quanto possível.
\subsection{Tags Especiais}
Script, Style, textarea e blocos XML CDATA não devem ter seu conteúdo processados pelo parser.
Tags empty (que fecham sozinhas). Por isso, nosso parser difere de outros por
já sinalizar que uma tag é auto-closing. Isso permite ao programador
diferenciar se essa é uma Start Tag normal, o que torna possívevl ao usuário
avançar forçosamente o texto para o local onde a tag de fechamento está,
ignorando assim seu conteúdo e protegendo o próprio parser, ou se ela é uma tag
Empty, o que não torna necessário nenhuma intervenção do usuário.
\section{URL}
RFC 3986
http://en.wikipedia.org/wiki/URL_normalization
http://en.wikipedia.org/wiki/Percent-encoding
% vim:fileencoding=utf-8:syn=tex:ai:tw=72:smartindent:
% vim:spell:spelllang=pt:
\section{Detecção de Mapas de Caracteres}
\subsection{Mapas de Caracteres, Unicode e Codificação de Texto}
BOM, UTF-8
\subsection{Problemas na decodificação de textos na Web}
Em algumas situações não teremos informações sobre charset: o HTTP não
informou, não existe informação no documento. Assumiremos utf-8 e, em
último caso, Latin1 caso.
(This is harder than it sounds, because standards can overlap. If
you fetch an XML document over HTTP, you need to support both
standards and figure out which one wins if they give you conflicting
information.)
Sometimes you receive text with verifiably inaccurate encoding information.
[chardet.feedparser.org]
http://feedparser.org/docs/character-encoding.html
COmo é feito no XML
Mas ele tem UTF8 como default
http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info
HTTP defaults to ISO 8859-1 (Latin 1)
O que a RFC 3023 diz? HTTP Headers -> XML Dec. -> UTF-8
Windows-1252 (http://en.wikipedia.org/wiki/ISO_8859-1)
How browsers do?
\begin{enumerate}
\item The HTTP headers, where available, always take precedence over other information.
\item If the first 2-4 bytes are an XML Byte Order Mark (BOM), this is used.
\item If the document starts with an XML declaration <?xml .... ?>, this determines encoding by XML rules.
\item If the document contains the HTML hack <meta http-equiv="Content-Type" ...>, any charset declared here is used.
\end{enumerate}
Finally, As a last resort, detection.
A composite approach to language/encoding detection,
http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html
http://www.unicode.org/iuc/iuc19/program.html
\subsection{Solução encontrada}
KISS.
Tentaremos seguir a RFC 3023.
\section{Políticas de blah para robôs}
http://www.robotstxt.org/wc/meta-user.html
rel=``nofollow''
\section{Limitando o conteúdo baixado}
Apenas HTML
w3c - xhtml, seção 5.
RFC 3236
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/