示范

const { body } = Office.context.mailbox.item;
const coercionType = Office.CoercionType.Html;

// First, let's get the current body of the mailbox item.
body.getAsync(coercionType, {}, (firstResult) => {
  const previousBodyHtml = firstResult.value;

  // Now, let's set the body to the value we received.
  body.setAsync(previousBodyHtml, { coercionType }, () => {

    // Now, let's get the body again.
    body.getAsync(coercionType, {}, (secondResult) => {
      const nextBodyHtml = secondResult.value;

      // The values do not match.
      console.error(previousBodyHtml, 'does not equal', nextBodyHtml);
    });
  });
});

Body#setAsync不是像预期的那样是幂等的，而是经过相当多的过滤。

观察到的行为

带有id或class属性的HTML字符串中的任何元素都具有该属性的前缀为x_的值。
- 从Body#getAsync返回的字符串中的某些元素包括id和class属性，这些属性似乎对Outlook（以及我们的加载项）具有语义含义。受影响的元素包括引用的回复，签名和正文HTML本身的包装元素的指示符。在设置身体时，这些指示器会被控制。
- 如果受影响的属性已经有x_前缀，则Outlook会添加另一个。因此，每次加载项设置正文时，这些属性值都可以增长到具有相当数量的x_前缀（例如：x_x_x_x_x_x_x_x_x_x_divtagdefaultwrapper）。
从Body#getAsync返回的值可能包含带有数据URI的图像（在Office 365中也是如此）。 Body#setAsync会导致清除这些图像的src属性，从而导致图像以损坏的图像显示给用户。
- 正文中的图片永远不应该有数据URI - 大多数电子邮件客户端都不会使用数据URI呈现内联图像;它们在那些电子邮件中显示为损坏的图像。
  - Outlook使用代理图片的src属性呈现大多数内联图片，并使用 cid： URI的originalsrc属性引用电子邮件中的附件相应的Content-ID标题。这似乎是合理的。

我们在开发加载项时发现的是，在实践中，Body#setAsync期望接收一个HTML字符串，表示里面内部第一个元素{{1} Office 365中的 divtagdefaultwrapper 的属性，或Outlook 2016中具有类 WordSection1 的第一个元素。

解决方法

因此，要解决此问题，在调用id时，必须首先将字符串和rebase解析为相应的根元素，然后才能通过Body#getAsync持久保存对正文所做的任何更改。我们最终还必须从正文中的元素中删除所有Body#setAsync和id属性，添加我们自己的标记元素以标记正文中语义上重要的部分（引用的回复，签名等），并实现我们自己的数据URI所遇到的图像代理。

Answer 1

由于Word渲染引擎的限制，我们无法保证body.getAsync和body.setAsync是幂等的。您在Office 365中看到的使用数据URI的正文中的内嵌图像的问题是我们正在研究的已知问题。

Body＃setAsync munges从Body＃getAsync

示范

观察到的行为

解决方法

1 个答案: