权重域名

 　DIV+CSS时下最流行的或者说大部分做网页设计的人都采用的方式。说起来我干网页设计和网站制作也有六七年的时间了，当初DIV刚刚兴起的时候，曾和朋友们试过用DIV，但因为当时DIV+CSS这种技术还不成熟，所以也就没太在意，依然用TABLE，但，时至今日，DIV+CSS已把TABLE+CSS淘汰了，我
　　们这些常用TABLE的人，也得慢慢熟悉DIV了。
　　首先来说，DIV的好处在于样式与主体内容分离，大量减少网页代码量，使网页下载速度更快。而且对于后期网站维护来说，也是相当便捷的，这是DIV最大的优势。但个人认为，DIV也不一点缺点都没有，比如一个大型且架构复杂的网站来说，采用DIV布局对团队合作来说就是一个不小的折磨。因为全是DIV标签，如果不是本人做的，根本找不到需要的内容，当然可以添加注释，但这并不能完全解决这
　　个问题。
　　对于用习惯了TABLE的人来说，DIV确实很难适应，这就像学习武功，你本来学习的少林的功夫，如果再学武当的，兴许里面就有些冲撞，除非你忘了原来的基础，从头再来。DIV来说也是这样，对我来说对于用DIV控制盒子的各项属性就是一个不小的难题，兴好现在通过练习逐渐攻克了这个难关。
　　DIV+CSS任重而道远啊。

 　以前在岚海网络学习CSS+DIV的时候也是一头雾水，在一个小小的结构问题上可以花了大半天的功夫，现在接触得多了，其实发现当时只是卡在几个非常细节的问题上：
　　第一种情况：火狐下是正常的，IE6下间距错乱，这种情况，通常应该检查边距MARGIN，可以试着到边距MARGIN换成填充PADDING，这样通常都可以解决问题，也就是说，我们尽量多的在需要使用边距MARGIN的用填充PADDING去代替。
　　第二种情况：FLOAT造成的页面错乱，FLOAT是CSS当中最常用到的一个代码，当一个大框架当中有好几个小框架FLOAT的时候会倒致大框架失去它的高度，这个时候我们就应该在所以小框架的最后面，加上一个clear:both来清除浮动。
　　关于网站建设的几点经验：
　　1、素材的收集，平时多浏览一些做得好的欧美网站，现在很多人都喜欢去考参一些韩国的酷站，个人觉得欧美网站的用户体验远远好于韩国酷站，也更符合国情。见到好的素材及时收集起来。网页设计是经验的积累，同时也是素材的一个积累。
　　2、颜色的处理，对颜色有了一定的理解之后，用不超过三种的主色调加浅的过渡色彩(比如很淡的灰色)。这样的网站，不一定美观，但一定不难看。
　　3、留白的处理，初学者和有经验的设计师最基本的区别就是间距的处理，好的用户体验网站，就是一个对留白处理得非常好的例子。
　　4、网页的统一性，色彩和框架的统一，大的方面来说，就是整个网站的标题，描述文字、边框颜色，背景，框架的形状。小的细节方面就是一个图标的颜色，一个需要强调的符号都有效果的统一起来。
　　5、在脑海里画效果图，这是一种设计思维，当你可以在效果图上把首页，或者是大致的元素都确定之后，就可以尝试基脑海中想象中其它页面的效果图的样子。这样便可以节省大量的去把你脑海中的东西画出来的时间。

一旦我们知道了用户是谁，就可以确定他们是否有权限访问请求的资源。这一过程的实现方式很多，根据资源决定。在基于windows的系统中，大多数资源都有一个访问控制列表（ACL），其中列出了可以访问某一资源的用户。这种列表通常指定了每个用户所拥有的访问类型，即他们是否能够阅读它、写入它、修改它或者删除它等等。

例如，如果用户请求一个ASP页，操作系统将确认他对此页面是否具有read访问权限。如果有，将允许IIS读取该页。然而，IIS也带有授权设置，用来控制用户获取某一资源的权限。假设是一个ASP页面，如果IIS为该页设置了Script Execute（脚本执行）许可，那么用户就可以在该页执行脚本。

当用户通过web请求资源时，IIS接受请求并执行用户的初始验证工作。在判断用户是否被允许访问资源之前，IIS也执行其他的检查工作。

1、IP地址和域名限制。在windows2003 server和windows NT4中，可以规定客户机的IP地址和域名，此客户机会被允许访问或拒绝访问。可以通过IP address和domain name restrictions对话框完成，这些对话框位于站点或目录的properties对话框的directory security页。如果经常从单独机器上访问受限制的站点，或者如果所有的用户都来自于一组特定的IP地址或域，则这些对话框就很有用。

今天小编带大家一起来了解一下应用程序的授权许可。
1、在windows中授权。假如用户已经被成功地验证身份，如果所验证的账户拥有对该资源的正确的许可，则用户就可以访问他们所请求的资源。这种许可保留在每一个资源的ACL中。Windows采用一系列方法管理这些ACL。比如windows explorer用于在局域和网络驱动器上管理文件和文件夹的ACL。在windows explorer中打开任何文件或文件夹的properties对话框，选择security页，就可以显示已经访问了文件或文件夹的账户和组，以及它们的许可。Advanced按钮更详细地控制选项。

Windows验证提供最安全的方法，可以控制访问和保障ASP.NET应用程序的安全。但是，如果希望为几个应用程序建立登录的策略，则这种验证方法就无法使用，因为这些应用程序分布在不同服务器和站点中，尤其是在不同地理位置的站点。唯一的解决方案是在所有服务器上建立相同的账户，可行的方法是使用active directory建立windows“森林（forest）”，这样所有的服务器称为相同企业的一部分——即使这些服务器分布于不同域中也是如此。

但是，如果希望启用在多个站点间使用相同的证书用户的系统，这也可能失败。例如，可能希望构建解决方案，其中用户可以登录到一家著名的站点，比如hotmail.com，然后可以到达自己的站点，当证书记录在hotmail时，根据所提供的登录证书自动完成验证。

验证了用户之后，系统至少会知道一些用户的信息。至少会知道用户名称（身份）和所执行的验证类型。在windows验证的情况下，它也知道用户是哪一个成员的角色（即哪一个windows账户组）。

网站建设中我们可以在代码中访问此信息，并使用它处理应用程序的行为。例如，我们可以显示不同页或改变页的内容，这取决于特定的用户，或取决于他们所属于的组。这是一项非常有用的功能，因为唯一的替代方法是提供页内容，为此要创建页的多个副本，并建立正确的用户对每一页的访问许可。即使这样，用户可以知道他们应该访问哪一页的唯一方法也只是实验所有的页，这可不是方便用户的方法。

所有ASP.NET页和资源会默认地在局域系统进程账户之下运行——这些账户带有SYSTEM的绰号。此账户通常具有机器上的所有资源的完全权限，因此ASP.NET可以正常运行，而没有许可设置带来的问题。当然，我们可以修改此账户的许可，为此可以控制ASP.NET访问资源的方式。其他许多进程也可以使用SYSTEM账户，改变其许可可以导致其他应用程序无法运行。

相反，在此还有另一个绰号值可以使用，即MACHINE，其密码是AutoGenerate。当账户称为ASPNET时，就可以运行ASP.NET。此账户广泛地等同于普通的ASP账户（即它不拥有特权），但是ASP.NET为此账户设置了一些ACL，以帮助非常规地使用它。至少，ASP.NET需要读取它自己的二进制文件，配置文件（例如，安装root和安装root/config文件夹）的许可，并可以完全控制ASP.NET temporary file文件夹，安装进程可以自动设置这些。此选项可以在公共服务器上提供简单有效的方法，以强化安全。

元素提供账户细节，仅当为启用模仿设置时使用这些细节。打开模仿设置意味着ASP.NET会运行在账户环境之下，当接收请求时由IIS验证此账户。如果配置IIS来允许匿名访问（站点的默认设置），那么其环境是IUSR账户的环境（或者是所规定的账户，如果改变它，IIS就为匿名访问使用此账户）。简单地在machine.config或web.config文件的<system.web>部分添加<identity impersonate=”true”>元素，意味着会在IIS匿名账户（IUSR_machinename）之下发生匿名访问。另一种可能情况是使用<identity>元素的userName和password以规定账户，我们希望ASP.NET资源运行在此账户之下。

.NET Framework的原则是一旦创建了一个枚举对象，会在原处及时得到包含在可枚举对象的项目的快照。如果初始对象发生了改变，枚举就会无效，下次调用枚举对象的任何一种方法时枚举对象会抛出InvalidOperationException。所有的.NET Framework类都遵循这些原则，用户所写的枚举类型同样如此。然而，由于性能方面的原因，在创建可枚举对象时，架构中的枚举对象实际上并没有复制所有的项目。它们只是把引用保存回到可枚举对象中，并提供了一个逻辑快照。把一个引用和一个索引保存到初始枚举对象中比复制每个项目要廉价得多，对一个巨大的集合来说，复制项目是个非常昂贵的过程。