阿特拉斯，希腊神话中的巨神，以肩膀扛顶着天。后代，也引伸有能担负重责大任的人，有人也因之称他为宇宙神。

VeriSign通过它的一个崭新的技术平台—高级交易查询信令系统(ATLAS)来提供服务,ATLAS是一个综合性的处理平台，其设计宗旨是扩展 其Internet的核心基础设施、域名系统(DNS)，支持迅速发展中的通过Internet提供的语音、数据和多媒体服务。通过Solaris 10 OS和Sun Fire x64服务器的采用，ATLAS每天管理着数以百亿计的处理业务，且提供高于99.999％的数据完整性和服务，阻止如“拒绝服务”等来自 Internet的恶意攻击。

ATLAS 是欧洲核子中心(cern)大型强子对撞机(LHC)上的四个大型探测器之一.

微软目前目前对于通过Ajax风格的编程在浏览器中实现日益流行的富客户端应用比较感兴趣。今后的IE中将拥有Ajax的所有东西——DHTML、JScript和XmlHttp。实际上Outlook Web Acces从1998年开始就已经提供了这种伟大的浏览体验了。在ASP.NET 2.0中，微软使用异步回调及舒适的Ajax风格的应用程序的编写更加简单，并且，微软为此提供了内建的控件。

最近，几乎所有的浏览器都提供了Ajax所需的技术，使用这种模式的富客户端应用程序也不断出现。今天，世界上出现了不计其数的Ajax风格的站点，包括 Google的很多站点、A9和Flickr。微软的很多站点也使用了这项技术，如Start.com和MSN虚拟地球。

Ajax的风行说明用户对于丰富的Web体验的需求日益增长。然而，开发和调试Ajax风格的Web应用程序是一项非常艰难的工作。要编写一个丰富的 Web UI，开发者需要详细地掌握DHTML和JavaScript，并且还要掌握各种浏览器之间在设计细节上的不同。然而没有那些工具能够简化这些应用程序的 设计和开发。最后，调试和测试这些应用程序会变得异常困难。

微软致力于简化Ajax风格Web应用的开发，并提供丰富的、可交互的和个性化的用户体验。开发者可以对客户端脚本不甚了解;但他们可以很容易地开发和调试这种应用程序。

出于这一目的，微软启动了一个新的项目，研发代号“Atlas”。Atlas为开发这带来了如下特性：

Atlas客户端脚本框架
Atlas的ASP.NET服务器控件
ASP.NET Web Services集成
Atlas的ASP.NET构建块
客户端构建块服务
你可能会问的一个问题是，Atlas如何在Avalon和智能客户端上使用?

我们可以看到，Atlas是编写丰富的、可交互的和个性化的Web浏览器应用程序的最好方式。而Avalon是微软的下一代表现层模型，可以在 Windows平台上提供最丰富的用户体验。Avalon将使用最新的媒体集成功能和硬件加速设备，提供卓越的视觉体验。Avalon将带来超越浏览器的 体验。

当然，当你构建Avalon应用程序的时候，你依然可以重用ASP.NET和Atlas中的编程模型。例如，Avalon客户端上依然可以使用ASP.NET构建块服务和客户端构建块服务。这种模型可以使你平滑地过渡到下一代应用程序上。

Atlas:客户端脚本框架

Atlas客户端脚本框架是可扩展的，100%面向对象的JavaScript客户端脚本框架，允许开发这很容易地构建拥有丰富的UI工能并且可以连接 Web Services的Ajax风格浏览器应用程序。使用Atlas，开发者可以使用DHTML、JavaScript和XMLHTTP来编写Web应用程 序，而无须掌握这些技术的细节。

Atlas客户端脚本框架可以在所有的现代浏览器上运行，而不需要Web服务器。它还完全不需要安装，只要在页面中引用正确的脚本文件即可。

Atlas客户端脚本框架包含下列组件：

一个可扩展的和新框架，其中为JavaScript添加了很多新特性，如生存期管理、集成、多播事件处理器和接口
一个基础类库，提供了通用特性，如丰富的字符串操作功能、计时器和运行任务等
一个UI框架，可以跨浏览器实现动态行为
一个网络栈，用于简化对服务器的连接和对Web Services的访问
Atlas:ASP.NET服务器控件

微软为ASP.NET应用程序专门设计了一组Ajax风格的服务器控件，并且加强了现有的ASP.NET页面框架和控件，以便支持Atlas客户端脚本框架。

ASP.NET 2.0中有一项称作异步客户端回调的新特性，使得构建无中断的页面变得很容易。异步客户端回调包装了XMLHTTP，能够在很多浏览器上工作。 ASP.NET本身包括了很多使用回调的控件，包括具有客户端分页和排序功能的GridView和DetalsView控件，以及TreeView空间的 虚拟列表支持。

Atlas客户端脚本框架将完全支持ASP.NET 2.0回调，但微软希望进一步增强浏览器和服务器之间的集成性。例如，你可以将Atlas客户端控件的数据绑定指定为服务器上的ASP.NET数据源控件，并且可以从客户端异步地控制Web页面的个性化特征。

Atlas:ASP.NET Web Services集成

和任何客户端应用程序一样，一个Ajax风格的Web应用程序通常也需要访问Web服务器的一些功能。Atlas应用程序连接服务器的模型和其他平台类似，都是使用Web Services来实现。

通过ASP.NET Web Services集成，Atlas应用程序将可以在任何支持XMLHTTP的浏览器上通过Atlas客户端将本框架来直接访问任何宿主于ASP.NET的 asmx或Indigo服务。该框架将会自动处理代理和脚本到对象、对象到脚本的序列化问题。通过使用Web Services集成，开发者可以使用单一的编程模型来编写Web Services，并且在任何应用程序中使用它们，不论是基于浏览器的站点上还是智能客户端应用程序中。

Atlas:ASP.NET构建块服务

在ASP.NET 2.0中，微软构建了一组丰富的构建块服务(Building Block Services)，这使得构建强大、个性化的Web应用程序变得不可思议的简单。这些构建块极大地降低了在开发通用的Web应用程序过程中需要编写的代 码数量，比如管理用户、通过角色验证用户和存储用户的个性化设置信息等。

使用Atlas，我们可以在任何浏览器上的任何客户端应用程序中向访问Web Services那样访问这些功能。例如，如果你正在开发一个站点，来显示用户的TO-DO项目，你可以使用ASP.NET的Profile服务来将他们 存放在服务器上的用户自定义配置文件中。这样即使用户从一台机器上转移到另一台机器上，也同样可以访问这些项目。

微软将提供的服务包括(全部是基于ASP.NET 2.0的)：

– Profile：在服务器上存放每个用户特有的数据

– UI个性化：在服务器上存放个性化的UI设置信息

– 验证：验证用户

– 角色：基于用户的角色验证用户任务和提供不同的UI

由于这些构建块是服务器端的，开发者需要对他们应用和其他站点一样的安全模型。这些服务不需要客户端下在任何东西——只要在浏览器中引用脚本代理即可。

所有的ASP.NET 2.0构建块服务都是可插拔的，这使用一种通用的提供者模型可扩展模式在后台实现。微软提供的内建提供程序允许开发这使用SQL Server数据库或Active Directory作为存储容器，开发者也可以很容易地插接自己的提供程序。例如，你可能希望使用集群而不是数据库服务器来存放用户的配置文件，这时你只 需将你的提供程序插接近来即可。

Atlas:客户端构建块服务

除了DHTML、JScript和XMLHTTP，微软还提供了一组附加的服务来加强客户端的功能并提供增强的体验。

对于这样的服务，本地浏览器缓存就是一个很好的例子。当启用了本地浏览器缓存时，Web站点就可以将内容存储到患从中，并在需要的时候很快地取出。但浏览器并未提供向缓存中存放数据的API，而且象Google Map或OWA这样的应用程序不得不通过很多工作产生一个唯一的URL才能使浏览器缓存它。在Atlas中，微软提供了可编程的本地存储/缓存，因此应用程序可以很方便、有效并且安全在本地缓存数据。

同其他应用程序的集成是检验Web体验是否丰富的另一个新的标准。例如，当一个用户浏览一个拍卖网站并对一件商品出价时，他可能想随时知道这个拍卖什么时 候结束，但他如何才能将这个事件添加到他们个人的日历程序中?Atlas带来了一系列客户端构建块服务，当用于选择“添加到日历”时，浏览器将调用接驳点 来获取日历数据，并将其传递到本地的日历程序中。此时页面上无须下载或运行任何特殊的代码或执行任何初始化动作，因此，这比ActiveX要安全得多。

对SESSION的争论好象一直没有停止过，不过幺麽能理解SESSION的人应该占90以上。
但还是讲讲，别嫌老~

有一些人赞成用SESSION，有一些人不赞成。但这个问题到底要怎么说。不妨听听我的看法

如果有错误请不要朝丢东西，金条和硬币除外。

有些人应该知道我是做江湖程序的，而江湖程序做看中的就是效率，但这里不谈设计，而

从一些比较实际的角度看SESSION。

首先要先说SESSION是干什么的，SESSION是可以存储针对与某一个用户的IE以及通过其当

前窗口打开的任何窗口具有针对性的用户信息存储机制。为什么要这样说。看下边

先研究SESSION是如何启动的，当打开IE以后浏览网站后会发出一个指令请求SESSIONID以

及对各个类型数据的下载许可，如图片，声音以及FLASH。
数据实际传输内容：IE到服务器
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language0: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: www.jh521.com
Connection: Keep-Alive
服务器会返回一个没有被使用的SESSIONID让IE使用，当时IE就对返回SESSIONID做存储

并同时返回相关页面的下载数据，如下:服务器到IE
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sun, 30 Nov 2003 16:41:51 GMT
Content-Length: 21174..Content-Type: text/html
Set-Cookie: ASPSESSIONIDCACBBBRT=IBOMFONAOJFEEBHBPIENJFFC; path=/
Cache-control: private
然后就是页面HTML代码

此时这个IE程序(不是客户机)的SESSIONID就为IBOMFONAOJFEEBHBPIENJFFC

而当IE在访问任何这个站点的ASP程序的时候，就会把IBOMFONAOJFEEBHBPIENJFFC发送

给服务器，服务器就会知道IBOMFONAOJFEEBHBPIENJFFC是表示你
而在服务器上设置SESSION("name")="name"
完全可以看成是
SESSION("IBOMFONAOJFEEBHBPIENJFFC")("name")="name"
或者
SESSION(SESSIONID)("name")="name"
这样，SESSION就区分开用户了。
而当服务器反馈这个ID的时候会看这个ID有没有被使用。如果有在换一个
反正不会让你重复，如果想模拟某人的SESSION的ID来进行欺骗是可以的。不过要获取到

对方IE传输信号，并且在保证当时这个SESSIONID没有被取消的情况下才可能实施。

不过要是我有那时间直接通过POST信号找他NAME和PASS了。我可不费这个劲

想必一些人明白了了SESSIONID到底是如何工作的

那么就在看看COOKIE,有人说SESSIONID就是COOKIE，按照技术上来讲他们不属于同类

但是属于一种工作模式，用户和服务器传输私有数据

当我设置COOKIE的时候，服务器会反馈给IE一个指令。IE通过这个网络指令生成COOKIE并

存放,在特定的时候会取得这个这个信息如在访问这个站点并且COOKID有效的时候。

那么为什么要用COOKIE而不用SESSION呢
看下区别

有效时间以及存储方式 传输内容
COOKIE 可设置并在本地保留 明码信息

SESSION 在IE不关闭并服务器不超时 只有SESSIONID

当如果想让用户下次登入网站不需要输入用户名或者密码的时候就只能用COOKIE,

因为他可以保留相当长的时间(在COOKIE记录被删除或者失效日期之前)

而SESSION就不可以，他不会保留太长时间，而且IE在关闭后就自动清除了SESSIONID记录

在下次登入的时候会请求新的SESSIONID

而服务器想通过用户个人变量校验用户的状态的时候，就不能用COOKIE

如果用设置用户权限是USER。而IE访问的时候就把USER的明码传输到服务器。

那么如果我通过一定手段，比如直接修改COOKIE记录，把USER修改成ADMIN呢~~

就麻烦了。

但存储用户名和密码或者网站的配色方案这样的信息，用COOKIE是最好的

好，有点累了，在说说这个东西
Request.ServerVariables("HTTP_REFERER")

我想有一些人通过这个Request.ServerVariables("HTTP_REFERER")
来进行一些关键性限制,特别是对付远程提交以及非法侵入。
那么我就要提醒下服务器取得的HTTP_REFERER信息完全是IE传输给服务器的，可以模拟
而且难度不大，用不到半个小时就可以用VB做出一个针对HTTP_REFERER入侵程序。
（可惜我原先那他没干正经事情，做WEB游戏挂机程序来的)

顺便把我找到的一个关于SESSION的资料也弄过来吧 COOKIE的我前面发过了

一个人在网站上一次活动的过程。

当一个访问者来到你的网站的时候一个Session就开始了，当他离开的时候Session就结束了。本质是来说，cookie是和浏览器有关系，而 Session变量就可以存一些资源变量在服务器上面。PHP4用文件存储Session变量，但理论上可以用数据库或共享内存来做这件事。

所有的页面都用PHP4的Session必须用Session_start()功能函数来告诉PHP4引擎来取有关的Session到内存中

。函数Session_start()可以在cookie域里或请求的参数中取得Session_id为了响应http请求。如果不能找到

SessionID就新建一个Session。

什么是Session变量？

Session变量是个有规律的全局变量，当一个Session变量被注册，用PHP4可以在所有的页面上得到Session

的值。用Session_register("variable_name")可以注册一个Session变量。在所有并发的的用Session就使用

Session_start()函数，变量的值将作为一个Session变量注册为Session。

我们能作什么？

通常有很多的方法来管理Session和Session变量，我将给你个例子。说你将建一个商业站点，象我这样的，

你可能想保持已经被承认的用户当前的名字，或有多少的新消息用户已经得到。为了不在从数据库里读取，你

有两个方法可以做：

1.1.你可以用三个cookie

。authenticated_user – 当前的用户名称

。num_messages – 他得到的信息的数量

。expire_time – 何时重新读取信息数量

2.2.用sessions和新建三个session变量

第一个方法安全性不好，一些人可以得到cookie进入他人的领域。

用sessions用户仅得到一个cookie，安全的多。

缺点

session给了你自由，过度的用session会影响脚本语言的使用。虽然PHP4的session有些限制，如你不能存对象在session里。

long getCreationTime()                         取得session产生的时间，单位是毫秒
       String getId()                                  取得session 的ID
       long getLastAccessedTime()                      取得用户最后通过这个session送出请求的时间
       long getMaxInactiveInterval()                    取得最大session不活动的时间，若超过这时间，session 将会失效
       void invalidate()                                取消session 对象，并将对象存放的内容完全抛弃
       boolean isNew()                                  判断session 是否为"新"的
       void setMaxInactiveInterval(int interval)        设定最大session不活动的时间，若超过这时间，session 将会失效

Cookies，有些人喜欢它们，有些人憎恨它们。但是，很少有人真正知道如何使用它们。现在你可以成为少数人中的成员－可以自傲的Cookie 大师。–>

如果你象作者一样记性不好，那么你可能根本记不住人们的名字。我遇到人时，多半只是点点头，问句“吃了嘛！”，而且期望问候到此为止。如果还需要表示些什 么，那么我就得求助于一些狡猾的技巧，好让我能想对方是谁。比如胡扯起一些和对方有关的人，不管他们之间关系多远，只要能避免不记得对方名字的尴尬就好： “你隔壁邻居的侄子的可爱小狗迈菲斯特怎么样？”通过这个方法，我希望能让对方感到，我确实很重视他（她），甚至还记得这些琐事，虽然实际上连名字都忘记 了。但是，不是我不重视，而是我的记忆力实在是糟糕，而且要记住的名字又实在太多。如果我能给每个人设置cookies，那么我就不会再犯这种记忆力问题 了。

在这篇文章里，我们要学习：

1. 什么是 Cookies?
2. Cookie 的构成
3. 操纵 Cookies
4. Cookie 怪兽

什么是Cookies?

你会问，什么是cookies呢? cookie 是浏览器保存在用户计算机上的少量数据。它与特定的WEB页或WEB站点关联起来，自动地在WEB浏览器和WEB服务器之间传递。

比如，如果你运行的是Windows操作系统，使用Internet Explorer上网，那么你会发现在你的“Windows”目录下面有一个子目录，叫做“Temporary Internet Files”。如果你有空看看这个目录，就会发现里面有一些文件，文件名称看起来就象电子邮件地址。比如在我机器上的这个目录里，就有 “jim@support.microsoft.com”这样的文件。这是一个cookie 文件，这个文件从哪来呢？猜一猜，它来自微软的支持站点。顺便说一句，这不是我的电子邮件地址，特此澄清。

对于管理细小的、不重要的、不想保存在中央数据库里的细节信息，Cookies 是个很不错的方案。（这不是说大家的名字不重要。）比如，目前网站上不断增长的自定义服务，可以为每个用户定制他们要看的内容。如果你设计的就是这样一个 站点，那么你怎么来管理这样的信息：一个用户喜欢绿色的菜单条，而另一个喜欢红色的。确实是个累人的问题。不过，这样的信息，可以很安全地记录到 cookie，并保存在用户的计算机上，而你自己的数据库空间可以留给更长久更有意义的数据。

FYI: Cookies 对于安全用途，通常很有用。我不想在此就这一问题过于深入，只是提供一个示例，可以看到如何使用在一段时间之后过期的cookies来保证站点安全：

1. 使用用户名和口令，通过 SSL 登录。
2. 在服务器的数据库里检查用户名和口令。如果登录成功，建立一个当前时间标签的消息摘要 (比如 MD5) ，并把它保存在cookie和服务器数据库里。把用户的登录时间保存在服务器数据库里面的用户记录里。
3. 在进行每个安全事务时（用户处于登录状态的任何事务），把cookie的消息摘要和保存在服务器数据库里的摘要进行比较，如果比较失败，就把用户引导到登录界面。
4. 如果第3步检查通过，那么检查当前时间和登录时间之音经过的时间是否超过允许的时间长度。如果用户已经超时，那么就把用户引到登录界面。
5. 如果第3步和第4步都通过了，那么把登录时间重新设置成当前时间，允许事务发生。那些需要你登录的安全站点，可能多数使用的都是和这里介绍的类似的方法。
Cookie的构成

Cookies最初设计时，是为了CGI编程。但是，我们也可以使用Javascript脚本来操纵cookies。在本文里，我们将演示如何使用 Javascript脚本来操纵cookies。(如果有需求，我可能会在以后的文章里介绍如何使用Perl进行cookie管理。但是如果实在等不得， 那么我现在就教你一手：仔细看看CGI.pm。在这个CGI包里有一个cookie()函数，可以用它建立cookie。但是，还是让我们先来介绍 cookies的本质。

在Javascript脚本里，一个cookie 实际就是一个字符串属性。当你读取cookie的值时，就得到一个字符串，里面当前WEB页使用的所有cookies的名称和值。每个cookie除了 name名称和value值这两个属性以外，还有四个属性。这些属性是： expires过期时间、 path路径、 domain域、以及 secure安全。

Expires – 过期时间。指定cookie的生命期。具体是值是过期日期。如果想让cookie的存在期限超过当前浏览器会话时间，就必须使用这个属性。当过了到期日期时，浏览器就可以删除cookie文件，没有任何影响。

Path – 路径。指定与cookie关联的WEB页。值可以是一个目录，或者是一个路径。如果http: //www.zdnet.com/devhead/index.html 建立了一个cookie，那么在http://www.zdnet.com/devhead/目录里的所有页面，以及该目录下面任何子目录里的页面都可以 访问这个cookie。这就是说，在http://www.zdnet.com/devhead/stories/articles 里的任何页面都可以访问http://www.zdnet.com/devhead/index.html建立的cookie。但是，如果http: //www.zdnet.com/zdnn/ 需要访问http://www.zdnet.com/devhead/index.html设置的cookes，该怎么办？这时，我们要把cookies 的path属性设置成“/”。在指定路径的时候，凡是来自同一服务器，URL里有相同路径的所有WEB页面都可以共享cookies。现在看另一个例子： 如果想让 http://www.zdnet.com/devhead/filters/ 和http://www.zdnet.com/devhead/stories/共享cookies，就要把path设成“/devhead”。

Domain – 域。指定关联的WEB服务器或域。值是域名，比如zdnet.com。这是对path路径属性的一个延伸。如果我们想让 catalog.mycompany.com 能够访问shoppingcart.mycompany.com设置的cookies，该怎么办? 我们可以把domain属性设置成“mycompany.com”，并把path属性设置成“/”。FYI：不能把cookies域属性设置成与设置它的 服务器的所在域不同的值。

Secure – 安全。指定cookie的值通过网络如何在用户和WEB服务器之间传递。这个属性的值或者是“secure”，或者为空。缺省情况下，该属性为空，也就是 使用不安全的HTTP连接传递数据。如果一个 cookie 标记为secure，那么，它与WEB服务器之间就通过HTTPS或者其它安全协议传递数据。不过，设置了secure属性不代表其他人不能看到你机器本 地保存的cookie。换句话说，把cookie设置为secure，只保证cookie与WEB服务器之间的数据传输过程加密，而保存在本地的 cookie文件并不加密。如果想让本地cookie也加密，得自己加密数据。

操纵Cookies

请记住，cookie就是文档的一个字符串属性。要保存cookie，只要建立一个字符串，格式是name=<value>（名称＝值），然 后把文档的 document.cookie 设置成与它相等即可。比如，假设想保存表单接收到的用户名，那么代码看起来就象这样：

document.cookie = "username" + escape(form.username.value);

在这里，使用 escape() 函数非常重要，因为cookie值里可能包含分号、逗号或者空格。这就是说，在读取cookie值时，必须使用对应的unescape()函数给值解码。

我们当然还得介绍cookie的四个属性。这些属性用下面的格式加到字符串值后面：

name=<value>[; expires=<date>][; domain=<domain>][; path=<path>][; secure]

名称=<值>[; expires=<日期>][; domain=<域>][; path=<路径>][; 安全]

<value>, <date>, <domain> 和 <path> 应当用对应的值替换。<date> 应当使用GMT格式，可以使用Javascript脚本语言的日期类Date的.toGMTString() 方法得到这一GMT格式的日期值。方括号代表这项是可选的。比如在 [; secure]两边的方括号代表要想把cookie设置成安全的，就需要把"; secure" 加到cookie字符串值的后面。如果"; secure" 没有加到cookie字符串后面，那么这个cookie就是不安全的。不要把尖括号<> 和方括号[] 加到cookie里（除非它们是某些值的内容）。设置属性时，不限属性，可以用任何顺序设置。

下面是一个例子，在这个例子里，cookie "username" 被设置成在15分钟之后过期，可以被服务器上的所有目录访问，可以被"mydomain.com"域里的所有服务器访问，安全状态为安全。

// Date() 的构造器设置以毫秒为单位
// .getTime() 方法返回时间，单位为毫秒
// 所以要设置15分钟到期，要用60000毫秒乘15分钟
var expiration = new Date((new Date()).getTime() + 15 * 60000);
document.cookie = "username=" + escape(form.username.value)+ "; expires ="
+ expiration.toGMTString() + "; path=" + "/" + "; _
domain=" + "mydomain.com" + "; secure";

读取cookies值有点象个小把戏，因为你一次就得到了属于当前文档的所有cookies。

// 下面这个语句读取了属于当前文档的所有cookies
var allcookies = document.cookie;

现在，我们得解析allcookies变量里的不同cookies，找到感兴趣的指定cookie。这个工作很简单，因为我们可以利用Javascript语言提供的扩展字符串支持。

如果我们对前面分配的cookie "username" 感兴趣，可以用下面的脚本来读取它的值。

// 我们定义一个函数，用来读取特定的cookie值。
function getCookie(cookie_name)
{
var allcookies = document.cookie;
var cookie_pos = allcookies.indexOf(cookie_name);

// 如果找到了索引，就代表cookie存在，
// 反之，就说明不存在。
if (cookie_pos != -1)
{
// 把cookie_pos放在值的开始，只要给值加1即可。
cookie_pos += cookie_name.length + 1;
var cookie_end = allcookies.indexOf(";", cookie_pos);

if (cookie_end == -1)
{
cookie_end = allcookies.length;
}

var value = unescape(allcookies.substring(cookie_pos, cookie_end));
}

return value;
}

// 调用函数
var cookie_val = getCookie("username");

上面例程里的 cookie_val 变量可以用来生成动态内容，或者发送给服务器端CGI脚本进行处理。现在你知道了使用Javascript脚本操纵cookies的基本方法。但是，如果 你跟我一样，那么我们要做的第一件事，就是建立一些接口函数，把cookies处理上的麻烦隐藏起来。不过，在你开始编程之前，稍候片刻。这些工作，早就 有人替你做好了。你要做的，只是到哪去找这些接口函数而已。

比如，在David Flangan的Javascript: The Definitive Guide 3rd Ed.这本书里，可以找到很好的cookie应用类。你也可以在Oreilly的WEB站点上找到这本书里的例子。本文最后的链接列表里，有一些访问这些 cookie示例的直接链接。

Cookies 怪兽

因为某些原因Cookies 的名声很不好。许多人利用cookies做一些卑鄙的事情，比如流量分析、点击跟踪。Cookies 也不是非常安全，特别是没有secure属性的cookies。不过，即使你用了安全的cookies，如果你和别人共用计算机，比如在网吧，那么别人就 可以窥探计算机硬盘上未加密保存的cookie文件，也就有可能窃取你的敏感信息。所以，如果你是一个WEB开发人员，那么你要认真考虑这些问题。不要滥 用cookies。不要把用户可能认为是敏感的数据保存在cookies里。如果把用户的社会保险号、信用卡号等保存在cookie里，等于把这些敏感信 息放在窗户纸下，无异于把用户投到极大危险之中。一个好的原则是，如果你不想陌生人了解你的这些信息，那就不要把它们保存在cookies里。

另外，cookies还有一些实际的限制。Cookies保留在计算机上，不跟着用户走。如果用户想换计算机，那么新计算机无法得到原来的cookie。 甚至用户在同一台计算机上使用不同浏览器，也得不到原来的cookie：Netscape 不能读取Internet Explorer 的cookies。

还有，用户也不愿意接受cookies。所以不要以为所有的浏览器都能接受你发出的cookies。如果浏览器不接受cookies，你要保证自己的WEB站点不致因此而崩溃或中断。

另外WEB 浏览器能保留的cookies不一定能超过300个。也没有标准规定浏览器什么时候、怎么样作废cookies。所以达到限制时，浏览器能够有效地随机删 除cookies。浏览器保留的来自一个WEB服务器上的cookies，不超过20个，每个cookie的数据（包括名称和值），不超过4K字节。(不 过，本文里的cookie尺寸没问题，它只占了12 K字节，保存在3个3 cookies里。)

简而言之，注意保持cookie简单。不要依赖cookies的存在，不要在每个cookie里保存太多信息。不要保存太多的cookes。但是，抛除这些限制，在技巧高超的WEB管理员手里，cookie的概念是一个有用的工具。

外部链接
每个 Javascript 程序员都应当有一份Javascript： David Flanagan 的The Definitive Guide。 这本书里找到cookie 类例程可以帮助你把不止一个变量编码到单一的cookie，克服掉“每个WEB服务器20 个cookies的限制”。

看来基本上得到大家的认可，关于分歧的部分和没有讲到的部分我们在深入探讨，

CSS的并发连接和服务器负载问题处理，也应该是web标准认识关心的。

到底SEO，IA，交互设计，用户体验算不算是Web标准的范畴，我明确一点

“用正确的方法去做正确的网页”

正确的网页是什么
1。优秀的信息架构
2。良好的交互设计

1和2最终达到了良好的用户体验

正确的方法是什么
1。标准的语言规范，XHTML，CSS，ECMAScript （标准的Javascript），DOM，XML，XMLHTTPRequest，甚至XSL等W3C的标准化规范语言
2。浏览器设备的支持情况的权衡以及解决方法
3。海量用户访问是的服务器负载

最终用户得到了良好的用户体验，搜索引擎得到了你想Open的数据，结果很完美！！

关于web标准，我建议大家不要停留在老外们的思维角度，要去消化他而不是模仿他，要站在巨人的肩膀上看得更远，不管什么技术，什么口号，什么方法，我的目的只有一个——我们要做到网页的最优化

C/S 与 B/S 区别

        Client/Server是建立在局域网的基础上的.Browser/Server是建立在广域网的基础上的.
１．硬件环境不同:
C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务.
B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备. 信息自己管理. 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行
２．对安全要求不同
C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息.
B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群.
３．对程序架构不同
C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.
B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.
４．软件重用不同
C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.
B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子
５．系统维护不同
系统维护是软件生存周期中,开销大, ——-重要
C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.
６．处理问题不同
C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统
B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小.
７．用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.
８．信息流不同
C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低
B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心