跨国报价邮件乱码
外贸跟单员给德国客户发 PDF 报价单，正文里用中文备注了「含 17% 增值税」，客户回复说看到一堆等号和乱码。其实是邮件系统把中文字符按 8bit 发送，对方网关不支持。用本工具把备注段手动编码成 QP 格式，客户收到的就是可读的「=BA=AC 17% =D4=F6=D6=B5=CB=B0」，双方不用换邮件客户端。
文本 plain · UTF-8
0 字符 · 0 字节
Quoted-Printable =HH · 软换行
0 字节
编辑「文本」→ 实时生成 QP；编辑「QP」→ 实时解码 文本
示例：点
中 → =E4=B8=AD ·
a=b → a=3Db ·
=E4=BD=A0=E5=A5=BD → 你好
就绪 · 输入文本或 QP 即时互转
第一节
关于本工具
About收到一封邮件，正文里本该是中文的地方全是“=E4=B8=AD=E6=96=87”这样的乱码——这是QP编码在作祟。这个工具把邮件传输中为了兼容7位ASCII而转码的QP文本还原回可读内容，也支持将中文或特殊符号编码成QP格式。纯浏览器处理，文件不离开本地，适合调试邮件模板、处理旧邮件存档时快速解码。
使用场景
旧系统传特殊符号
财务系统只支持 ASCII，但报销单备注里必须写「™」和「®」商标符号。IT 运维被这两个字符卡了一周，每次转码都丢数据。用本工具把整段备注编码成 QP，每字节转成「=XX」形式，老系统照常存储，解码后符号一个不丢，且不引入任何额外转义字符。
邮件列表发中文公告
社区管理员用群发工具给 2000 人发活动通知，正文里混了中英文。部分订阅者用 Outlook 2007 收不到中文，只显示「??」。管理员把整段正文用 QP 编码后粘贴进邮件客户端，所有字符被拆成「=E4=BD=A0=E5=A5=BD」格式，老版本 Outlook 也能正常解码显示，无需逐个用户排查。
嵌入式设备日志传输
物联网工程师在串口调试时，传感器上报的 JSON 里含中文设备名「温度传感器#3」。串口工具只认 ASCII，每次传完中文段就断帧。用本工具把中文设备名字段预先编码成 QP，串口按纯 ASCII 发送，接收端再用本工具解码还原，日志完整无乱码，且编码后长度只膨胀约 3 倍。
邮件签名保留特殊字符
设计师在邮件签名里放了「© 2025」和「✉」符号，发给自己测试正常，但对方用 Lotus Notes 收到时变成方框。用本工具把签名文本整体编码，在邮件客户端里以「Content-Transfer-Encoding: quoted-printable」头声明，对方自动解码，方框变回原符号，且签名排版不被打乱。
第二节
使用指南
Getting Started使用步骤
- 1在「输入」框粘贴或键入待编码/解码的文本，右侧预览区同步显示原始字符与字节数
- 2点击「编码」按钮将文本转为 QP 格式（=XX 形式），结果区高亮标记所有转义字符
- 3点击「解码」按钮将 QP 编码文本还原为原始内容，结果区显示解码后的可读文本
- 4点击结果区任意位置自动选中全部文本，按 Ctrl+C 或右键复制到剪贴板
- 5展开「字符统计」面板查看编码前后字节数变化，确认转义比例
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| Hello, World! | Hello, World! | 常规：纯 ASCII 文本，QP 编码后不变，验证无特殊字符时的输出 |
| 中文测试 | =E4=B8=AD=E6=96=87=E6=B5=8B=E8=AF=95 | 常规：非 ASCII 字符（UTF-8 编码）被等号+十六进制转义，验证中文编码 |
| =3D | = | 边界：输入已含等号，QP 解码时 =3D 应还原为 =，验证转义还原 |
| A line with newline | A line=0Awith newline | 边界：换行符（LF）被编码为 =0A，验证行结束符处理 |
| leading and trailing spaces | leading and trailing spaces =20 | 边界：行尾空格被编码为 =20，行首空格保留，验证空格策略（RFC 2045 规定行尾空格需编码） |
| =E4=B8=AD=E6=96=87=E6=B5=8B=E8=AF=95 | 中文测试 | 易错：输入是 QP 编码字符串，解码后还原为中文，验证解码功能与编码对称性 |
| A line with a tab character | A line with a tab=09character | 易错：制表符（TAB）被编码为 =09，用户常误以为制表符会保留，验证非打印字符编码 |
| =3D=3D=3D | === | 易错：连续等号编码，解码后还原为三个等号，验证连续转义序列的解析 |
常见错误对照
1.混淆 QP 编码与 Base64 编码
✗ 错误
将邮件附件图片直接拖入 QP 编码输入框✓ 修复
QP 编码只用于纯文本或 ASCII 兼容的短字段，二进制文件应使用 Base64QP 编码将非 ASCII 字节转为 =XX 形式，但二进制数据会使体积膨胀 3 倍以上，且邮件客户端可能解析失败。RFC 2045 规定 QP 适用于文本，Base64 适用于二进制。
2.未对等号本身进行编码
✗ 错误
输入文本包含等号，如 'a=b'，直接编码✓ 修复
等号应编码为 =3D，即输入 'a=3Db' 或由工具自动处理QP 编码中等号是转义前缀，字面等号必须转义为 =3D，否则解码器会将后续字符误读为编码序列。
3.手动添加软换行时破坏编码序列
✗ 错误
将长行手动拆分为 76 字符，结果在 =XX 中间换行，如 '=A
B'✓ 修复
软换行应放在编码序列之后，且行尾加 '=' 表示续行，或由工具自动处理RFC 2045 规定 QP 行最长 76 字符，软换行必须在编码序列完整后插入，且行尾用 '=' 标记续行，否则解码器会得到残缺字节。
4.解码时误将普通等号当作编码前缀
✗ 错误
输入 'abc=3Ddef' 解码得到 'abc=def'，但输入 'abc=def' 也期望得到 'abc=def'✓ 修复
只有 =XX 形式的序列（XX 为两位十六进制）才解码，孤立等号应保留或报错QP 解码器严格匹配 = 后跟两位十六进制数。非此格式的等号（如 '=def'）应视为字面等号，不进行解码。
5.对空格和制表符的错误处理
✗ 错误
在行尾保留空格或制表符，编码后未转为 =20 或 =09✓ 修复
行尾空格应编码为 =20，行尾制表符应编码为 =09，行内空格可保留RFC 2045 规定 QP 编码行尾不能有空白字符，否则某些邮件传输代理会将其删除或导致格式错误。行内空格可保留，但行尾必须编码。
6.忽略编码后行长度限制
✗ 错误
输入一段 200 字符的中文文本，编码后输出单行 600 字符✓ 修复
编码后每行不超过 76 字符，超出部分自动插入软换行（行尾加 =）邮件传输协议（SMTP）对行长度有限制，RFC 2822 建议每行不超过 998 字符。QP 编码后非 ASCII 字符膨胀 3 倍，必须软换行以保证兼容性。
7.对已编码文本重复编码
✗ 错误
将 '=E4=B8=AD'（已编码的'中'字）再次输入编码器✓ 修复
只对原始明文编码一次，已编码文本应直接传输或解码后再处理QP 编码不是幂等操作。对已编码文本再次编码会将等号转为 =3D，导致解码后得到 '=E4=B8=AD' 而非原文字，造成数据损坏。
8.编码时未指定字符集导致解码乱码
✗ 错误
仅输出编码后的 =XX 序列，不告知接收方原始字符集（如 UTF-8）✓ 修复
在邮件头或文档中明确声明 charset=UTF-8，或使用 =?UTF-8?Q?...?= 格式QP 编码只处理字节，不保存字符集信息。若接收方用 ISO-8859-1 解码 UTF-8 编码的字节序列，会得到乱码。RFC 2047 要求 MIME 编码必须附带字符集声明。
第三节
工作原理
How It Works核心公式
QP 编码：=HEX(byte) 或 =HEX(byte)=\nQP 解码：=HEX(byte) → byte
变量说明
byte待编码的字节值，0x00–0xFFHEX(byte)字节的两位十六进制大写表示
示例
编码字节 0x4A（字母 J）：QP 编码为 =4A。解码时遇到 =4A 还原为字节 0x4A，即 ASCII 字符 J。
输入 / 输出
编码 / 解码处理
编码结果
第五节
常见问题
Q & A问这个Qp编码解码，是不是只能用在邮件里？＋
答
QP（Quoted-Printable）编码最初是为电子邮件正文设计的，特别是为了在纯文本传输协议中安全传输包含非ASCII字符（如中文、特殊符号）的内容。但它的用途不限于邮件。任何需要在7位ASCII通道中保留8位数据完整性的场景，比如某些HTTP头、配置文件或旧系统间的文本交换，都可以用。本工具是纯前端实现，输入任何文本都能编码或解码，不检查内容来源，所以也适用于邮件以外的场景。
问编码后为什么有的字符变成=后面跟两个数字，有的还是原样？＋
答
这是QP编码的规则决定的。空格和可打印ASCII字符（字母、数字、部分标点）通常保持原样，只有非ASCII字符（如中文、带变音符号的字母）或特殊控制字符才会被转成'='加两位十六进制数。例如，英文字母'A'不变，而汉字'中'会被编码成'=E4=B8=AD'。本工具严格遵循RFC 2045标准，编码结果里不会出现不必要转义，解码时也能正确还原所有字符。
问解码出来的文本，末尾多了一个换行或者少了一个换行，是不是工具有bug？＋
答
不是bug，这是QP编码的软换行（soft line break）机制导致的。RFC 2045规定每行最多76个字符，超长行会自动插入'=\r\n'作为软换行标记，解码时这些标记会被移除。如果原始文本行末就有硬换行（如\r\n），编码后可能被误判为软换行。本工具解码时严格按标准处理：只移除'='后紧跟\r\n的软换行，保留真正的硬换行。建议编码前确保文本行末换行符统一，解码后检查行尾是否有多余空格。
问我有一段乱码，怎么判断它是不是QP编码？＋
答
看特征：QP编码的典型标志是大量出现'='后面跟两位十六进制数（如=E4=BA=BA），且文本中不会有其他编码常见的'%'或'&'前缀。如果乱码里只有'='和字母数字组合，且'='出现频率很高，那极大概率是QP编码。把这段文本直接粘贴到本工具的解码输入框，点击解码，如果输出变成可读的中文或符号，就确认了。注意，如果原始文本是UTF-8编码的QP，解码后就是UTF-8文本；如果是GBK编码的，解码后可能仍是乱码，需要先确认原始编码。
问用这个工具编码，和用Base64编码有什么区别？哪个更小？＋
答
核心区别：QP编码只转义非ASCII字符，ASCII字符保持原样，所以编码后体积通常比原文大10%-30%（中文多时更大）；Base64把整个数据重新编码，体积固定增大约33%。如果文本里英文和数字占多数，QP编码后的体积更小；如果全是中文，Base64反而更紧凑。另一个区别：QP编码结果仍然是可读的（能看到部分原文），方便人工检查；Base64是完全不可读的乱码。选择哪种取决于场景——邮件正文常用QP，附件或二进制数据用Base64。
问我复制了一段QP编码的文本进去，解码后中文变成问号了，怎么回事？＋
答
最常见的原因是编码与解码时的字符集不一致。QP只负责转义字节，不负责字符集转换。如果原始文本是GBK编码后做的QP编码，而本工具解码时假设输入是UTF-8，那么解码出的字节会按UTF-8解析，导致中文变成'?'或乱码。解决步骤：1) 确认原始邮件或文件的字符集（常见GBK、UTF-8、ISO-8859-1）；2) 在工具解码前，先确保输入文本的字符集正确（浏览器默认用UTF-8）；3) 如果无法确定，可以尝试在输入前用文本编辑器另存为UTF-8再复制。本工具解码后输出的是UTF-8文本，如果原始是其他编码，需要手动转换。
问这个工具是纯前端处理的，我的文本会不会被上传到服务器？＋
答
不会。本工具的实现方式是FE（纯前端），所有编码和解码操作都在浏览器本地完成，没有任何数据上传到服务器。输入文本、中间结果、最终输出都只存在于当前页面的内存中，刷新页面或关闭标签页后自动清除。可以断网测试——断开网络后，工具仍然能正常工作。这保证了敏感邮件内容或私人文本的隐私安全。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。