最小化(压缩;放气)数据库存储的 html:有必要吗?

发布于 2024-12-29 19:37:48 字数 266 浏览 2 评论 0原文

我将电子邮件正文中的 HTML 存储在 SQL Server nvarchar(max) 列中。 最小化 HTML 传输方式有什么好处吗?

我所说的“最小化”是指删除 HTML 文本流中多余的空格和回车/换行符。我的术语可能不太正确:我不打算删除任何 HTML 标签/注释或类似的内容。

我所说的好处是指存储空间的效率、插入/检索的速度,因此好处主要集中在数据库方面。

如果值得这样做,我应该注意什么(例如,如果我用单个空格替换换行符,以后可能会错误地呈现 HTML)?

I am storing the HTML from the body of emails in a SQL Server nvarchar(max) column.
Is there any benefit in minimizing the HTML on the way in?

By minimizing I mean removing redundant white space and carriage returns/linefeeds in the HTML text stream. My terminology might not be quite right: I'm not looking at removing any HTML tags/comments or anything like that.

By benefit I mean in terms of efficiency of storage space, speed of insert/retrieval, so benefits are focused on the database side.

If it is worthwhile to do, what should I look out for (e.g. if I replace linefeeds with a single space, might it render the HTML incorrectly at a later time)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

蓝戈者 2025-01-05 19:37:48

您仍然需要一个完整的 HTML 解析器来了解什么是 HTML,什么不是。大多数浏览器都会进行一些“修复”,以使原本无法呈现的 HTML 能够以图形方式呈现——这样一来,如果不完全解析树,就不可能实现。

有人可能会在其中插入一些错误的 HTML,这会很容易地使您的“简单”解析器出现错误,而不是出于恶意。不要参与修复 HTML 的工作,逐字处理它,让不良内容自行挂起。

You'd still have to have a full HTML parser to understand what's HTML and whats not. Most browsers do a bit of 'fixing up' to make otherwise unpresentable HTML graphically renderable -- in such a way that without fully parsing the tree would be impossible.

Someone could stick some bad HTML in that'd goof up your 'simple' parser pretty easily more often by mistake than malice. Don't get in the business of fixing HTML, handle it verbatim and let the bad content hang itself.

清眉祭 2025-01-05 19:37:48

HTML 将仅作为 BLOB 存储在数据库中。你将无法解析它、搜索它等(好吧,从技术上讲你可以,但这很愚蠢)。在这种情况下,您可以在客户端中(解压缩)它并将其发送+将其作为 varbinary(max) 存储在数据库中。

权衡是管理压缩的 CPU 时间与增加的存储+网络流量。

我不会清理 HTML,因为您会失去可读性,甚至可能失去原始内容。

HTML will be just be stored as a BLOB in the database. You won't be able to parse it, search it etc (well, you technically can but that's silly). In that case, you can (un)compress it in the client and send it+store it as varbinary(max) in the database.

The trade off is CPU time to manage compression vs increased storage+network traffic.

I wouldn't sanitise the HTML because you'll lose readability and possibly original content.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文