将原始数据存储在 cookie 中 - 好主意还是坏主意？
我想在 cookie 中存储最近查看的个人资料列表。
我有一个网站，人们可以在其中输入游戏角色 ID（魔兽世界）并可以查看该角色的个人资料。
字符标识由名称（unicode，最多 15 个字符）、服务器名称（unicode，最多 25 个字符）和区域（2 个字符，latin-1）组成。
我在 cookie 中存储最多 5 个最近查看的字符，并对这些值进行 URL 编码，因为并非所有浏览器都支持 unicode-cookie 友好。
这使得这个 cookie 的长度达到两个 500 个字符。
问题：这是一种合理的方法吗？我希望您评估以下一些其他解决方案。
- 按照数据库中定义的方式存储characterId。优点：cookie 大小小，缺点：a) 可以从数据库中删除字符（数据库只是一个缓存以加快更新速度），b) 数据库可以重新索引。
- 存储名称+服务器+区域哈希，并通过数据库中的哈希查找。缺点：a）同样，字符可以从数据库中删除，优点：抗重建索引。
- 要求用户创建一个帐户并将其存储在那里。缺点：没有人喜欢创建帐户，我不想这样做。
我是否在吹毛求疵，我目前的解决方案（将 URL 编码的列表存储在 cookie 中）是否足够好？
编辑：需要注意的是，“最近的字符”列表只是为了方便起见，如果它被清除 - 这根本不是问题（它类似于某些应用程序中的“最近的文件”） ）。
I want to store a list of recently viewed profiles in a cookie.
I have a site where people enter game character id (World of Warcraft) and can view the character's profile.
Character identity consists of name (unicode, up to 15 characters), server name (unicode, up to 25 characters), and zone (2 characters, latin-1).
I store up to 5 recently viewed characters in cookies, URL-encoding the values, since not all browsers are unicode-cookie friendly.
This makes this cookie up two 500 characters long.
Question: is this a reasonable approach? Here are few other solutions I would like you to evaluate.
- Store characterId as it is defined in the database. Pros: small cookie size, Cons: a) character can be removed from the database (database is just a cache to speed up update), b) database can get re-indexed.
- store name+server+zone hash, and look it up by hash in database. Cons: a) again, character can be removed from the database, Pros: reindexing resistant.
- require a user to create an account and store it there. Cons: nobody likes creating accounts, and I rather not do this.
Am I splitting hairs and my present solution (store URL-encoded list in a cookie) is good enough?
EDIT: It is important to note that "recent characters" list is there just for convenience, if it gets cleared - it is not a problem at all (it's akin to a 'recent files' in some applications).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您当前的解决方案没有遇到问题（或限制），我会保持原样。请注意，通过存储整个字符并呈现该数据，数据可能会过时。
我会将 ID 存储在 cookie 中，并执行一些服务器端逻辑以从 ID 列表中返回可用字符。数据库中不存在的 ID 可以跳过显示并再次出现在 ID 列表中。
If you are not experiencing problems (or limitations) with your current solution, I would keep it as is. Be aware, by storing the entire character, and presenting that data, the data could be outdated.
I would store the ID's in a cookie and do some server side logic to return the available characters from the list of ID's. ID's which are not present in the database can be skipped from displaying and turning up in the list of ID's again.
就我个人而言，我更愿意将 ID 存储在 cookie 中，并将其余数据存储在数据库中。如果可以在用户会话期间删除数据，请仅为用户会话创建一个新表（使用其 session_id）并将该 ID 存储在 cookie 中。在该表中放置一个日期时间，并定期（如在 cron 作业中）删除任何早于 x 天的记录。
Personally, I would prefer to have the ID stored in the cookie and have the rest of the data in the database. If the data can be deleted during a user's session, create a new table just for the user's session (use their session_id) and have that ID stored in the cookie. Put a datetime in that table and periodically (like in a cron job) delete any records that are older than x days.