클라이언트에 데이터를 저장해야 하는 이유는 무엇인가요? 클라이언트에 데이터를 저장하면 많은 문제를 해결할 수 있고 불필요한 데이터 전송을 줄일 수 있습니다.
1. 프로그램 상태를 저장할 수 있습니다. 사용자는 브라우저를 닫았다가 연 후에 어디에서 작업 중인지 알 수 있습니다. 또.
2. 데이터 캐시 기능: 변경되지 않는 데이터가 많기 때문에 매번 서버에서 데이터를 가져올 필요가 없습니다.
3. 사용자 기본 설정 저장 가능: 이러한 종류의 데이터는 일반적으로 서버에 저장할 필요가 없습니다.
이전 접근 방식 HTML5 로컬 저장 이전에는 클라이언트에 영구 데이터를 저장하려는 경우 다음과 같은 몇 가지 옵션이 있었습니다.
1. HTTP 쿠키의 단점은 명백합니다. 최대 4KB의 데이터만 저장할 수 있으며 각 HTTP 요청은 SSL을 사용하지 않는 한 일반 텍스트로 서버에 다시 전송됩니다.
2.IE 사용자 데이터. userData는 1990년대 브라우저 전쟁 중에 Microsoft가 출시한 로컬 저장소 솔루션으로, DHTML의 동작 속성을 사용하여 각 페이지에서 최대 64K의 데이터를 저장할 수 있으며 각 사이트에서는 최대 640K의 데이터를 저장할 수 있습니다. userData의 단점은 분명합니다. 이는 웹 표준의 일부가 아니므로 애플리케이션이 IE만 지원해야 하는 경우가 아니면 거의 쓸모가 없습니다.
3. 플래시 쿠키. 플래시 쿠키는 실제로 HTTP 쿠키와 동일하지 않습니다. 아마도 이름을 "플래시 로컬 저장소"라고 불러야 할 것입니다. 플래시 쿠키를 사용하면 각 웹사이트는 기본적으로 100K 이하의 데이터를 저장할 수 있습니다. 사용자는 Flash의 외부 인터페이스 인터페이스를 통해 대용량 저장 공간을 통해 Javascript를 통해 Flash의 로컬 저장소를 쉽게 운영할 수 있습니다. 플래시의 문제점은 단순히 플래시라는 것입니다.
4. 구글 기어. Gears는 Google이 2007년에 출시한 오픈 소스 브라우저 플러그인으로, 주요 브라우저의 호환성 향상을 목표로 하고 있으며, SQLite 기반의 SQL 데이터베이스가 내장되어 있으며, 사용자 확보 후 데이터베이스에 액세스할 수 있는 통합 API를 제공합니다. 승인을 받으면 각 사이트는 SQL 데이터베이스에 모든 크기의 데이터를 저장할 수 있습니다. Gears의 문제는 Google 자체가 더 이상 이를 사용하지 않는다는 것입니다.
눈부시게 다양한 기술로 인해 브라우저 호환성 문제가 발생합니다. 아마도 이곳에서 모두가 가장 많이 사용하는 것은 쿠키일 것입니다.
HTML5의 새로운 경험 위 문제에 대해 HTML5는 보다 이상적인 솔루션을 제공합니다. 저장해야 할 것이 단순히 키/값 쌍이라면 데이터로 해결할 수 있고, 웹 스토리지를 사용할 수 있습니다.
쿠키와 비교했을 때 웹 저장소는 다음과 같이 요약할 수 있는 많은 장점을 가지고 있습니다.
1. 더 큰 저장 공간: IE8의 각 독립 저장 공간은 10M이며, 다른 브라우저는 구현이 약간 다르지만 훨씬 더 큽니다. 쿠키보다.
2. 저장된 콘텐츠가 서버로 전송되지 않습니다. 쿠키가 설정되면 쿠키 콘텐츠가 요청과 함께 서버로 전송되며, 이는 로컬에 저장된 데이터에 대한 대역폭을 낭비합니다. 웹 스토리지의 데이터는 로컬에만 존재하며 어떤 방식으로든 서버와 상호 작용하지 않습니다.
3. 더욱 풍부하고 사용하기 쉬운 인터페이스: 웹 스토리지는 더욱 풍부한 인터페이스 세트를 제공하여 데이터 작업을 더욱 쉽게 만듭니다.
4. 독립적인 저장공간: 각 도메인(서브도메인 포함)은 독립적인 저장공간을 가지고 있습니다. 각 저장공간은 완전히 독립적이므로 데이터 혼동이 없습니다.
웹 스토리지 분류 웹 스토리지는 실제로 sessionStorage와 localStorage의 두 부분으로 구성됩니다.
sessionStorage는 세션에 데이터를 로컬로 저장하는 데 사용됩니다. 이러한 데이터는 동일한 세션의 페이지에서만 액세스할 수 있으며 세션이 끝나면 데이터가 삭제됩니다. 따라서 sessionStorage는 영구 로컬 저장소가 아니며 세션 수준 저장소일 뿐입니다.
LocalStorage는 데이터가 적극적으로 삭제되지 않는 한 영구 로컬 저장소로 사용됩니다.
웹 스토리지 지원 여부 확인 웹 스토리지는 모든 주요 브라우저에서 지원되지만, 이전 브라우저와 호환되기 위해서는 이 기술을 사용할 수 있는지 여부를 확인해야 합니다.
첫 번째 방법: Storage 개체가 있는지 확인하여 브라우저가 웹 저장소를 지원하는지 확인하세요.
if(typeof(Storage)!=="undefine"){
// 예! localStorage 및 sessionStorage 지원
// 일부 코드.. ..
} else {
// 죄송합니다. 웹 저장소는 지원되지 않습니다..
}
두 번째 방법은 각 개체를 별도로 확인하는 것입니다. localStorage 지원 여부 :
if (typeof(localStorage) == 'undefine' ) {
alert('브라우저가 HTML5 localStorage를 지원하지 않습니다. 업그레이드해 보세요.')
} else {
// 예! localStorage 및 sessionStorage 지원!
// 일부 코드.....
}
또는:
if('localStorage' in window && window['localStorage'] !== null) {
// 네! localStorage 및 sessionStorage 지원!
// 일부 코드.....
} else {
alert('브라우저가 HTML5 localStorage를 지원하지 않습니다. 업그레이드해 보세요.') ;
}
또는
if (!!localStorage) {
// 예! localStorage 및 sessionStorage 지원
// 일부 코드.....
} else 🎜>alert('브라우저가 HTML5 localStorage를 지원하지 않습니다. 업그레이드해 보세요.');
}
분명히 첫 번째 방법이 가장 직접적이고 간단합니다.
웹 스토리지 활용
웹 스토리지는 키-값 쌍을 저장하고, 브라우저는 이를 문자열로 저장합니다. 필요한 경우 다른 형식으로 변환하는 것을 잊지 마세요.
다른 용도를 제외하면 sessionStorage와 localStorage는 동일한 구성원 목록을 갖습니다.
key = value: 키-값 쌍 저장
setItem(key, value): 키-값 쌍 저장
getItem(key): 키-값 쌍 가져오기
removeItem(key ): 모든 키-값 쌍 제거
clear(): 모든 키-값 쌍 지우기
length: 키-값 쌍의 개수
강조되어야 함 여기서: setItem(key,value ) 메소드는 이론상 모든 유형이 될 수 있지만 실제로 브라우저는 문자열 값을 가져와 로컬에 저장하기 위해 value의 toString 메소드를 호출하므로 사용자 정의 유형인 경우 정의해야 합니다. 의미 있는 toString 메소드를 사용하세요. 예를 들어 다음 예는 JSON.stringify와 함께 사용됩니다.
var person = {'name': 'rainman', 'age': 24}
localStorage.setItem("me", JSON.stringify(person)); >JSON.parse(localStorage.getItem( 'me')).name; // 'rainman'
/**
* JSON.stringify, JSON 데이터를 문자열로 변환
* JSON.stringify({'name': 'fred', 'age': 24}) // '{"name":"fred ", "age":24}'
* JSON.stringify(['a', 'b', 'c']) // '["a","b","c"]'
* JSON.parse, 역방향 JSON.stringify
* JSON.parse('["a","b","c"]') // ["a","b","c" ]
*/
또한 키-값을 추가할 때 쌍, 추가된 수가 상대적으로 큰 경우 비교하십시오. 안전한 방법은 제한을 초과하는 예외가 있는지 확인하는 것입니다.
try {
localStorage.setItem(itemId, value.join(';'))
} catch(e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert( '할당량 초과!');
}
}
Web Storage의 방법은 매우 간단합니다. 예제는 버튼 클릭 횟수를 계산합니다.