邮箱签名生成器_HTML与纯文本双格式输出

使用方法

填「姓名」，这是唯一必填项，默认张伟。留空会被拦下并提示——一个没有署名的签名没有意义。
填职位、公司、电话。默认分别是 产品经理、柳泉科技、+86 138 0000 0000。这三项留空时会整行省略，不会留下一个孤零零的标签。
填「邮箱」，默认 zhangwei@example.com。格式不对会被拦下，提示缺的是 @ 还是域名后缀。
填「网址」，默认 https://www.example.com。必须以 http:// 或 https:// 开头，否则邮箱客户端会把它当相对路径，点开就是 404。
填地址，默认 北京市海淀区中关村大街 1 号。地址过长时纯文本版会自动换行，不用手动插回车。
点「生成签名」或在任一输入框里按 Enter。预览区立刻显示渲染效果，四格统计同时更新。
「复制 HTML」拿到的是完整表格源码，「复制纯文本」拿到的是每行不超过 78 字符的版本。两套都贴进邮箱签名设置里，客户端会自动按 MIME 的 multipart/alternative 选择该显示哪一套。

邮箱签名生成器能解决什么问题

一是让签名在所有客户端里长得一样。同一个签名在 Apple Mail 里排版正常、到了 Windows 版 Outlook 就散架，是因为后者用 Microsoft Word 的渲染引擎，不认 flex、grid，也不认 background-image。本页生成的 HTML 只用 <table> 加内联样式，这套写法在 Word 引擎下也能立住。

二是避免「签名字一多就被 Gmail 折叠」。Gmail 对 HTML 源码超过 102,005 字节的邮件会从下往上剪裁，把底部内容藏进「查看整封邮件」。一封邮件里有整个公司地址、社交链接、免责声明的长签名，很容易踩线。本页实时报出字节数，默认示例只占 0.82%。

三是同时交付 HTML 与纯文本两套。有些客户端或有些收件人设置了「只看纯文本」，这时如果只给了 HTML，签名会变成一团标签。两边都提供，收件人看到的才是干净的署名。

四是防止邮箱被当成链接文本漏掉。纯文本签名里的邮箱地址很多客户端不会自动识别，用户得手动复制。本页的 HTML 版把邮箱和网址包进 mailto: 与完整 https:// 链接，可点击率明显不同。

本页不做的事：它不生成签名里的 Logo 图片，也不做社交图标——那需要外链图片或 base64，而 base64 内联图片会让体积膨胀三分之一以上，还常被客户端拦截。想要 Logo 请用图床外链，或干脆只用文字。要把已有 HTML 签名还原成纯文本，用 HTML转纯文本转换器更方便。

原理：内联样式、表格布局与 102005 字节剪裁线

生成过程只有两步：转义、拼接。先把每个字段逐个过 escapeHtml()：& 换成 &、< 换成 <、> 换成 >、" 换成 "。不转义的后果很具体：名叫「李&王」的人会让整个签名表格解析错位，而 <script> 风格的字段则可能被部分客户端当成标签执行。转义之后按固定模板拼成 <table> 结构，行与行之间用 \r\n 连接，因为 RFC 5322 规定行分隔是 CRLF。

为什么必须用 table 而不是 div。Word 渲染引擎把 HTML 当成一份 Word 文档来排版，只认一小撮 1990 年代的标签和属性，盒模型、flex、grid 全都不支持。而 <table> 的 cellpadding、cellspacing、border 这三个属性从 HTML 4 起就没变过，是唯一跨客户端都成立的布局原语。所以本页的骨架是「一个 table、每个字段一行 tr、每行的内容放在 td 里」，间距靠 padding 而不是 margin——Word 引擎对 margin 的支持同样残缺。

为什么不能用 <style> 标签。Gmail 网页版、Gmail App、Outlook 桌面旧版、Outlook.com、Foxmail 都会把 <style> 里的规则整块剥离，只保留元素上的 style 属性。这意味着写在 <style> 里的 .sig-name { font-size: 16px } 在这几个客户端里等于没写。本页因此把每一条样式都直接写在元素上，代价是源码变长——默认示例 836 字节里，样式属性占了大约三分之二。

102,005 字节是硬阈值，而且算的是压缩后的 HTML 源码。Gmail 对源码超过这个值的邮件从底部开始剪裁，被剪掉的部分只在「查看整封邮件」链接后面。它数的是 HTML 与内联资源，外链图片不算在内，所以「把图片放外链」既能省体积又不会被拦。另一个常见放大项是 base64 内联图片：base64 把每 3 字节编码成 4 个字符，体积固定膨胀 33.33%，一张 100 KB 的图编码后约 133.3 KB，单它一张就超过整个阈值。

78 字符是纯文本行的经验上限。RFC 5322 §2.1.1 规定邮件每行 MUST 不超过 998 字符、SHOULD 不超过 78 字符（均不含 CRLF）。998 是很多实现真正会拒收的硬线，78 是为了迁就那些显示宽度窄的客户端——超过 78 个字符的行可能被截断或被丑陋地折行。本页的纯文本版逐行检查，默认示例最长一行 26 个字符，离上限还有很大余量。

完整示例（数值仅作演示）

页面打开时的默认字段是：姓名张伟、职位产品经理、公司柳泉科技、电话 +86 138 0000 0000、邮箱 zhangwei@example.com、网址 https://www.example.com、地址北京市海淀区中关村大街 1 号。下面是这套字段生成的两套签名。

HTML 源码共 836 字节、8 行，占 Gmail 102,005 字节阈值的 0.82%，剩余空间 101,169 字节；
这份 HTML 里没有 <style> 标签、没有 display:flex 或 display:grid、没有 base64 内联图片，三条都能通过上面那张兼容表；
纯文本版共 6 行、173 字节，最长一行是「网址：https://www.example.com」，26 个字符，低于 78 字符的建议线；
HTML 与纯文本的体积比是 4.83 倍——这个倍数意味着纯文本版几乎不可能触发剪裁；
转义示例：字段里出现 & 会变成 5 个字节的 &，< 与 > 各变成 4 字节的 < 与 >，" 变成 6 字节的 "；
若把一张 100 KB 的 Logo 转成 base64 内联进去，体积会变成约 133.3 KB，是阈值的 134%，必定被 Gmail 剪裁。

再看一个长度边界的例子：姓名填满 30 个汉字，UTF-8 下是 90 字节；地址填满 60 个汉字是 180 字节。即使所有字段都填到 maxlength 上限，HTML 源码仍在 3 KB 以内，离 102,005 字节的阈值有三十倍的安全距离。真正会把签名撑爆的是图片，不是文字。

输入范围与客户端兼容对照表

下表把常见邮箱客户端按渲染引擎分组，标出它对四类写法的支持情况。这张表决定了本页为什么选择内联样式加表格：只要有客户端会在某一列打叉，这套写法就不能用。

邮箱客户端	渲染引擎	<style> 标签	flex / grid	background-image	内联 base64 图片	签名建议
Gmail 网页版	自定义	剥离	部分支持	拦截	不支持	只用内联样式与表格
Gmail App（Android / iOS）	自定义	剥离	不支持	拦截	不支持	版式越简单越稳
Apple Mail（macOS / iOS）	WebKit	保留	支持	支持	支持	能显示，但别只迁就它
Outlook 365 / 2019（Windows）	Microsoft Word	剥离	不支持	不支持	不支持	必须用 table + 内联样式
Outlook 新版（Windows）	Chromium	保留	支持	支持	部分拦截	新版宽，旧版仍要兼容
Outlook for Mac	WebKit	保留	支持	支持	支持	接近 Apple Mail 的表现
Outlook.com（网页版）	自定义	剥离	不支持	拦截	不支持	同桌面旧版口径
QQ 邮箱（网页版）	WebKit	保留	支持	部分拦截	拦截	内联样式最稳
网易 163 邮箱	WebKit	保留	支持	部分拦截	拦截	避免外链图与底图
Foxmail 桌面版	IE 内核 / WebKit	剥离	不支持	不支持	不支持	按老 IE 口径写
Samsung Mail	Android WebView	保留	支持	支持	部分拦截	基本跟随系统内核
Thunderbird	Gecko	保留	支持	支持	支持	兼容性最好的一个

再看长度与体积的对照。文字字段即便全部填满，体积也远低于剪裁线；真正的风险来自图片。

内容	典型体积	占 102,005 字节阈值	结论
默认示例 HTML 签名	836 B	0.82%	安全
全部字段填满上限的 HTML 签名	≈2.8 KB	≈2.8%	安全
一张 100 KB 的 Logo 转 base64	≈133.3 KB	134%	必定被剪裁
外链 Logo（仅一行 `<img>`）	≈120 B	0.12%	安全，且不进源码计数

输入范围、边界与精度说明

姓名限 30 个字符、必填。邮箱签名里出现超过 30 字的姓名通常意味着填错了字段（把抬头写进了姓名）。留空时本页会拦下，而不是生成一个没有署名的模板。
职位与公司各限 40 字、可空。留空时整行省略，不会残留一个「职位：」的空标签。这是刻意的：空标签在 Word 引擎下会撑出一个多余的行高。
电话限 30 字，不强制数字格式。因为 +86 138 0000 0000、(010) 8888 6666、138-0000-0000 都是合法写法，强行只留数字反而会丢信息。本页只在电话里出现 < 或 > 这类会破坏 HTML 的字符时会转义处理。
邮箱必须匹配 ^[^\s@]+@[^\s@]+\.[^\s@]{2,}$。这是简化规则，不覆盖 RFC 5322 的完整文法（引号本地部分、IP 字面量、注释这些写法都会被拒）。对本页足够：签名里的邮箱写规范一点没有坏处。
网址必须以 http:// 或 https:// 开头。只写 www.example.com 时，很多客户端会把它当相对链接，在邮件里点开就是 404。这个邮箱签名生成器直接拦下并给出补全建议。
地址限 60 字。超过这个长度纯文本版会自动折行，HTML 版则交给 td 的宽度自动换行。两套都不裁字。
HTML 源码字节数按 UTF-8 统计。一个汉字 3 字节，一个 ASCII 字符 1 字节，所以「同一段文字」在中文和英文下的字节数差三倍。计数用的是编码后的字节数，不是字符数——因为 Gmail 阈值是按字节算的。
本页刻意不做的近似。不插入追踪像素（那会引入外链请求与隐私问题）、不做社交图标（需要外链图片）、不生成 vCard 附件（multipart/alternative 里再挂附件会让结构复杂化）。

常见问题

为什么复制到 Outlook 里格式全乱了？

因为 Windows 版 Outlook 用的是 Microsoft Word 的渲染引擎，不是浏览器内核。它不认 flex、grid、background-image，也会把 <style> 块剥掉。本页的邮箱签名生成器从一开始就只用 <table> 加内联 style 属性，这两样从 HTML 4 起就没变过，是 Word 引擎唯一稳定支持的组合。

为什么建议同时保留纯文本版？

因为收件人的客户端会自己选。邮件按 MIME 的 multipart/alternative 结构发送时，同一个签名会带 HTML 和纯文本两份，客户端挑它能显示的那份。如果只有 HTML，遇到「只看纯文本」的设置或老客户端，你的签名就会变成一堆尖括号标签。两份都填，是成本最低的保险。

78 字符这个数字是从哪来的？

来自 RFC 5322 §2.1.1。规范里写了两条：每行 MUST 不超过 998 字符，SHOULD 不超过 78 字符，都不含行尾的 CRLF。998 是很多邮件实现的硬上限，超了可能被拒收或截断；78 是更保守的建议值，专门照顾显示宽度窄的客户端。本页按 78 检查，因为纯文本签名本来就不该有很长的行。

签名里能不能放公司 Logo？

能，但要放外链地址，不要转成 base64 内联。原因有两个：base64 会让体积膨胀 33.33%，一张 100 KB 的图编码后约 133.3 KB，单它一张就超过 Gmail 的 102,005 字节剪裁线；而且 Gmail、QQ 邮箱、163 邮箱都可能拦掉内联图片，收件人只看到一个红叉。外链图片不计入 HTML 源码体积，是更稳的做法。

为什么必须填姓名，其他字段却可以空着？

因为签名的唯一职能就是告诉收件人「这封邮件是谁发的」。没有姓名的签名在中文商务邮件里几乎无法辨认身份。反过来，职位、公司、电话、地址都可能是刻意不公开的（比如自由职业者或内部邮件），所以它们留空时本页只做省略处理，不报错。

「HTML / 纯文本体积比 4.83 倍」说明什么？

说明 HTML 版的信息冗余度高——同样的内容，为了跨客户端兼容，每条样式都要重复写在元素上，标签也要成对出现。这个倍数本身不危险，因为两者都远低于任何阈值。它的用处是提醒你：如果哪天 HTML 版体积涨得很快，多半不是文字变多，而是有人往里塞了图片或大量重复的内联样式。

复制粘贴时选「保留源格式」还是「纯文本」？

看你贴到哪里。贴进邮箱客户端的「签名」设置里通常要保留源格式（HTML 视图），这时用「复制 HTML」；贴进纯文本的签名档或工单系统，用「复制纯文本」。如果只有 HTML 源码又必须变成纯文本，可以先贴进编辑器再另存为纯文本，或者用 HTML转纯文本转换器处理。

字段里出现特殊符号会怎样？

会被转义，不会破坏结构。比如姓名写「A&B」，输出里是「A&B」，渲染出来仍然是「A&B」。四类字符会转义：&、<、>、"。不转义的后果很具体——名为「李<王」的人会让整个表格的标签错位，签名直接散架。

邮箱签名生成器