1. 理解IndexedDB keyPath的限制
indexeddb的keypath属性是定义对象存储中索引的关键，它指定了用于创建索引的数据项路径。然而，其设计并非完全自由。根据w3c indexeddb规范，keypath中的“步骤”（steps）被严格限制为符合javascript标识符的规则。这意味着，如果您的数据对象中包含嵌套属性，例如{ user: { profile: { name: "john" } } }，您会像在javascript中访问obj.user.profile.name一样，使用字符串"user.profile.name"作为keypath。
这种设计理念确保了keyPath的简洁性和与JavaScript对象属性访问的语义一致性。它暗示了keyPath的解析机制是基于点运算符（.）的属性链访问。
2. 特殊字符带来的挑战
当数据对象的属性名包含@、&等特殊字符时，例如{ "text@": "some value" }，在JavaScript中，我们无法直接使用点运算符obj.text@来访问它，而必须使用方括号表示法obj["text@"]。正是这种访问方式的差异，导致了keyPath无法直接处理含有特殊字符的属性名。
尝试对特殊字符进行编码或替换通常无法解决问题，因为IndexedDB的keyPath解析器期望的是一个合法的JavaScript标识符链，而不是一个经过编码的字符串字面量。这意味着，诸如objectStore.createIndex("myIndex", "text@")这样的代码将无法按预期工作，导致索引创建失败或行为异常。
3. 推荐解决方案：数据预处理策略
鉴于keyPath的限制，最可靠的解决方案是在数据存储到IndexedDB之前对其进行预处理（massage），确保所有用于索引的属性名都符合JavaScript标识符规范。
3.1 存储前的数据转换
在将包含特殊字符属性的对象存入IndexedDB之前，您需要创建一个新的、符合规范的属性，并将原始特殊字符属性的值赋给它。
示例代码：
// 假设原始数据对象
const originalData = {
id: 1,
"title@": "IndexedDB Special Characters",
"text&content": "This is the main content."
};
/**
* 转换函数：将对象中包含特殊字符的属性名转换为符合IndexedDB keyPath规范的属性名。
* @param {Object} obj - 原始数据对象。
* @returns {Object} - 转换后的数据对象。
*/
function preprocessObjectForIndexedDB(obj) {
const newObj = { ...obj }; // 创建一个副本，避免修改原始对象
if (newObj["title@"]) {
newObj.indexedTitle = newObj["title@"]; // 创建新属性，符合JS标识符规范
// 可选：删除原始特殊字符属性，以避免冗余存储
delete newObj["title@"];
}
if (newObj["text&content"]) {
newObj.indexedTextContent = newObj["text&content"];
delete newObj["text&content"];
}
return newObj;
}
const processedData = preprocessObjectForIndexedDB(originalData);
console.log(processedData);
/*
预期输出:
{
id: 1,
indexedTitle: "IndexedDB Special Characters",
indexedTextContent: "This is the main content."
}
*/
// 接下来，将 processedData 存储到 IndexedDB
// objectStore.add(processedData);3.2 创建索引
在数据预处理之后，您就可以使用新创建的、符合规范的属性名来创建索引了。
示例代码：
// 假设 db 已经打开，并且 objectStore 已经创建
// const db = ...;
// const transaction = db.transaction(["myStore"], "readwrite");
// const objectStore = transaction.objectStore("myStore");
// 在版本升级或数据库首次创建时定义索引
db.onupgradeneeded = (event) => {
const db = event.target.result;
if (!db.objectStoreNames.contains("myStore")) {
const objectStore = db.createObjectStore("myStore", { keyPath: "id", autoIncrement: true });
// 使用转换后的属性名创建索引
objectStore.createIndex("byIndexedTitle", "indexedTitle", { unique: false });
objectStore.createIndex("byIndexedTextContent", "indexedTextContent", { unique: false });
console.log("Object store and indexes created.");
}
};3.3 检索后的数据还原（可选）
如果您的应用程序在检索数据后仍然需要使用原始的特殊字符属性名，您可以在从IndexedDB中读取数据后进行逆向转换。
示例代码：
// 假设从 IndexedDB 检索到的数据
const retrievedData = {
id: 1,
indexedTitle: "IndexedDB Special Characters",
indexedTextContent: "This is the main content."
};
/**
* 还原函数：将IndexedDB中符合规范的属性名还原为原始的特殊字符属性名。
* @param {Object} obj - 从IndexedDB检索到的数据对象。
* @returns {Object} - 还原后的数据对象。
*/
function postprocessObjectFromIndexedDB(obj) {
const originalObj = { ...obj };
if (originalObj.indexedTitle) {
originalObj["title@"] = originalObj.indexedTitle;
delete originalObj.indexedTitle;
}
if (originalObj.indexedTextContent) {
originalObj["text&content"] = originalObj.indexedTextContent;
delete originalObj.indexedTextContent;
}
return originalObj;
}
const revertedData = postprocessObjectFromIndexedDB(retrievedData);
console.log(revertedData);
/*
预期输出:
{
id: 1,
"title@": "IndexedDB Special Characters",
"text&content": "This is the main content."
}
*/4. 注意事项与总结
- 无内置转义机制： IndexedDB规范中没有提供任何机制来直接“转义”keyPath中的特殊字符，使其能够直接引用非JavaScript标识符属性。数据转换是目前唯一的有效策略。
- 数据结构一致性： 实施数据预处理策略意味着您的IndexedDB内部存储的数据结构可能与应用程序中原始数据对象的结构有所不同。这要求在应用程序的存储和检索逻辑中保持一致的转换处理。
- 性能考量： 对于大量数据的频繁存储和检索，数据转换会引入额外的处理开销。在设计时应权衡这种开销与索引功能的重要性。
- 命名约定： 建议为转换后的属性名采用清晰、一致的命名约定（例如，添加indexed前缀），以便于代码维护和理解。
总之，当您需要在IndexedDB中为包含特殊字符的属性创建索引时，必须通过数据预处理来调整数据结构，使其符合keyPath的JavaScript标识符限制。虽然这增加了数据处理的复杂性，但它是确保IndexedDB索引功能正常运作的关键步骤。
