あなたを怖がらせるコーディングの理由のために(私は言うには恥ずかしいです)、1つの文字列に多数のテキスト項目を保存する必要があります。
文字を使用して区切ります。
これに使用するのに最適な文字、つまりテキストに表示される可能性が最も低い文字はどれですか?ロケールの問題を回避するために、ASCII=で印刷可能かつおそらく128未満でなければなりません。
何らかの恥ずかしい理由で、CSVを使用できないと仮定して、データを使用するといいでしょう。いくつかのサンプルデータを取得し、値0〜127ごとに単純な文字カウントを実行します。発生しないものを選択してください。選択肢が多すぎる場合は、より大きなデータセットを取得します。書くのにそれほど時間はかからず、あなたに最適な答えが得られます。
答えは、問題のあるドメインごとに異なります。 (パイプ)はシェルスクリプトで一般的であり、^は数学式で一般的であり、他のほとんどの文字についても同様です。
個人的に私が行くと思う| (パイプ)選択が与えられたが、実際のデータを使用するのが最も安全です。
そして、あなたが何をするにしても、あなたが逃げるスキームを解決したことを確認してください!
おそらく|または^または〜2つの文字を組み合わせることもできます
「Unit Separator」を選択しますASCII code "US":ASCII 31(0x1F)
昔、ほとんどのことはランダムアクセスなしで連続して行われていました。これは、いくつかの制御コードがASCIIに埋め込まれたことを意味します。
ASCII 28 (0x1C) File Separator - Used to indicate separation between files on a data input stream.
ASCII 29 (0x1D) Group Separator - Used to indicate separation between tables on a data input stream (called groups back then).
ASCII 30 (0x1E) Record Separator - Used to indicate separation between records within a table (within a group). These roughly map to a Tuple in modern nomenclature.
ASCII 31 (0x1F) Unit Separator - Used to indicate separation between units within a record. The roughly map to fields in modern nomenclature.
Unit SeparatorはASCII形式であり、表示するためのUnicodeサポートがあります(通常、同じグリフの「us」)が、多くのフォントでは表示されません。
表示する必要がある場合は、フィールドに解析された後、アプリケーション内で表示することをお勧めします。
異なる言語を使用する場合、この記号:¬
最高であることが証明されました。しかし、私はまだテスト中です。
CSV形式のフォーマットを使用してはどうですか?文字は標準のCSV形式でエスケープできます。また、すでに多くのパーサーが記述されています。
「印刷可能」と言いましたが、タブ(0x09)やフォームフィード(0x0c)などの文字を含めることができます。カンマはテキストで表示されることがあるため、区切りファイルにはコンマではなくタブを選択することがほとんどです。
(興味深いことに、 ascii table には、グループ、レコード、およびユニットの区切り記号に、GS(0x1D)、RS(0x1E)、およびUS(0x1F)の文字があります。
「印刷可能」とは、ユーザーが認識して簡単に入力できる文字を意味する場合、パイプを選択します。可能性として、シンボルを最初に、他のいくつかの奇妙な文字(_@
_または_~
_または_^
_または_\
_、またはここに入力できないように見えるバックティックを使用します。これらの文字+=!$%&*()-'":;<>,.?/
は、ユーザー入力で発生する可能性が高いようです。アンダースコア__
_およびハッシュ_#
_およびブラケット_{}[]
_については、わかりません。
パイプ記号を使用できますか?これは通常、コンマまたはタブで区切られた文字列の次に最も一般的な区切り文字です。ほとんどのテキストにパイプが含まれている可能性は低く、ord( '|')は124を返すため、要件に適合するようです。
高速にエスケープするには、次のようなものを使用します。str1、str2、str3を連結したい場合は、次のようにします。
delimitedStr=str1.Replace("@","@a").Replace("|","@p")+"|"+str2.Replace("@","@a").Replace("|","@p")+"|"+str3.Replace("@","@a").Replace("|","@p");
元の使用を取得するには:
splitStr=delimitedStr.Split("|".ToCharArray());
str1=splitStr[0].Replace("@p","|").Replace("@a","@");
str2=splitStr[1].Replace("@p","|").Replace("@a","@");
str3=splitStr[2].Replace("@p","|").Replace("@a","@");
注:交換の順序は重要です
壊れず実装が簡単
これは状況や言語に応じて良い場合も悪い場合もあります(通常は悪い)が、常にBase64でエンコードできることに注意してください。そうすれば、それぞれの側でさまざまなパターンをエスケープしたりアンエスケープしたりすることを心配する必要がなくなり、Base64文字セットで使用されていない文字に基づいて文字列を単純に分離および分割できます。
XMLドキュメントをXMLプロパティ/ノードに配置することに直面したとき、私はこのソリューションに頼らなければなりませんでした。プロパティにはCDATAブロックを含めることはできません。また、CDATAは構造を壊さずにその中にCDATAブロックを追加できないため、ノードはエスケープされます。
ただし、ほとんどの場合、CSVはおそらくより良いアイデアです。
疑似印刷可能なascii 0x7fを使用し、通常の使用ではほとんど表示されません。
勝利のためのパイプ! |
おそらく何かを選択し、他の用途を無視する必要があります。
+
良い候補かもしれません。
まあ、それはある程度テキストの性質に依存しますが、垂直バー0x7Cはテキストに頻繁に現れません。
ASCIIを使用する必要があるかどうかはわかりませんが、UTF-8でエンコードできる場合は、次のような本当に不明瞭なシンボルを見つけることができます。 ╡
(U + 2561) -プログラムでよく使用します。
オブジェクトのシリアル化を調べて、必要なすべての要素の新しいフィールドを作成することもできます。
パイプとキャレットの両方が明らかな選択肢です。ユーザーが応答全体を入力する必要がある場合、キャレットはパイプよりもキーボードで簡単に見つけることができます。
自然なテキストでアンパサンドとそれに続くコンマを見たことはありませんが、最初にファイルをチェックして、区切り文字が含まれているかどうかを確認できます。使用する区切り文字が競合を引き起こさないことを常に認識できるようにする場合は、必要な区切り文字のファイルをチェックするループを実行し、存在する場合は、ファイルが一致しなくなるまで文字列を2倍にします。プログラムは完全に一致する区切り文字のみを検索するため、同様の文字列が存在するかどうかは関係ありません。