您在名称部分看到的象形图是Unicode表情符号。它们可以在任何有 Unicode 更新版本的地方使用。要查看每个 Unicode 版本支持的表情符号的完整列表，请查看此处。您几乎可以在任何地方复制和粘贴它们，它们会显示出来。

这些不包含跟踪，它们是从本地系统加载的。但是，如果将它们作为图像嵌入到电子邮件正文中，那就另当别论了。

那些不是图像。电子邮件“发件人：”标头可以包含文本且只能包含文本。除非您的邮件网络/应用程序客户端存在明显的安全漏洞，否则该字段将永远不会有任何图像。

您看到的包装礼物 - 🎁 - 是一个实际的文本字符，称为“包装礼物”。不管它在你看来多么形象，它仍然是一个像任何字母或数字一样的字符。例如，您可以在文本所在的任何位置选择并复制/粘贴它：在一些纯文本编辑器（如记事本）中，或者直接到此答案的句子中间，如您所见。

需要注意的一点是，虽然这些图像字符（表情符号）通常不被视为漏洞或错误方面的安全风险，但它们仍然具有间接的安全影响。

最大的暗示是，这些表情符号并不是 Unicode 的唯一特征。Unicode 的目标是它希望为世界上每一种书写系统的数字表示提供支持。问题是某些字符可以在多种语言中找到，但略有不同。例如，拉丁字母“a”也可以在俄语字母表中找到，与西里尔字母“а”一样，无论是大写还是小写看起来都完全相同。网络钓鱼者喜欢滥用这一点，将某些单词中的拉丁语“a”替换为西里尔字母“а”，以误导更幼稚的单词过滤器，或者将其作为IDN Homograph 攻击的域名的一部分。

可能不会，但是...

Unicode 的复杂性（BOM、UCS-2、UTF-16、UTF-8和UTF-7已经够糟糕了，但是你需要结合变音符号、零宽度空格、超长编码、从右到左切换）意味着与它相关的错误将比与 ASCII 相关的错误多得多。

对于显示 Unicode 文本的 Web 浏览器，风险非常小。您将 Unicode 文本传递给一个 Unicode 渲染器，该渲染器由懂 Unicode 的人编写。

当 Unicode 文本控制某些东西时，例如对文件的访问或电子邮件的路由，就会出现问题。尽管已有数十年历史，但臭名昭著的Microsoft IIS DotDot 漏洞就是一个很好的例子。这利用了字符的超长编码/，允许攻击者潜在地访问服务器硬盘驱动器上的任何文件。

在您的情况下，邮件通过几个邮件服务器进行路由。如果他们在处理电子邮件地址时存在漏洞，则邮件服务器可能会受到威胁——但它是FROM地址，所以它不应该造成太大的损害。...也就是说，除非您回复电子邮件（或有一些自动回复），否则它会变成一个TO地址，这可能是攻击者所希望的。😉

我敢肯定这种攻击非常罕见，如果发生这种情况，表情符号可能看起来像垃圾，但tl;dr 表情符号只是 Unicode 字符，您的设备极不可能通过在网络浏览器中查看它们而受到损害。