电商网站短编码需求：隐藏手机分类标识，相同原字符对应不同编码

针对你遇到的问题——既要生成短编码、隐藏URL中的品类标识（g/b前缀），又要避免固定字符映射（比如Base64的问题），这里有几个实用的方案，完全贴合你的需求：

方案1：带随机映射表的自定义字符替换 #

这个方案核心是用多组字符映射表，每次编码随机选择一组，让同一个原始字符（比如g）能对应不同的编码字符，同时保持编码长度和原始ID几乎一致。

实现步骤： #

1. 预设3-4组字符映射表，比如：
   • 表1：g→X, b→M, 0→a, 1→b, 2→c, ..., 9→j
   • 表2：g→Y, b→N, 0→k, 1→l, 2→m, ..., 9→t
   • 表3：g→Z, b→O, 0→u, 1→v, 2→w, ..., 9→z
2. 编码时，随机选一组映射表，把原始ID的每个字符替换成表中对应字符；同时把映射表编号（1-3） 隐蔽地加入编码——比如用编码最后一位的奇偶性表示（奇数对应表1，偶数对应表2，0对应表3），或者把编号转成字母（1→A、2→B）放在编码开头（伪装成编码的一部分）。
3. 解码时，先识别使用的映射表，再反向替换还原原始ID。

优点： #

• 编码长度和原始ID几乎一致（最多多1位），非常适合URL场景；
• 同一个原始字符（如g）每次编码会对应不同字符，用户无法通过编码规律判断品类；
• 实现简单，不需要复杂加密算法。

注意： #

• 要确保映射表的字符集无重复，避免解码歧义；
• 映射表编号的隐藏方式要自然，别让用户察觉到规律。

方案2：带碰撞检测的哈希截断 #

如果完全不想让编码和原始ID有任何关联，可以用哈希截断的方式，同时通过映射表避免碰撞问题。

实现步骤： #

1. 对原始ID（比如g1234）计算短哈希值，比如用SHA-1取前6位，或者用CRC32转换成8位字符；
2. 维护一张数据库表，记录编码→原始ID的对应关系，每次生成编码时检查是否已存在（碰撞）：
   • 如果不存在，直接使用该编码；
   • 如果存在，就取哈希值的下几位（比如前7位），直到找到唯一编码。
3. 解码时，通过映射表直接查找原始ID。

优点： #

• 编码完全无规律，用户绝对无法从编码判断品类；
• 编码长度短（6-8位），适配URL需求。

缺点： #

• 需要额外维护映射表，增加了数据库存储和查询的开销；
• 极端情况下可能需要多次尝试才能生成唯一编码，但概率极低。

方案3：前缀混淆+数字置换 #

这个方案针对你的ID格式（前缀+自增数字）做定制化混淆，既隐藏前缀，又打乱数字规律。

实现步骤： #

1. 把原始前缀g/b转换成随机字符（比如g可选A或B，b可选C或D，每次随机选一个）；
2. 对后面的自增数字做简单置换：比如反转数字（1234→4321）、交换奇偶位（1234→2143），或者加一个固定偏移量后取模10000（比如1234+123=1357）；
3. 把混淆后的前缀和数字拼接成最终编码。
4. 解码时，先根据混淆前缀反推原始前缀（A/B→g，C/D→b），再反向置换数字得到原始ID。

优点： #

• 编码长度和原始ID完全一致；
• 同一前缀每次编码对应不同字符，数字部分也无规律，用户无法判断品类；
• 不需要额外存储，解码逻辑简单。

注意： #

• 数字置换的规则要固定，确保解码能准确还原；
• 前缀的随机选择要均衡，避免某类字符出现频率过高。

总结 #

如果想要最简单的实现，优先选方案1或方案3；如果完全不在乎存储开销、想要绝对无规律的编码，选方案2。这三个方案都能满足你“短编码、隐藏品类、可变字符映射”的核心需求，而且都不需要使用冗长的加密算法。

内容的提问来源于stack exchange，提问作者yajiv