纯文本db文件的最佳分隔符/分隔符是什么？

问题描述

|                                                                                                                   关闭。这个问题是基于意见的。它当前不接受答案。                                                      

解决方法

        无论选择哪个字符作为分隔符，您都希望在数据中转义该字符的任何实例。 也许是tilde（

~

），或转到高ASCII字符。 无论哪种方式，如果有可能它会潜入您的数据中，您都希望在写入纯文本文件之前对其进行转义。     ,        我认为最好的方法是用三个樱桃\'@@@ \'连接字符串。     ,        嗯，US-ASCII中的分隔符很少，十六进制为

1c

，

1d

，

1e

和

1f

。纯文本不应包含它们。

1c  FS  ␜  ^\\  File Separator
1d  GS  ␝  ^]  Group Separator
1e  RS  ␞  ^^  Record Separator
1f  US  ␟  ^_  Unit Separator

    ,        对于特定的数据仓库情况，我们可以控制源文件，但是转义和限定很繁琐，我们可以做出业务决策，即从数据中剥离一个扩展的ASCII字符（如果曾经发生过，那么就已经没有了）。 \）。 创建带分隔符的源文件时，我们删除了数据中的任何█实例（alt + 219），并将该字符用作分隔符。 另外，这个角色真的很容易发现。     ,        我个人喜欢使用«作为分隔符来分割CSV文件中的数据，我个人认为我还没有找到自然发生的«和»实例，所以这里有两分钱。     ,        您可以使用特殊的分隔符（十六进制1c-> 1f），但它们不可打印，并且某些技术在处理包含它们的数据时遇到问题。 因此，对于计划B，如果您的数据使用UTF-8，则可以选择一个随机的UTF-8字符，该字符极不可能出现在收到的任何源数据中。 但是，即使那样，如果要确保不会遇到问题，最好还是在整个数据集中扫描该字符，如果出现该字符，只需选择另一个UTF-8字符。 我倾向于对封装充满热情，并尽可能避免使用封装，如我在“封装”一章中的帖子中所述：https://theonemanitdepartment.wordpress.com/2014/12/15/the-absolute-最少每个人都必须绝对肯定要知道关于文件类型编码定界符和数据类型的数据的借口/     ,        我通常更喜欢不可打印的字符，例如\“ \\ u0001 \”，例如，在大多数Azure Data Analytics U-SQL脚本中，我将其用作列定界符。假设您可以使用多字符自定义定界符     ,        实际上，这取决于您要分离的数据类型，我们需要一个用于机器事件数据的分隔符，并提出了两个建议：

=)

或

^_^

。 我们选择

^_^

是因为它实际上根据测试的样本数起作用，而且看起来也很可爱！     ,        如果您可以选择使用字符串作为列分隔符，请使用\“ \”作为分隔符。您可以为此编写任何字符串，并为您提供灵活性。     ,        如果您无法控制放入其中的数据，请不要使用纯文本数据库。此处通常没有正确的答案。没有上下文或约束，这是一个错误的问题。 以机智： 如果我说我只接受小写字母作为数据，则可以使用任何其他符号作为分隔符。即使是9，我也很好。除小写字符外，没有其他符号比其他任何符号都更好。 相反，如果说我可以接受任何字符，那么我将没有任何字符可用于分隔符，而我会留下一个非常遗憾的数据库，该数据库只能存储一个值。 如果您必须尽力使数据库成为纯文本，则可能需要二进制数据库。你看过sqlite吗？它非常简单易用，可在许多情况下使用，并且比纯文本数据库具有很多优势。     ,        我以前使用过ePUB转换器，而定界符char是符号引号字符，在使用该字符的任何位置，都将其重写为@，即使它确实破坏了所生成的示例材料，也很简单但有效。     ,        我建议使用interrobang字符“‽”。更多详细信息：https://en.wikipedia.org/wiki/Interrobang