Rumah >hujung hadapan web >html tutorial >Atitit.html解析器的选型?jsoup?nsoup?,java?c#?.net?版本_html/css_WEB-ITnose
Atitit.html解析器的选型 jsoup nsoup ,java c# .net 版本
1. 框架选型的要求1
1.1. 文档多1
1.2. 跨平台1
2. html解析器特性:1
2.1. jQuery 风格的 CSS 选择器1
2.2. 操作 HTML 文档.1
3. 浏览器解析html的原理以及防止乱码2
4. 把meta标签放在head区域的最前面4
5. HTML解析器4
6. 参考8
6.1.1. atitit. java?jsoup?html table的读取解析 总结 -?attilax的专栏 ...8
1. 框架选型的要求
· 对不信任的源的 HTML 进行清理
· jQuery 风格的 CSS 选择器
NSoup.Nodes.Document doc = NSoup.NSoupClient.Parse(HtmlString);
?
NSoup.Nodes.Document doc = NSoup.NSoupClient.Connect("http://www.oschina.net/").Get();
?
ebClient webClient =?new WebClient();
String HtmlString=Encoding.GetEncoding("utf-8").GetString(webClient.DownloadData("http://www.oschina.net/"));
NSoup.Nodes.Document doc = NSoup.NSoupClient.Parse(HtmlString);
?
WebRequest webRequest=WebRequest.Create("http://www.oschina.net/");
NSoup.Nodes.Document doc = NSoup.NSoupClient.Parse(webRequest.GetResponse().GetResponseStream(),"utf-8");
作者:: 老哇的爪子 Attilax 艾龙, EMAIL:1466519819@qq.com
3. 浏览器解析html的原理以及防止乱码
细节
HTML文档是作为带有字符编码信息的字节流序列在互联网中传送的。字符编码信息可以在随文档发送的HTTP响应头信息中指定,也可以在文档的 HTML标签中指定。浏览器根据字符编码信息将字节流转换为显示在浏览器上的字符。如果不知道如何构造一个页面的字符,浏览器自然也不能正确地渲染页面。绝大部分浏览器在开始执行任何JavaScript代码或者绘制页面之前都要缓冲一定数量的字节流,缓冲的同时它们也要查找相关的字符编码设定(一个值得注意的例外是IE6/7/8)。
不同浏览器需要缓冲的字节流数量不同,另外如果找不到编码设定,各浏览器默认的编码也不同。但是不管哪一种浏览器,如果在已经缓冲了足够的字节流、开始渲染页面之后才发现指定的编码设定与其默认值不同,都会导致重新解析文档并重绘页面。如果编码的变化影响到了外部资源(例如css\js\media),浏览器甚至会重新对资源进行请求。
为了避免这些延迟,对任何超过1k(精确地说是1024字节,这是我们测试过的所有浏览器的最大缓冲限制)的HTML文档,要尽早指定字符编码。
建议
通过HTTP头信息或meta标签指定编码
为HTML文档指定编码设定有几种方式:
服务器端:通过web服务器的配置来指定编码参数,为所有text/html类型的文档指定带有正确编码信息的Content-Type头信息。例如Content-Type: text/html;charset=UTF-8
客户端:在HTML代码中包含http-equiv="content-type"的meta标签,并指定字符编码。例如 。
如果可能的话,为你的web服务器做指定字符编码的HTTP头信息配置。某些浏览器(例如Firefox)在执行JavaScript之前会用(比 其它浏览器)更短的延迟缓冲来检查头信息中是否指定字符编码。这意味着它们可以跳过对HTML标签的检查,缩短缓冲的字节数和延迟时间
4. 把meta标签放在head区域的最前面
如果你不能对web服务器配置进行修改,又需要通过meta标签指定编码,要确保你用于指定编码的meta标签是文档中head标签的第一个子元 素。浏览器会在文档的前1024字节中寻找字符编码参数,因此为了避免性能损耗,编码参数在文档头部越早出现越好(译注:在IE6以下的版本中,特定情况 下,如果该meta标签不是head的第一个子元素,则会被忽略
5. HTML解析器HTML解析器的工作是解析HTML标记到解析树。
HTML的词汇与句法定义在w3c组织创建的规范中。当前版本是HTML4,HTML5的工作正在进行中。
在对解析器的介绍中看到,语法可以用类似BNF的格式规范地定义。不幸的是所有常规解析器的讨论都不适用于HTML(我提及它们并不是为了娱乐,它们可以用于解析CSS和JavaScript)。HTML无法用解析器所需的上下文无关的语法来定义。过去HTML格式规范由DTD (Document Type Definition)来定义,但它不是一个上下文无关语法。
HTML与XML相当接近。XML有许多可用的解析器。HTML还有一个XML变种叫XHTML,那么它们主要区别在哪里呢?区别在于HTML应用更加”宽容”,它容许你漏掉一些开始或结束标签等。它整个是一个“软”句法,不像XML那样严格死板。 总的来说这一看似细微的差别造成了两个不同的世界。一方面这使得HTML很流行,因为它包容你的错误,使网页作者的生活变得轻松。另一方面,它使编写语法格式变得困难。所以综合来说,HTML解析并不简单,现成的上下文相关解析器搞不定,XML解析器也不行。
如我们前面看到的,HTML无法使用自上而下或自下而上的解析器来解析。
理由如下:
1. 语言的宽容特点
2. 浏览器需要对无效HTML提供容错性的事实。
3. 解析过程的反复。通常解析过程中源码不会变化。但在HTML中,script标签包含”document.write”时可以添加内容,即解析过程实际上还会改变源码。
浏览器创建了自己的解析器来解析HTML文档。
HTML5规范里对解析算法有具体的说明,解析由两部分组成:分词与构建树。
分词属于词法分析部分,它把输入解析成符号序列。在HTML中符号就是开始标签,结束标签,属性名称和属生值。
分词器识别这些符号并将其送入树构建者,然后继续分析处理下一个符号,直到输入结束
算法的输出是HTML符号。算法可以用状态机来描述。 每一个状态从输入流中消费一个或多个字符,并根据它们更新下一状态。决策受当前符号状态和树的构建状态影响。这意味着同样的字符可能会产生不同的结果,取决于当前的状态。算法太复杂,我们用一个例子来看看它的原理。
基础示例,分析下面的标签:
Hello world
初始状态是”Data state”,当遇到””。每个字符都被追加到新的符号名上。在我们的例子中,解出的符号就是”html”。
当碰到”>”时,当前符号完成,状态改回“Data state”。”
”标签将会以同样的方式处理。现在”html”与”body”标签都完成了,我们回到“Data state”状态。吃掉”H”(”Hello world”第一个字母)时会产生一个字符符号,直到碰到””的”现在我们回到“Tag open state”状态。吃掉下一个输入”/”时会产生一个”end tag token”并变更为“Tag name state”状态。同样,此状态保持到我们碰到”>”时。这时新标签符号完成,我们又回到“Data state”。同样”