https://www.cnblogs.com/chyong168/archive/2012/04/24/2467505.html
在Internet Explorer 5中，Microsoft提供了名为userData的客户端持久存储功能。它是通过对CSS行为进行特殊扩展来实现的。这些扩展完全都是非标准的，是 90年代后期浏览器大战遗留下来的产物。由于它概念模糊、使用困难，并且只能用于Internet Explorer，所以很少有Web开发人员会使用这种存储方式，大多数的开发人员甚至完全不知道存在这种技术。
IE的userData能够存储完整的XML文档，并且会将复杂的数据类型转换为XML存储起来。通过这种方 式，数据会被插入到XML数据岛（另一项只有IE中才存在的功能）中。然后整个XML数据岛再被存入userData中。不过，像 Dojo.Storage这样的存储框架屏蔽了userData中的这些XML功能，通常只将名/值对以字符串的形式暴露出去。
在某些情况下，userData可以比其他存储方式存储更多的数据。Internet Explorer中不仅对每页数据的大小作出了限制，同时也对整个域的大小进行了限制。如果试图存储的数据容量超过了允许的大小，就会导致 JavaScript抛出一个异常。表8-2显示了Internet Explorer不同安全域中userData的存储能力。
表8-2 Internet Explorer不同安全区域中的userData存储能力
|
安 全 区 域 |
页大小限制 |
域大小限制 |
|
Intranet |
512KB |
10MB |
|
本机、可信任区域及Internet |
128KB |
1MB |
|
受限制区域 |
64KB |
640KB |
表中两个关系最紧密的域就是Internet和 Intranet。对于互联网上的普通网站来说，IE本身允许的存储容量要大于Flash的LSO，但是小于Mozilla的DOM存储。而对于 Intranet中的应用程序来说，userData的存储能力远远超过其他存储方式，10MB的存储容量可以存储下整个数据表、树型结构及其他体积更大 的数据结构。开发人员必须记住，userData是一种持久化存储方式，而不是驻留在内存中，因此关闭浏览器并不会删除这些数据。当使用userData 存储体积较大的数据结构时，开发人员需要格外小心。因为这些数据结构中可能会存有身份认证这样的敏感数据，如果被持久保存在客户端很可能被攻击者所利用。
由于名/值对是作为XML节点的属性存储在userData的XML文档中，因此Internet Explorer可以自动将某些特殊字符转义为XML中的对应字符。例如，双引号（”）会被替换为"，而连字符（&）会被替换 为&。由于这些自动转义的字符会增加实际存储的数据大小，因此开发人员必须确保有足够的空间来存储转义后的数据。
使用userData将会使数据共享受到极大的限制。不同域、甚至同一域下的不同子域之间都不能共享数据。此 外，同一主机不同端口上的应用程序之间也无法共享数据。我们只能在同域同目录下的不同页面之间共享数据。例如，http://company.com /Storage/ Checkout.html可以访问http://company.com/Storage/ UserData.html，以及任何/Storage/目录下网页所存储的数据。如果试图从其他页面访问，仅会返回一个null。这些默认的限制是无法 改变的，并且几乎与cookie的默认规则恰恰相反。这也使得userData成为了Internet Explore 5中少数几个较为安全的功能之一。
我们无法通过编程手段来删除掉存储在userData中的所有数据，只能对使用.userData样式的 HTML元素调用其removeAttribute()方法，来删除相应的名/值对。但是，我们无法遍历删除userData中实际存储的名/值对。虽然 开发人员应该知道存储在客户端的所有名/值对，但是，我们毕竟都是人，总会忘记一些事情，并且由于我们无法像为DOM存储编写一个clear()方法那 样，所以那些应该被删除的数据很可能被遗留在userData中。幸好，userData元素的expires属性可以提供一些帮助，开发人员可以通过它 来设置自动删除数据的过期时间。在默认情况下，存储在userData中的所有数据永远都不会过期。Interner Explorer不仅无法提供网站使用userData存储数据的时间，也没有提供任何关于userData的可视化界面，即使删除浏览器中的 cookie、缓存、历史记录和离线内容，也无法删除userDat中存储的数据。这些因素都增加了窃取客户端机器中数据的可能性。一旦确保不再需要使用 应用程序中的某些数据，开发人员就应该立即将它们删除掉。
要查看userData中存储的数据不是不可行，但需要一些技巧。首先，在Windows Explorer（随便打开一个Windows文件窗口）的文件夹选项中切换到“查看”选项卡，勾选“显示所有文件和文件夹”复选框，并取消选择“隐藏受 保护的操作系统文件（推荐）”选项。然后我们打开userData目录，在Windows XP系统中即为C:Documents and SettingsUSER_NAMEUserData。虽然userData都存储在XML文件中，但是Internet Exploerer使用缓存的存储机制来存储这些XML。例如，用一个名为index.dat的索引文件来存储所有的元数据（Metadata），然后将 其中的元素（即不同域用来存储userData的XML）分别存储在5个随机生成的目录下。我们可以通过查看index.dat索引文件，以及目录中的所 有XML文件，来确定具体使用的userData存储系统。
不过，要想修改userData中存储的内容却是非常复杂的，因为我们无法直接修改缓存目录中的XML文件。 如果真这么做，那么JavaScript在加载修改后的数据时，会抛出一个数据格式错误的异常。这意味着在index.dat文件中保存了某些哈希散列 值，或者XML文件的长度。不幸的是，index.dat不是一种开放的文件格式。在互联网上，只有很少一些网站详细描述了该文件结构的内部结构。我们 （本书作者）经过一晚上大量的尝试和失败，终于发现XML文件的长度的确存储在index.dat文件中。注意，index.dat里 的+0x20偏移量就用来保存文件的长度，当前值为136字节，也正是我们用来存储持久化userData的XML文件的长度。
于是，现在攻击者可以任意修改userData中存储的持久化数据，只要最后更新index.dat文件中的 XML文件长度即可。
我们再一次重申，任何形式的客户端存储都可以被用户查看并修改。开发人员永远都不能相信任何来自客户端的数据。
总结
l userData提供了持久化存储功能。如果要模拟非持久化存储，开发人员可以使用浏览器的unload()方法来清除userData数据。
l 可以指定userData是否自动过期。在默认情况下，userData中的数据永远不会过期。
l 只有满足以下3个条件，页面之间才能共享userData数据：同一端口、同一服务器、同一目录下。必须遵守该规定，并且域和域之间也无法共享数据。
l userData可以存储XML或者字符串数据。开发人员必须将复杂的数据类型进行序列化，转化为这两种格式，并实现相应的反序列化功能。
l 通过文本编辑器就可以查看userData中的数据，而修改其中的数据需要十六进制编辑器。