libspotify：对于图像ID，我可以做什么，不能做什么？

Question

各种libspotify API函数处理图像ID：

这些都会将图片ID返回为const byte*：

sp_album_cover
sp_artist_portrait
sp_artistbrowse_portrait
sp_image_image_id

sp_image_create将图片ID参数设为const byte[20]，而sp_playlist_get_image将图片ID参数设为byte[20]，并使用图片ID值填充。

在这个问题中，Spotify员工说图像ID的内容是不透明的，20的大小不一定是图像ID的准确长度：libspotify API: image ID format?

  

    

sp_image_create需要20个字节长的image_id参数。这是否意味着图像ID的最大长度是20个字节？

  

     

没有。 sp_subscribers是我们为编译器添加假号的另一个例子。图像id指针的内容是不透明的，并且可能在版本之间发生变化。不要编写对它们做出假设的代码，因为它会破坏。

但是，为了使用sp_playlist_get_image，调用者需要来分配数组以存储图像ID。这似乎是不一致的建议，或者至少是令人惊讶的。以下哪项是正确的？

• 解释A：图片ID总是正好是20个字节。
• 解释B ：图片ID可能长达20个字节。
• 解释C：图像ID可以是任意长度，但sp_playlist_get_image返回的图像ID保证不超过20个字节。
• 解读D：图片ID可能有任何长度，sp_playlist_get_image根本无法安全使用。

我认为链接问题的答案排除了A和可能B，所以我认为答案可能就是C，就像那样令人沮丧。完全悲观主义者可能会选择D。

我很感兴趣，因为我正在尝试编写比现有libspotify.net更安全，更高级的.NET包装器，而且我不确定如何在托管代码中显示图像ID。我认为唯一的问题是有两个替代实现 - 一个具有20字节缓冲区，表示从sp_playlist_get_image返回的图像ID，另一个具有IntPtr，表示从其他任何地方返回的图像ID。如果库对图像ID的大小和性质做了足够的保证，我总是可以使用自己的缓冲区并在必要时复制它，但是我担心libspotify看起来不太可能在任何接近强度的地方保证这一点。

Answer 1

对于当前版本的libSpotify，解释C 对于该特定呼叫是正确的。由于它需要字节[20]，该函数保证如果你分配20个字节，你将总是有足够的播放列表的图像ID。如果该保证将来发生变化，那么功能签名将会发生变化，假设我们当时没有像其他任何东西一样工作。

考虑到该API的状态，您的混合解决方案实际上听起来是最好的。当那令人讨厌的IntPtr消失时，使用sp_playlist_get_image可以更好地面向未来。

我希望你的项目顺利进行 - 我们多年来一直想要一个体面的.NET包装器，但我们自己从来没有时间做过整件事。如果它是开源的，我会很乐意做出贡献。