代码之家  ›  专栏  ›  技术社区  ›  DVK

Unicode字符“”有什么特别之处,它打破了基于大括号的解析器逻辑?

  •  1
  • DVK  · 技术社区  · 5 年前

    • 它将数据结构编码为专有的序列化格式,该格式使用花括号对数据进行编码。下面是一个序列化字符串示例: {{9}{{8}{{skip_association}{{0}{}}}{{data}{{9}{{1}{{exceptions}{{9}{{1}{{-472926}{{9}{{1}{{AAAAAAYQ2}
    • 然后它将该序列化字符串发送到Java服务器
    • Java服务器尝试将字符串反序列化回数据结构。
    • {{id}{{7}9{Z928D2AA2}}} 表示名为“id”的字段,类型为“string”(7),长度为字符串9,值为Z928D2AA2。

    问题: 当被序列化的数据结构包含某些特定的Unicode字符时,反序列化失败。

    具体来说,这个字符:“(各种在线解码器显示为 %82 0x82

    我试图理解为什么这会是一个问题,以及这个字符有什么特别之处-还有其他Unicode字符不会破坏反序列化程序。

    (aka 0x82)Unicode字符有什么特别之处吗 这会干扰解析依赖于大括号作为分隔符和已知字段长度的序列化字符串吗?

    P.P.S加倍好奇:当我在SO问题的标题中使用那个字符时,它在预览中打印出来,但在问题发布时被删除了!!! 当我试图将字符串复制/粘贴到编辑器中时,与编码的字符串长度相比,它们的测量长度是正确的

    use open      qw(:std :utf8);    # undeclared streams in UTF-8
    use charnames qw(:full :short);  # unneeded in v5.16
    use Encode qw(decode);
    
    0 回复  |  直到 5 年前
        1
  •  3
  •   ysth    5 年前

    您可以在unicode字符数据库中查看有关字符的信息;可以在 https://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt 其中显示:

    0082;<control>;Cc;0;BN;;;;;N;BREAK PERMITTED HERE;;;;
    

    字段的含义可以在 http://www.unicode.org/reports/tr44/#UnicodeData.txt