Gmail API返回text/plain内容编码不符问题排查与求解

你遇到的这个乱码问题其实是Gmail API的特殊处理逻辑导致的，我来帮你拆解清楚：

问题根源：Gmail的编码标准化 #

Gmail在接收和存储邮件时，会自动将所有文本内容统一重新编码为UTF-8，但它会保留原始邮件头里的charset参数不变。也就是说：

• API返回的part.Body中的base64url解码后字节，已经是UTF-8格式的
• 但Content-Type头里的charset还是原始邮件声明的编码（比如windows-1251、koi8-r）

这就导致你按照声明的charset解码时，相当于把UTF-8字节当成了其他编码来解析，自然会出现乱码；而改用UTF-8解码就和Gmail内部存储的内容一致，所以能正常显示——这也是Gmail网页端能正确展示的原因，它实际用的是UTF-8解码，并没有严格遵循头里的charset。

正确的实现方案 #

既然明确了Gmail的这个行为，你可以直接忽略Content-Type中的charset参数，统一用UTF-8解码即可。修改后的代码如下：

public static string DecodeTextPart(Google.Apis.Gmail.v1.Data.MessagePart part) 
{ 
    var content_type_header = part.Headers.FirstOrDefault(h => string.Equals(h.Name, "content-type", StringComparison.OrdinalIgnoreCase)); 
    if (content_type_header == null) 
        throw new ArgumentException("No content-type header found in the email part"); 
    
    var content_type = new System.Net.Mime.ContentType(content_type_header.Value); 
    if (!string.Equals(content_type.MediaType, "text/plain", StringComparison.OrdinalIgnoreCase)) 
        throw new ArgumentException("The part is not text/plain"); 
    
    // 直接使用UTF-8解码，忽略Content-Type中的charset声明
    return Encoding.UTF8.GetString(GetAttachmentBytes(part.Body)); 
}

如果担心极端场景下可能存在例外（虽然实际测试中极少出现），你也可以做一个容错处理：先尝试用声明的charset解码，若抛出解码异常，再 fallback 到UTF-8解码。不过从大多数开发者的实践来看，直接使用UTF-8是最稳定可靠的方式。

额外验证小技巧 #

你可以把GetAttachmentBytes返回的字节数组保存成一个临时文本文件，用记事本或VS Code打开时选择UTF-8编码，就能看到内容是否正常——这能直观确认字节确实是UTF-8格式的。

内容的提问来源于stack exchange，提问作者GSerg