注意：为了清楚起见，您所说的加密字符串，我将称为十六进制代码，以进一步区分您帖子末尾的随机字符串。
总结
我相信您在字符串中看到的编码是错误的 ASCII/ISO-8859-1 编码。它省略了一些字符，因此无法从该字符串中恢复原始十六进制代码。找到可以正确处理条形码的扫描仪后，发现条形码与您的十六进制代码不匹配。
编码
Wikipedia says 默认情况下1，Aztec 中的字节码在 0 到 127 之间时被解释为 ASCII，在 128 到 255 之间时被解释为 ISO-8859-1。所以当你替换字母和您从这两种编码中获得正确的十六进制值的符号，您会得到以下信息：
36 30 30 30 30 34 7C 5D 49 EA F7 BA D2 C6 C2 41 2A D7 49 6D 4B 5C 5A CA 7A 6A C6 D5 D0 6C F7 20 76 5B E0 46 7E 2A 30 0A 3A E5 66 7C F9 DF F1 45 A5 4A 6E 2F 3F F0 BC 3E 77 5B 27 58 DF 55 37 4C AE E7 C3 C6 5B 57 DB 7C 2D 2C E3 A4 44 C4 BA 6A C6 AE 2D 20 6E E8 50 D0 6B 5E A1 B1 78 4F 53 35 B7 D3 FE DF E1 D7 44 A2 5C
这类似于您的加密十六进制代码，但省略了一些字节，加粗的 E8 字节后面的内容不同。省略的字节都来自00 - 1F 和80 - 9F 范围。 ASCII 中的00 - 1F 范围是控制代码，其中大部分很少使用，并且许多应用程序都没有很好地支持。另一个范围在 ISO-8859-12 中未定义。因此，任何试图将这些字节解释为 ASCII/ISO-8859-1 字符串的应用程序都可能导致不可预知的行为。
如果您在加密的十六进制代码中从这些范围中删除字节，您基本上会得到3与我得到的相同的东西，直到 E8 字节。 E8 之后的字节是 0F。我以前从未听说过这个控制代码，但是apparently 它被称为“Shift In”，它的功能是“Shift Out 后返回常规字符集”。由于我们已经遇到了字符集的问题，我只能假设这个控制代码负责E8 字节之后的解释错误。
编辑：您最近的一项编辑修改了字符串，现在它包含以下几个字符：�。这是 Unicode 的替换字符，当出现字符编码问题或进程无法解释特定字符时，该字符通常会替换其他字符。在这种情况下，它将替换 00 - 1F 范围内的许多字节，这些字节是 ASCII 控件。仍然无法恢复。 80 - 9F 范围仍然被省略。
更好的条码阅读器
为了正确解释条形码，您需要一个不会将十六进制代码解释为编码字符串，而是解释为字节流的阅读器。至少，您需要一个仍能保留 00 - 1F 和 80 - 9F 范围的阅读器。
我发现一个这样的读者是NeoReader。您完全有可能已经尝试过，但是复制粘贴可能会导致这些特殊代码范围出现错误。
我在 iOS 7 设备上用它扫描了代码，然后点击了应用程序提供的“复制到剪贴板”按钮。然后，我将字符串粘贴到this converter 的顶部并点击转换。我通常将此转换器用于 Unicode 内容，但我发现的其他专用文本到十六进制转换器无法处理字符串及其特殊代码。如果向下滚动到“十六进制代码点”，您应该能够看到所需的十六进制代码，尽管它们的前缀是额外的 004。
它产生的字符串（虽然用一粒盐，但我有一些复制粘贴错误，并且在发布时似乎删除了特殊控件）：
600004|]I ê÷ºÒÆÂA*×ImK\ZÊzjÆÕÐl÷ v[àF~*0
:åf|ùßñE¥Jn/?ð¼>w[' XßU7L®çãÆ[WÛ|-,ã¤DĺjÆ®- nèPÐk^¡±xOS5·Óþßá×D¢\¥ö>¡¡ôQJÄÂ[ºED+³Â[ºED+ ³Â[ºED+³Â[ºED+³Â[ºED+³Â[ºED+³ uû
十六进制代码比较（差异用< >标记）：
Your hex code: 36 30 30 30 30 34 7C 5D 49 0B EA F7 93 BA 89 D2 C6 C2 41 2A D7 1C 49 8C 6D 4B 5C 07 5A CA 7A 6A C6 D5 D0 6C F7 20 76 5B E0 18 46 93 7E 2A 30 <0D> 14 3A 1A E5 66 7C 05 F9 DF 96 8A F1 45 A5 4A 6E 2F 89 3F F0 93 1F BC 3E 77 5B 27 0C 58 DF 55 37 4C AE 8A E7 C3 C6 16 5B 57 DB 7C 2D 2C 8B 1C E3 A4 44 1B C4 BA 6A C6 98 93 AE 2D 20 6E 9F E8 0F <EB BC 9F 2E 8A E7 CF DA 22 96 E1 74 DE B2 F0 29 EC B1 C1 75 43 1F B2 E5> 1F A5 F6 06 3E 97 A1 A1 93 F4 51 4A C4 14 9F 1A C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 06 0B 12 75 85 8B 07 FB
NeoReader string: 36 30 30 30 30 34 7C 5D 49 0B EA F7 93 BA 89 D2 C6 C2 41 2A D7 1C 49 8C 6D 4B 5C 07 5A CA 7A 6A C6 D5 D0 6C F7 20 76 5B E0 18 46 93 7E 2A 30 <0A> 14 3A 1A E5 66 7C 05 F9 DF 96 8A F1 45 A5 4A 6E 2F 89 3F F0 93 1F BC 3E 77 5B 27 0C 58 DF 55 37 4C AE 8A E7 C3 C6 16 5B 57 DB 7C 2D 2C 8B 1C E3 A4 44 1B C4 BA 6A C6 98 93 AE 2D 20 6E 9F E8 0F <81 50 D0 6B 5E A1 B1 78 4F 53 35 B7 D3 FE 1F DF E1 90 D7 44 A2 5C 00 19> 1F A5 F6 06 3E 97 A1 A1 93 F4 51 4A C4 14 9F 1A C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 06 0B 12 75 85 8B 07 FB
区别解释
事实证明，条形码实际上与您的十六进制代码不匹配。在我们的两个代码不同的地方，在那个0F 字节处，条形码实际上遵循了 NeoReader 的建议。如下图所示，放大了条码的右下角（蓝线表示不编码数据的部分，它们用于帮助定位扫描仪）。
在this video tutorial 的帮助下，我设法手动5 解码那部分条码。但是，您的条形码不使用此处显示的字符串编码方法，因为它使用 binary shift escape 处理 8 位值。从那里我相信0A 0D 的区别是由于我的复制粘贴错误。
很遗憾，由于打印机对您来说是一个黑匣子，因此您似乎无法自己解决此问题。
脚注
我找不到阿兹特克代码规范，但行为似乎与默认值相对一致。
ISO-8859-1 本质上是 ASCII 的超集，但它在技术上未定义 ASCII 控制代码范围。这在实践中通常被忽略。
唯一的区别是我有斜体0A 字符，它是一个换行符。你的字符串有0D，另一个换行符。不同的系统以不同的方式处理换行符，自动更改换行符的情况并不少见。与大多数其他 ASCII 控制代码不同，换行符通常得到很好的支持。
原因很复杂。忽略一些细节，我相信在点击转换按钮后，它首先被转换为 UTF-16（Javascript 的本机字符串编码）。 ASCII/ISO-8859-1 字符的字节值在 UTF-16 中是相同的。但是，UTF-16 是 16 位编码而不是 8 位编码，因此，额外的00。
那很痛苦。