为什么ICalUid的长度不同
本文关键字：ICalUid 为什么 | 更新日期: 2024-10-21 06:23:40
我有一个应用程序，它使用EWS API跟踪Exchange中的约会。使用属性.ItemId是错误的，因为尽管它是唯一的，但它很可能会更改（Exchange web服务：为什么ItemId不是恒定的？[续]）。对于跟踪项目来说，这是一个糟糕的情况。因此，我使用属性Appointment.ICalUid.
这个属性看起来也不总是一样的，就我所见，它不知何故发生了变化。我记录了一些更改。首先用以下内容创建一个记录。ICalUID:
5fc22493-7212-4c44-9cd6-971c3bae28af
然后，下次我在Exchange中查找记录时，同一项会返回另一项。ICalUID:
040000008200E00074C5B7101A82E00800000000F01883C1D49AD101000000000000000010000000C321E8A40C6DE948836C422E2DA8610C
为什么一开始我会返回一个36个字符的字符串，后来又返回一个190个字符长的字符串？为什么这种价值观在改变？
编辑：短id是在使用连接到Exchange Server的Android手机时创建的，长id是在带有Outlook 2013的Windows 10上使用Outlook创建的。但它不知怎么变了？
这是因为iCal的RFC没有定义Uid的格式或长度https://www.rfc-editor.org/rfc/rfc5545只是它必须是全球独一无二的。这意味着它取决于实现者，例如有些人使用guid，有些人使用guid和域等。Exchange/Outlook使用GOID格式，特别是PidLidCleanGlobalObjectIdhttps://msdn.microsoft.com/en-us/library/office/cc839502.aspx和PidIdGlobalObjectIdhttps://msdn.microsoft.com/en-us/library/office/cc815676.aspx（通常由Exchange服务器在创建约会时生成）。
因此，您应该期望不同的格式，我通常建议您使用PidLidCleanGlobalObjectId扩展属性，而不是icaluid属性，因为这将始终返回一致性，因为它的集合Exchange永远不会更改此属性，在某些情况下，强类型属性可能不一致，如您所见。（作为一般规则，它应该返回GOID）。
干杯Glen