Atitit.html解析器的选型?jsoup?nsoup?，java?c#?.net?版本_html/css_WEB-ITnose
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. 框架选型的要求
1.1. 文档多
1.2. 跨平台
2. html解析器特性：2.1. jQuery 风格的 CSS 选择器
· 对不信任的源的 HTML 进行清理
2.2. 操作 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解析器ＨＴＭＬ解析器的工作是解析ＨＴＭＬ标记到解析树。
5.0.1.1. HTML语法定义
ＨＴＭＬ的词汇与句法定义在w3c组织创建的规范中。当前版本是HTML4，HTML5的工作正在进行中。
5.0.1.2. 不是上下文无关语法
在对解析器的介绍中看到，语法可以用类似ＢＮＦ的格式规范地定义。不幸的是所有常规解析器的讨论都不适用于ＨＴＭＬ（我提及它们并不是为了娱乐，它们可以用于解析CSS和JavaScript）。HTML无法用解析器所需的上下文无关的语法来定义。过去HTML格式规范由DTD (Document Type Definition)来定义，但它不是一个上下文无关语法。
HTML与XML相当接近。XML有许多可用的解析器。HTML还有一个XML变种叫XHTML，那么它们主要区别在哪里呢？区别在于HTML应用更加”宽容”，它容许你漏掉一些开始或结束标签等。它整个是一个“软”句法，不像XML那样严格死板。 总的来说这一看似细微的差别造成了两个不同的世界。一方面这使得HTML很流行，因为它包容你的错误，使网页作者的生活变得轻松。另一方面，它使编写语法格式变得困难。所以综合来说，ＨＴＭＬ解析并不简单，现成的上下文相关解析器搞不定，ＸＭＬ解析器也不行。
5.0.1.3. 解析算法
如我们前面看到的，HTML无法使用自上而下或自下而上的解析器来解析。
理由如下：
1. 语言的宽容特点
2. 浏览器需要对无效HTML提供容错性的事实。
3. 解析过程的反复。通常解析过程中源码不会变化。但在HTML中，script标签包含”document.write”时可以添加内容，即解析过程实际上还会改变源码。
浏览器创建了自己的解析器来解析HTML文档。
HTML5规范里对解析算法有具体的说明，解析由两部分组成：分词与构建树。
分词属于词法分析部分，它把输入解析成符号序列。在HTML中符号就是开始标签，结束标签，属性名称和属生值。
分词器识别这些符号并将其送入树构建者，然后继续分析处理下一个符号，直到输入结束
5.0.1.4. 分词算法
算法的输出是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”。同样”