无法从条形码中识别字符串编码

Question

我的任务是使用iOS设备解码存储在Aztec条形码上的数据.我可以访问组装发送到条形码打印机的字符串的代码,但打印本身就是一个黑盒子.

当我逐步完成整个过程时,我可以看到发送到打印机的字符串看起来像这样(请注意,除了前8个字符之外,这是一个加密字符串):

_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

打印的条形码如下所示:

但是,当我使用通用的iOS条形码阅读器阅读它时(我已尝试了一些),我得到以下内容:

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?û

这与原始字符串(例如前几个字符)相似.但我不知道这是什么类型的编码,或者如何将其转换为我期望看到的十六进制代码.

我会很高兴知道:

1)我在这看什么？

2)如何将此字符串转换回原始格式？

Answer 1

注意:为清楚起见,您将其称为加密字符串,我将其称为十六进制代码,以进一步区分帖子末尾的随机字符串.

摘要

我相信你在字符串中看到的编码是一个拙劣的ASCII/ISO-8859-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 EE 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-1 ^2中未定义.因此,任何试图将这些字节解释为ASCII/ISO-8859-1字符串的应用程序都可能导致不可预测的行为.

如果您删除加密的十六进制代码从这些范围的字节,你基本上是³我,直到同样的事情E8字节.你拥有的字节E8是0F.我之前从未听说过这个控制代码,但显然它叫做"Shift In",其功能是"在Shift Out后返回常规字符集".由于我们已经遇到字符集问题,我只能假设这个控制代码负责E8字节后的解释错误.

编辑:您最近的一个编辑修改了字符串,它现在包含一些这些字符: .这是Unicode的替换字符,当出现字符编码问题时,或者进程无法解释特定字符时,该字符通常会替换其他字符.在这种情况下,它将替换00- 1F范围中的许多字节,即ASCII控件.它仍然无法恢复.本80- 9F范围仍然是省略.

更好的条形码阅读器

为了正确解释条形码,您需要一个不将十六进制代码解释为编码字符串的读取器,而是一个字节流.至少,你需要一个仍然保留00- 1F和80- 9F范围的阅读器.

我发现的一个这样的读者是NeoReader.您完全有可能已经尝试过,但复制粘贴可能会导致这些特殊代码范围出错.

我在iOS 7设备上用它扫描了代码,然后按下应用程序提供的"复制到剪贴板"按钮.然后,我将字符串粘贴在此转换器的顶部并点击转换.我通常将此转换器用于Unicode内容,但我找到的其他专用文本到十六进制转换器无法处理字符串及其特殊代码.如果向下滚动到"十六进制代码点",您应该能够看到所需的十六进制代码,尽管它们以额外的00⁴为前缀.

它产生的字符串(虽然带有一粒盐,我有一些复制粘贴错误,看起来特殊控件在发布时被删除):

600004 |]Iê÷ºÒÆA*×ImK \ZÊzjÆÕÐ÷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建议的那个字节.如下图所示,它在条形码的右下象限中放大(蓝线表示不编码数据的部分,它们用于帮助定位扫描仪).

在本视频教程的帮助下,我设法手动⁵解码条形码的那一部分.但是,您的条形码不使用此处显示的字符串编码方法,因为它使用二进制移位转义来处理8位值.从那里我相信一个< - > 差异是由于我的复制粘贴错误.0A0D

不幸的是,由于打印机对你来说是一个黑盒子,看起来好像你自己可以解决这个问题.

脚注

1. 我找不到Aztec Code规范,但行为似乎与默认值相对一致.

2. ISO-8859-1本质上是ASCII的超集,但它在技术上使ASCII控制代码范围未定义.这在实践中通常被忽略.

3. 唯一的区别是0A我有一个斜体字符,这是一个新的字符.你的字符串有0D另一个换行符.不同的系统以不同的方式处理新行,并且它们自动更改新行字符的情况并不少见.与大多数其他ASCII控制代码不同,新行字符通常得到很好的支持.

4. 原因很复杂.对一些细节进行着色,我相信在点击转换按钮时,它首先转换为UTF-16(Javascript的本机字符串编码).UTF-16中ASCII/ISO-8859-1字符的字节值相同.但是,UTF-16是16位编码而不是8位编码,因此,额外的00.

5. 那很痛苦.