libspotify：我可以用图像 ID 做什么和不能做什么？

Question

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

这些都以const byte* 的形式返回图像ID：

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，另一种具有表示从其他任何东西返回的图像 ID 的 IntPtr。如果库对图像 ID 的大小和性质做出了充分保证，我总是可以使用自己的缓冲区并在必要时复制到其中，但我担心 libspotify 不太可能做出足够强大的保证来允许这样做。

Answer 1

对于当前版本的 libSpotify，解释 C 对特定调用是正确的。由于它需要 byte[20]，因此该函数保证如果您分配 20 个字节，您将始终有足够的播放列表的图像 ID。如果该保证在未来发生变化，则函数签名将被更改，假设那时我们还没有让它像其他所有东西一样工作。

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

我希望您的项目进展顺利——我们多年来一直想要一个像样的 .NET 包装器，但一直没有时间自己完成整个事情。如果它是开源的，我很乐意贡献。