各种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是另一个为编译器输入假数字的例子。image 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似乎不太可能提供足够强的保证来允许这样做。
对于libSpotify的当前版本，解释C对于该特定调用是正确的。因为它占用byte[20]，所以该函数保证如果您分配20个字节，您总是有足够的播放列表的图像ID。如果将来这个保证发生了变化，那么函数签名也会发生变化，假设到那时我们还没有使它像其他所有东西一样工作。
考虑到API的状态，你的混合解决方案现在听起来是最好的。当讨厌的sp_playlist_get_image消失时，尽可能使用IntPtr将更加适合未来。
我希望你的项目进展顺利——我们一直想要一个像样的。net包装器，但从来没有时间自己完成全部工作。如果它是开源的，我很乐意贡献。