问libspotify:对于图像ID，我能做什么，不能做什么？

EN

各种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:图像ID格式？的精确长度。

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。

我之所以感兴趣，是因为我试图编写一个比现有的.NET更安全、级别更高的libspotify.net包装器，而且我也不知道如何在托管代码中显示图像ID。我认为它唯一的特点是有两个替代的实现--一个具有一个20字节的缓冲区，表示从sp_playlist_get_image返回的图像ID，另一个带有一个代表其他任何东西返回的图像ID的IntPtr。如果库对图像ID的大小和性质提供了足够的保证，那么我总是可以使用自己的缓冲区，并在必要时将其复制到其中，但我担心libspotify不太可能提供足够强大的保证。