与桌面客户端相比，使用 ws.spotify.com/search 时的搜索结果不同

Question

在我未来的网站上，我尝试将作为字符串“Artist - TrackTitle”给出的曲目转换为相应的“spotify:track:trackCode”。

由于我在编写 PHP 方面比 javaScript 更快（请随意冷笑），所以我执行以下操作：

1. 清除 Spotify 搜索发现混淆的一些内容的字符串，例如括号中的内容、“`”、“/”、“-”等符号。
2. 将空格转换为 html 实体“%20”
3. 检索 spotify xml 页面“http://ws.spotify.com/search/1/track?q=”的结果和附加的字符串。
4. 如果有结果，则检索该页面中与正则表达式“(spotify:track:)(.*)(\">)”匹配的第一个匹配项

有趣的是，这仅适用于大约 80% 的所有字符串。尽管字符串的标准化程度相当高（它们来自无线电网站，瑞典语“Digilistan P3”），但有些搜索结果为 0。

可能的解决方案：

• A) 该曲目在 Spotify 上不可用。
• B) 曲目在 spotify 上可用，但 ws.spotify.com/search 上的搜索算法与桌面客户端不同。
• C) 搜索字符串没有为 url 版本或桌面客户端准备好

属于 B 组或 C 组的两首曲目（从不合适的字符中删除后）：

1. teddybears sthlm - 摇滚高中
2. bomfunk mc´s - b-boys & flygirls
3. 克里斯蒂娜·阿奎莱拉、mya、pink & lil´ kim - 女士果酱
4. macklemore & ryan lewis 壮举。 wanz - 旧货店（我的意思是：真的吗？你在开玩笑吗？甚至 ws.spotify.com/search/1/track?q=macklemore%20&thrift%20shop 都不提供任何强> 结果！）

现在的问题

任何人都可以提出更好的转换或想法，以提高我在为曲目找到合适匹配方面的成功率吗？

当前算法can be found here。

Answer 1

看来你需要逃避 &'s

http://ws.spotify.com/search/1/track?q=track:%22Thrift%20Shop%22+AND+artist:%22Macklemore%20%26%20Ryan%20Lewis%22

Answer 2

客户端和Web API中的搜索算法确实略有不同，但你也可能发现了一个bug。

Web API 使用全球流行度对搜索结果进行排名（根据实际搜索查询加权）。它还返回在任何国家/地区可用的东西。

客户端仅返回登录用户在该国家/地区可用的实体。它还使用登录用户所在国家/地区的受欢迎程度来对搜索结果进行排名。

根据这一点，以及唱片公司经常为具有不同权利的不同国家/地区发送完全相同专辑的不同副本这一事实将使搜索结果有所不同。我们最近在客户端的某些国家/地区也看到了一个错误。 https://twitter.com/swemoph/status/426260017847623680

因此，按照设计，它应该略有不同，但在您的情况下，它应该只意味着更多搜索结果的顺序略有不同，但绝不会为零。

2-4 可以用不转义 & 来解释。

1 号更有趣。查看 Web API 和开放站点中曲目的实际 uri，我们发现它被错误归因于 Teddybears（而不是 Teddybears Sthlm）：

$ curl -s 'http://ws.spotify.com/lookup/1/.json?uri=spotify:track:1JdC88rtMAwebQVFOcAg0D' | jq .track.artists [ { “名称”：“泰迪熊”， “href”：“spotify：艺术家：3gqv1kgivAc92KnUm4elKv” }, { “名称”：“托马斯·鲁西亚克”， “href”：“spotify：艺术家：7amcWVAeY8e6YwgV9bXlKH” } ]

http://open.spotify.com/track/1JdC88rtMAwebQVFOcAg0D 展示泰迪熊的摇滚高中

这清楚地解释了为什么您在 Web API 中找不到它。通过添加搜索词 sthlm，您将从结果中排除该曲目。查询引擎似乎按预期工作（尽管如果我们在这里允许更模糊的搜索，我会更喜欢，但这是一个不同的问题）。您没有做错任何事，但我们需要弄清楚为什么数据看起来不同。