字符串加密 - 生成独特的模式，如 Spotify 代码

Question

昨天我阅读了问题Algorithm to create costum Template/Code from String。因为这个问题没有很好地表达出来，所以它立刻就被否决了。然而，我认为这个问题本身并没有那么糟糕，所以我决定再次提出这个问题的更好版本。

好的，我想知道新 Spotify 代码的字符串加密是如何工作的。见下图：

我对在 javascript 中实现这种模式加密的可能性的程度非常感兴趣。

Spotify 代码 -我已经在上面提到过-排列成一行，分为不同大小的条。

因此，假设有一行被分为 24 个条形，并且所有条形的大小都可以是“3”、“5”、“7”或“9”。

 string = 'hello'   -->  pattern = '3,3,5,7,9,3,7,9,9,3,3,5,3,9,5,3,3,7,5,9,3,9,3,9'

什么是将字符串（比如 5 个字符）转换为独特模式的好方法/简单方法，然后也可以转换回来并作为字符串读取？

这是我迄今为止开发的代码，但在此代码中，我使用了一个包含 10 种不同可能性（--> 条大小）的键数组，但我只喜欢我们 4 种不同的大小。

---

解释：

我将我的字符串 'hello' 转换为二进制格式，并将该字符串分成最多 3 个的组以获得如下内容：['001', '110', '0']。

之后我使用上面的结果数组并在下面的键数组中找到匹配项并获取索引（10 种不同的索引 --> 10 种不同的可能性）并将它们用作条形大小。

但是，必须有一种更有效的方法将字符串转换为独特的模式。我希望有人可以帮助我改进我的小算法。预先感谢一百万。

 string = 'hello'   -->  pattern = '3,3,5,7,9,3,7,9,9,3,3,5,3,9,5,3,3,7,5,9,3,9,3,9'

Answer 1

您似乎假设存在从字符串“Coffee”到显示的图形的直接映射。这个假设几乎肯定是不正确的。

首先，考虑如果有两首不同的歌曲“Coffee”会发生什么。您提出的算法将为它们分配相同的代码。这似乎不合理。您希望代码能够唯一标识这首歌曲。

其次，歌曲名称可以任意长。例如，平克·弗洛伊德 (Pink Floyd) 的一首歌曲名为“几种毛茸茸的小动物聚集在一个洞穴中，并用图片进行勾勒”。您的编码算法可能无法将其放入 24 个条中。即使可以，我总能找到更长的歌名。

给定字母 az，有 11,881,376 种可能的 5 字符字符串。如果您只想对所有可能的情况进行唯一编码，只需 23 位即可实现。只需将字符串视为以 26 为基数的数字并进行转换即可。

最有可能的是，Spotify 为每首歌曲分配了一个唯一的编号，然后对该编号进行编码。字符串“Coffee”和您在屏幕上看到的图形代码之间没有直接映射。

Answer 2

更新：我问了一个类似的问题，有人回答了这个条形码的专利。总而言之，他们使用中间查找表将条形码链接到唯一的 Spotify ID。

我一直在深入研究 Spotify 代码，以尝试理解它们。

Spotify 有每首歌曲、专辑、艺术家、用户、播放列表等的 URI。它们看起来像这样：

spotify:playlist:37i9dQZF1DXcBWIGoYBM5M

如果您访问Spotify 代码，您可以从 URI 生成代码。上述 URI 的代码如下所示：

正如您所指出的，他们在每个条的高度中对信息进行编码，与美国邮政服务在其条形码中的编码方式相同（请参阅智能邮件条形码）。

Spotify Codes 中的条形图有 8 种不同的高度。徽标是最大高度，第一个和最后一个条形始终是最低高度。在上图中，最大高度为 96 像素，条形分为 8 个不同的高度箱：[96, 84, 74, 62, 52, 40, 28, 18].

使用这个（有点凌乱的 Python）代码，我可以从条形码图像中获取八进制序列：

from skimage import io
from skimage.filters import threshold_otsu
from skimage.measure import label, regionprops
from skimage.morphology import square
from skimage.color import label2rgb, rgb2gray

def get_sequence(filename):
    image = io.imread(filename)
    image = rgb2gray(image)
    b_and_w = image > threshold_otsu(image)
    labeled = label(b_and_w)
    bar_dims = [r.bbox for r in regionprops(labeled)]
    bar_dims.sort(key=lambda x: x[1], reverse=False)
    spotify_logo = bar_dims[0]
    max_height = spotify_logo[2] - spotify_logo[0]
    sequence = []
    for bar in bar_dims[1:]:
        height = bar[2] - bar[0]
        ratio = height / max_height
        if ratio < 0.25:
            sequence.append(0)
        elif ratio < 0.33:
            sequence.append(1)
        elif ratio < 0.46:
            sequence.append(2)
        elif ratio < 0.5625:
            sequence.append(3)
        elif ratio < 0.677:
            sequence.append(4)
        elif ratio < 0.8:
            sequence.append(5)
        elif ratio < 0.9:
            sequence.append(6)
        elif ratio < 1.1:
            sequence.append(7)
        else:
            raise ValueError('ratio is too high')
    return sequence

序列映射如下： 37i9dQZF1DXcBWIGoYBM5M -> [0, 6, 0, 2, 4, 5, 1, 4, 5, 2, 3, 7, 3, 7, 1, 5, 6, 2, 5, 7, 4, 3, 0]

奇怪的是，URI 中的信息量与 Spotify 代码不匹配。URI 的长度为 22 个字符，包含0-9 a-z A-Z. 这意味着62^22潜在的 URI，或2.7 e39. Spotify 代码中有 23 个柱，但第一个和最后一个始终为 0，因此只有 21 个可用柱。这意味着8^21或9.22 e18潜在的代码。URI 到代码的映射并不简单，因为没有 1 个代码到 1 个 URI。

我不知道他们如何将 URI 映射到代码。我的猜测是他们有一个单独的数据库/查找表，用于将代码映射到 URI。在创建代码时，他们将 URI 散列到一个代码中，然后将其存储以供日后查找。当有人查找代码时，他们会检查该数据库并将其映射到 URI。由于有更多潜在的 URI，它们只是永远不会被使用，也不必担心它们。