1

各种 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 可以是任意长度，但返回的图像 IDsp_playlist_get_image保证不超过 20 个字节。
  • 解释 D：图像 ID 可能是任意长度，sp_playlist_get_image根本无法安全使用。

我认为链接问题的答案排除了 A 和可能的 B，所以我认为答案可能是 C，尽管如此令人沮丧。一个彻头彻尾的悲观主义者可能会选择 D。

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

4

1 回答 1

3

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

考虑到该 API 的状态，您的混合解决方案实际上听起来是目前最好的。当这种讨厌的事情消失IntPtr时，在你可以使用的地方使用将更具前瞻性。sp_playlist_get_image

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

于 2013-01-04T12:07:32.120 回答