Microsoft图形 API 为同一邮件返回了不同的线程 ID

Question

在我们的应用程序中，我们调用Microsoft图形API来获取电子邮件标头数据。 在最初调用 api 期间，我们收到了一封电子邮件的以下对话 ID 详细信息

{"conversationId":"AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk+h7byQ="}

几秒钟后，当我们对同一封电子邮件发出类似的请求时，我们收到了不同的 conversationId

{"conversationId":"AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk_h7byQ="}

现在，这里的期望是 conversationId 的值应始终保持不变。 在上述情况下，返回的 2 个 conversationId 中的唯一区别是"+"被替换为"_">

• AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk+h7byQ=
• AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk_h7byQ=

详细步骤：-

• owa mail dom 被解析以获取 conversationId

  AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk+h7byQ=

• 使用此 conversationId，我们调用 MS Graph API 并获取详细信息，包括我们作为主键存储在数据库中的 messageId
• 几分钟后，我们进行了另一次MS Graph API调用，这次使用messageId，作为响应，我们得到了一个不同的conversationId

  AAQkADVhMzU1YWY5LWVkNGQtNGZjOC1hMjJmLTk0MzIxMGQzMzRhMQAQAA8kZ_w6rdxIsHkFk_h7byQ=

问题：-

+ 和 _ 是否有可能

互换

Answer 1

不应假定 Exchange 标识符可以跨平台互换。多年来，Exchange已经使用了大量不同的标识符格式。这可能是问题的关键所在。

有一些机制可以在它们之间进行转换，但我通常建议不要这样做，除非您别无选择。

我不确定您为什么/如何解析 OWS DOM，但坦率地说，我更惊讶标识符比我更接近，它没有按预期工作。如果要从 OWA 中从 Graph 中提取消息，我会为此使用 Outlook Web 加载项。外接程序框架包含一个 convertToRestId 方法，该方法返回可用于 Microsoft Graph 的标识符：

function getItemRestId() {
if (Office.context.mailbox.diagnostics.hostName === 'OutlookIOS') {
// itemId is already REST-formatted
return Office.context.mailbox.item.itemId;
} else {
// Convert to an item ID for API v2.0
return Office.context.mailbox.convertToRestId(
Office.context.mailbox.item.itemId,
Office.MailboxEnums.RestVersion.v2_0
);
}
}

至于+vs_，这归结为编码格式。Base64有多种风格。标准 在标准 Base64 中，第 62 个字符是+的，第 63 个字符是/。 如果要在 URL 中使用 Base64 作为保留字符+并且/，这会带来问题。要解决此问题，您需要 Base64 的 URL 安全变体。那里有几种这样的变体。最常见的是base64url(在 RFC 4648 中定义)，它将-换成第 62 个，将_换成第 63 个。