Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to analyze Cookie, UserData, SessionStorage and WebSqlDatabase in Web data storage. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Cookie

It is a standard way to save client browser state, and Cookie may have been available soon after the birth of the browser, so why do you need Cookie? Because the HTTP protocol has no state, a flag / storage is needed to record the current status of the client browser to ensure that the client browser can know the current status of the client browser when communicating with the server. Cookie is the container for recording this status. Cookie is brought back to the server on every request, thus ensuring that Server can know the current status of the browser. Because Cookie will be brought back to Server, the content of Cookie cannot be stored too much, and the maximum limit of introduction http://ec.europa.eu/ipg/standards/cookies/index_en.htm is 4K.

One of the paragraphs reads:

A browser is only required to store up to 300 cookies overall and maintain only the last 20 from each domain. The maximum size of a cookie is 4K of disk space.

However, in some scenarios, you may need to store more than 4K or more data, but the data does not need to be brought back to the server at each request, as long as it can be saved in the customer's browser and can be easily read and written by Javascript. This demand is especially urgent in medium and large RIA application scenarios. Some of the data is placed in the customer browser to save bandwidth and improve browsing speed. The HTML5 standard has come up with a solution for us to meet this need: sessionStorage, webSqlDatabase, Microsoft IE has a userData solution.

UserData

Microsoft's introduction to USERDATA: http://msdn2.microsoft.com/en-us/library/ms531424(VS.85).aspx

One of the paragraphs reads:

Security Alert:For security reasons, a UserData store is available only in the same directory and with the same protocol used to persist the store.

Security Alert:Using this behavior incorrectly can compromise the security of your application. Data in a UserData store is not encrypted and therefore not secure. Any application that has access to the drive where UserData is saved has access to the data. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

……

The userData behavior persists data across sessions, using one UserData store for each object. The UserData store is persisted in the cache using the save and load methods. Once the UserData store has been saved, it can be reloaded even if Microsoft Internet Explorer has been closed and reopened.

Setting the userData behavior class on the html, head, title, or style object causes an error when the save or load method is called.

UserData can access each other under the same directory and protocol and store it on the client machine for a long time. The maximum storage space has also increased a lot. UserData needs to be bound to a Dom element to use. There is a removeAttribute method in the method of userData. After testing the code, it is found that the removeAttribute method does not seem to work very well, and you need to use a way like cookie expiration before you can completely delete a userData Attribute.

It is introduced in http://www.itwen.com/04web/11skill/skill20060918/60588.html that userData is stored in the X:\ Documents and Settings\ current user\ UserData\ directory. The details of MS are not specified in the userData documentation.

SessionStorage

Introduction of sessionStorage in HTML5 standard: http://www.whatwg.org/specs/web-apps/current-work/

The introduction to sessionStorage:

This specification introduces two related mechanisms, similar to HTTP session cookies [RFC2965], for storing structured data on the client side.

The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.

Cookies dont really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing.

To address this, this specification introduces the sessionStorage DOM attribute. Sites can add data to the session storage, and it will be accessible to any page from that origin opened in that window.

Html5 sessionStorage Demo: http://html5demos.com/storage

Here is the test code based on the IE FF-compliant userData mentioned in http://www.blogjava.net/emu/archive/2006/10/04/73385.html:

The code is as follows:

Function isIE () {

Return!! document.all

}

Function initUserData () {

If (isIE ()) document.documentElement.addBehavior ("# default#userdata")

}

Function saveUserData (key, value) {

Var ex

If (isIE ()) {

/ / IE

With (document.documentElement) try {

Load (key)

SetAttribute ("value", value)

Save (key)

Return getAttribute ("value")

} catch (ex) {

Alert (ex.message)

}

} else if (window.sessionStorage) {

/ / FF 2.0 +

Try {

SessionStorage.setItem (key, value)

} catch (ex) {

Alert (ex)

}

} else {

Alert ("Error occured in user data saving. Your browser do not support user data.")

}

}

Function loadUserData (key) {

Var ex

If (isIE ()) {

/ / IE

With (document.documentElement) try {

Load (key)

Return getAttribute ("value")

} catch (ex) {

Alert (ex.message); return null

}

} else if (window.sessionStorage) {

/ / FF 2.0 +

Try {

Return sessionStorage.getItem (key)

} catch (ex) {

Alert (ex)

}

} else {

Alert ("Error occured in user data loading. Your browser do not support user data.")

}

}

Function deleteUserData (key) {

Var ex

If (isIE ()) {

/ / IE

With (document.documentElement) try {

Load (key)

Expires = new Date (315532799000). ToUTCString ()

Save (key)

}

Catch (ex) {

Alert (ex.message)

}

} else if (window.sessionStorage) {

/ / FF 2.0 +

Try {

SessionStorage.removeItem (key)

} catch (ex) {

Alert (ex)

}

} else {

Alert ("Error occured in user data deleting. Your browser do not support user data.")

}

}

What userData and sessionStorage have in common is that both objects can store much larger content than cookie. And will not be brought back to the server with each request. But according to Html5 standards and tests, it is found that there are many differences between userData and sessionStorage.

Here is a test page:

Among them, SetInsurance link will operate javascript to write data with userData under IE and sessionStore under FF. In the case of IE, the values written by shutting down IE or restarting the machine will not be lost. The situation under FF is interesting: the values written on this page are accessible on this page and on other pages opened by this page. But even if the page is open, enter the address in the navigation bar and open the page, the stored values will not be accessible. The value stored on this page is not accessible on its parent page (the page that opens this page). I looked at the Html5 standard again. The full name of sessionStorage is: Client-side session and persistent storage of name/value pairs means that the content stored in Client has a session session, and the stored value is maintained by the session session. Once the session session is interrupted or lost, the stored value disappears. So when the page does not have a session (the parent page, the page opened by the address bar), there is no value. When FF shuts down or restarts the machine, it will inevitably lose its value.

WebSqlDatabase

WebSqlDatabase is a very Cool thing in the HTML5 standard. Write SQL queries with Javascript, and the database is in the browser, which was almost unthinkable before. Today, however, Safari, Chrome and Opera are all supported. Two Demo pages of webSqlDatabase: http://html5demos.com/database http://html5demos.com/database-rollback

W3C's introduction to WEBSQLDATABASE: http://dev.w3.org/html5/webdatabase/

A concise description on WiKi: http://en.wikipedia.org/wiki/Web_SQL_Database

From W3C: "... an API for storing data in databases that can be queried using a variant of SQL"

Web SQL Database is supported by Google Chrome [1], Opera and Safari but will not be implemented by Mozilla (Firefox) [2] who instead propone Indexed Database API access.

I don't know how well HTML 5's SQLDB will be supported by browsers, but sessionStorage seems to be basically meeting the needs.

On Web data storage how to analyze Cookie, UserData, SessionStorage, WebSqlDatabase to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.