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，另一个具有表示从其他任何返回的图像ID的IntPtr。如果图书馆对图像ID的大小和性质做了充分的保证，我可以随时使用我自己的缓冲区并在必要时复制到其中，但是我担心看起来libspotify不太可能在任何地方靠近足够强的地方提供保证。

Answer 1

对于libSpotify的当前版本，解释C对于该特定调用是正确的。由于它占用了字节[20]，该功能保证了如果您分配了20个字节，则您将始终拥有足够的播放列表的图像ID。如果这种担保在未来发生变化，那么函数签名将会改变，假设我们尚未像其他所有事情那样工作。

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

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