平文のdbファイルに最適な区切り文字/区切り文字は何ですか？
平文のdbファイルに最適な区切り文字/区切り文字は何ですか？
|、,、<TAB>、;など。しかし、近くのエントリに特別な十分な文字がある場合、それらはすべて壊れる可能性があるようです。
それでは、経験豊富なデータベースユーザーは、どの区切り文字を使用することをお勧めしますか？
セパレータとしてどの文字を選択しても、データ内のその文字のインスタンスはすべてエスケープする必要があります。
おそらくチルダ（~）、または高ASCII文字に移動します。
いずれにせよ、データに潜入する可能性がある場合は、プレーンテキストファイルに書き込む前にエスケープする必要があります。
文字列を3つのチェリー「@@@」で結合する最良の方法だと思います。
さて、区切り文字はほとんどありません文字 US-ASCIIでは、16進数1c、1d、1eおよび1f。プレーンテキストにそれらを含めることはできません。
1c FS ␜ ^\ File Separator
1d GS ␝ ^] Group Separator
1e RS ␞ ^^ Record Separator
1f US ␟ ^_ Unit Separator
特定のデータウェアハウスの状況では、ソースファイルを制御できたが、エスケープと修飾が面倒だったため、拡張された1つのASCII文字がデータから削除されるというビジネス上の決定を行うことができました。 （発生した場合は発生しません）。
区切られたソースファイルの作成時に、データ内の█（alt + 219）のインスタンスをすべて取り除き、その文字を区切り文字に使用しました。ボーナス、そのキャラクターは本当に見つけやすいです。
個人的には"を区切り文字として使用してCSVファイルのデータを分割するのが好きです。個人的に"と"の自然発生するインスタンスを見つけたとは思わないので、ここに2セントを示します。
特殊な区切り文字（16進数1c-> 1f）を使用できますが、それらは印刷できません。また、一部の技術には、それらを含むデータの処理に問題があります。
したがって、プランBでは、データがUTF-8の場合、どのソースにも表示されないextremelyであるランダムなUTF-8文字を選択できますあなたが受け取るデータ。
それでも、問題が発生しないことを確認したい場合は、常にデータセット全体でこの文字をスキャンし、表示された場合は別のUTF-8文字を選択することをお勧めします。
ここでの「カプセル化」の章の下の私の投稿で説明されているように、私は情熱を持ってカプセル化を嫌い、それを可能な限り避けます： https://theonemanitdepartment.wordpress.com/2014/12/15/the-データの絶対的で絶対的に確実な絶対的な最小の作業-ファイルの種類-エンコーディング-デリミタとデータの種類-excuses /
私は通常、「\ u0001」などの印刷できない文字を好みます。たとえば、ほとんどのAzure Data Analytics U-SQLスクリプトでこれを列区切り文字として使用します。これは、複数文字のカスタム区切り文字を使用できることを前提としています
列セパレータとして文字列のオプションがある場合は、区切り文字として「」を使用します。そのために任意の文字列を作成でき、柔軟性が得られます。
以前にePUBコンバーターを使用したことがあり、区切り文字は表記上の引用文字でした。使用された場所はどこでも@としてファイルに書き換えられ、作成されたサンプルマテリアルを破壊したとしても効果的です。
挿入するデータを制御できない場合は、プレーンテキストデータベースを使用しないでください。ここには一般的に正しい答えはありません。コンテキストや制約がなければ、これは誤った質問です。
言い方をすれば、データとして小文字のみを受け入れると言った場合、セパレータとして他の記号を使用できます。数字の9でも、私は大丈夫でしょう。小文字以外の記号は他のどの記号よりも優れていません。
逆に、文字を受け入れることができると言われた場合、セパレータ用の文字は残っておらず、単一の値しか保存できない非常に残念なデータベースが残されます。
データベースをプレーンテキストに変換するために一生懸命努力する必要がある場合は、おそらくバイナリデータベースが必要です。 sqliteを見たことがありますか？使い方は非常に簡単で、多くのコンテキストで利用でき、プレーンテキストデータベースよりも多くの利点があります。