所以我真的不希望这个问题是针对特定语言的，但是我怀疑Go（我的语言选择）在这里发挥了作用。我正在尝试在原始电子邮件的正文中找到一个字符串。为此，我正在获取编码，大多数情况是quoted-printable。好的，那很好，我正在对我的搜索查询进行编码，并引用可打印的内容，然后对其进行搜索。那个有效。然而。在一种特定情况下，我在gmail中看到的原始电子邮件看起来不错，但是当我从gmail API检索原始电子邮件时，尽管编码和所有内容都相同，但其将"编码为=22研究表明，那是因为字符集为utf-8。我还不太清楚是不是先编码utf-8，然后用quoted-printable还是相反的方式编码，但这也不是问题……。如果我查看"为=22的电子邮件，我会看到字符集为utf-8，而当我查看另一未编码的字符集时，字符集为UTF-8（请注意）。我不敢相信这里的情况是导致这种情况发生的原因，但是，如果=22实际上是=22还是"编码的utf-8，它似乎还不够健壮。 >
我本来的想法是始终先对quoted-printable进行解码，然后再进行搜索之前对其重新编码，但我认为这不会成为一种可靠的方法，并且认为其他人可能会有更好的建议？
结论，我试图在原始电子邮件中找到一个字符串，但是编码导致我在获取搜索字符串以匹配正文的编码时遇到问题
所以我真的不希望这个问题是针对特定语言的，但是我怀疑Go（我的语言选择）在这里发挥了作用。我正在尝试在原始电子邮件的正文中找到一个字符串。为此，我...
[=22 -type编码实际上与字符集无关（无论是utf-8小写字母还是UTF-8大写字母或任何其他字符集）。