SharePoint 中的 SPFile.Properties != 何时变为 SPFile.Item.Properties？
我们的一位客户遇到了我们无法重现的问题。我们使用 SPFile.Properties 以编程方式将文档的属性复制到目标文件。但是，由于某种原因，文件的属性与存储文件的列表中指定的元数据不匹配。
现在，我们可能可以通过复制 SPFile.Item.Properties （尚未测试）来解决此问题，但我只是想知道什么情况下SPFile.Properties 不等于SPFile.Item.Properties。
更新：我们刚刚收到客户的更新。使用 SPFile.Item.Properties 始终返回最新信息。不过，我们仍然想了解原来的问题。
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
SPFile.Properties和SPFile.Item字段之间存在细微差别，第一个字段的调用速度要慢得多。您很可能见过 Microsoft Office 文档的“属性”窗口（此窗口 - http://dradisframework.org /images/tutorial/custom_document_properties.png）。这些是您访问
SPFile.Properties时读取的属性。读取它们的速度很慢，因为有一些代码基础结构可以解析二进制 DOC 文件并查找属性。 （每次属性访问最多需要 30 毫秒左右）请在此处查看更多信息：http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx在 SharePoint 中，每个项目都是一个
SPListItem及其字段值（这里我没有故意使用“属性”一词）存储在 Sharepoint 的内容数据库中。因此，当您访问SPFile.Item.Properties时，您实际上会查看该文件附加到的SPListItem并从 SharePoint 的内容数据库查看其属性。当您上传设置了某些“Office 属性”的文件时，幕后发生的情况是 SharePoint 会将它们复制到
SPListItem中的同名字段。 （有关它的一些信息在这里：http://weblogs.asp。 net/bsimser/archive/2004/11/22/267846.aspx）这就是为什么这些属性通常具有相同的值，但只有当 SharePoint 知道如何从文件中读取元数据并将其写回时才会发生这种情况。因此，如果您将
.txt文件放入 SharePoint 商店，您将不会得到任何SPFile.Properties。There is a slight difference between
SPFile.PropertiesandSPFile.Itemfields and the first one is much, much slower to call.You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access
SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspxIn SharePoint, every item is an
SPListItemand its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you accessSPFile.Item.Properties, you actually look at theSPListItemto which the file is attached and look at its properties from SharePoint's content database.What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in
SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a
.txtfile in your SharePoint store, you will not get anySPFile.Propertiesback.用户将始终在文档库中看到 ListItem 属性，而不是 SPFile 属性。因此，在副本中使用 ListItem 属性是正确的方法。
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
我相信这个问题与 Sharepoint 属性升级/降级功能有关，该功能使文档属性能够嵌入到物理 MSOffice 文件中并随其传输到客户端等。但是，目前仅支持 Office 文件类型（据我所知） 。
乔纳森
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
试图找到“官方记录”的任何共享点几乎是不可能的。 :-D。在线文档很糟糕，你最好使用博客文章等。
PS 我同意亚历克斯的观点。尽管 SPFile 在没有随附 SPListItem 的情况下永远不会存在于列表中，但两者之间的连接可能会损坏（即能够编辑列表项，但文件无法打开）。对我来说，这表明有关 2 的信息存储在内容数据库中的不同位置。我以前也遇到过这种情况。
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.