【问题标题】:String Split Logic C#字符串拆分逻辑 C#
【发布时间】:2012-08-14 09:31:10
【问题描述】:

我有一个 REST 服务,它返回一个带有字符串的 JSON。该字符串是几个单词的聚合。组合这些字符串时,我使用“/”稍后将其拆分为分隔符。

例如:- 我得到的 json 字符串 - AAA/BBB/CCC(我正在从数据库中读取这些值)

在 UI 中,我将这个字符串从我引入的分隔符“/”中吐出,以提出业务逻辑。

我的问题是我引入的分隔符“/”是用户甚至可以输入的东西。因此,例如,如果用户也将“/”输入到其中一个字符串中,那么我的 JSON 将如下所示

e.g :- AAA/BBB/CC/C(/在用户输入两个 C 之后)

那么我的字符串拆分逻辑是错误的,因为我也使用相同的值来拆分字符串

处理此类问题的理想方式应该是什么。我正在使用 .NET C#

理想情况下,我想要一种方法来组合我的字符串并根据最终用户永远不会输入的内容拆分字符串

【问题讨论】:

  • 为什么你不能使用差异分隔符或限制用户进入你的分隔符?
  • 首先为什么要将组合字符串保存到数据库?有关 DB 范式的知识会很有用。
  • 是否有特殊原因无法从 JSON 返回对象?比如数组? ['AAA', 'BBB', 'CCC']?它应该很容易从 C# 生成,并且从 Javascript 中读取/生成也同样容易。
  • 或者你可以对它们进行 URL 编码..
  • 尝试另一种分隔符,例如“~”,这是一个不常用的分隔符。或者您可以尝试像这样的组合分隔符,例如“~/~”。

标签: c# string split


【解决方案1】:

一种选择是不将集合存储为标量值。您可以在数据库中使用一对多关系对其进行建模,或者您可以将集合序列化为 XML,并将其存储在单个列中。

【讨论】:

    【解决方案2】:

    请不要使用字符串来表示数组。您应该返回 JSON ['First', 'Second', 'Third', 'etc']。您可以使用任何 JSON 库从 C# 生成它(如果您使用 MVC3,您可以轻松地return Json(...) 一个数组)。

    就 Javascript 而言,您会得到一个可以轻松使用的数组。此外,将其发回应该很容易。

    【讨论】:

      【解决方案3】:

      而不是重新发明轮子,编写自己的序列化代码。为什么不使用标准 JSON 库为您进行序列化。

      JSON 已经迎合了数组或集合的概念,并且旨在转义其自己的分隔符。无需在某些标准 JSON 中间添加您自己的专有格式。

      This question 已经处理了 JSON 序列化器选择问题。


      只需将字符串作为IEnumerable<string> 存储在您的对象上。无论如何,它们可能会从您的数据模型中出来。

      【讨论】:

        【解决方案4】:

        在“/”之前添加一个“/”。额外的“/”很好地表明您应该将其作为字符而不是分隔标志来处理。您可以使用regex 进行拆分

        【讨论】:

        • 用户仍然可以在他们的字符串中输入'//'。我认为这不会解决问题。
        • 这很好撕成“////”,所以你知道它们都不是分裂标志。
        【解决方案5】:

        你可以做类似的事情,使用

        组合字符串

        字符串 S='AAA','BBB','CCC'

        比你可以写的代码更

        string[] ary=S.Replace("|","Pipe;").Replace("','","|").Split('|') ary[0] = ary[0].Replace("管道;","|")

        【讨论】:

        • 如果用户输入“,”或“Pipe;”会发生什么?
        • 取一个不能从键盘输入的分隔符,如 £
        • 它是英国和爱尔兰几乎所有键盘上的一个键,在美国国际键盘上,在大量其他键盘上,并且在大多数键盘上都有一些组合方式。即使它不在键盘上,如果用户必须努力复制粘贴才能写出 £ 而他们想写 £,他们会的。
        • 是的,最好使用$(开玩笑)。
        • 因为用户永远不会从多行的内容中复制粘贴?我认为 \u001F 是一个更安全的选择,但最好还是避免。
        【解决方案6】:

        如果您正在 POST 或 PUTting 这个字符串,那么根本不要像这样滚动您自己的编码。我们已经定义了 XML 和 JSON,虽然人们可能会无休止地争论它们的优缺点,但它们都可以工作,所以请使用其中之一。

        如果您在 URI 中使用此字符串进行 GET(当它自然是 GET 时这是一个更好的选择,如果不是,则更糟糕到容易出错的选择),那么 application/x-www-form- urlencoded 完全针对这种用途进行了明确定义:item=AAA&item=BBB&item=CCC&= 来自非 uri 编码,但任何 &=(以及任何其他在 URI 中受限制的字符)编码为正常方式(计算字符的 UTF-8 并在 % 之后添加每个八位字节的值,例如 =%3Dë%C3%AB 等等。

        如果你真的需要坚持你的基本方法,那么 U+001F 是一个控制字符,传统上用于在最低级别分隔字段(U+001E、U+001D 和 U+001C 越来越多地使用更高级别的分隔字段组)并且不会出现在大多数键盘上(任何书呆子和老派的人都可以设置键盘来键入它们,希望它们能够分隔字段)。如果可以避免的话,我不建议采用这种 1960 年代的方法来解决 2012 年的问题(尽管我认为美国的计算机仍然由约翰逊总统授权支持这些角色!)

        看在 Ada Lovelace 的份上,如果可以避免的话,不要将编码后的字符串存储在数据库中(除非在一个日志表中,它只是为了记录发送用于诊断目的的日志) .将单独的字段存储在数据库中,作为单独的字段。规范化是 1960 年代的一种方法,在 2012 年仍然适用

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2017-06-16
          • 2011-02-13
          • 2011-11-25
          • 2021-05-08
          相关资源
          最近更新 更多