単純な「はい」または「いいえ」の質問です。90%は「いいえ」と確信しています...しかし、よくわかりません。
Base64文字列にタブを含めることはできますか?
それはあなたが何を求めているかによります。タブをbase-64でエンコードできるかどうかを尋ねる場合、他のASCII文字と同じように扱うことができるため、答えは「はい」です。
ただし、base-64出力にタブを含めることができるかどうかを尋ねる場合、答えはノーです。次のリンクは、base-64の詳細を示す記事で、有効と見なされる文字が含まれています。
簡単な答えはノーですが、Base64にはキャリッジリターンを含めることもできません。
そのため、Base64の行が複数ある場合は、キャリッジリターン、ラインフィード、およびBase64アルファベットに含まれていないその他のものをすべて削除します。
これにはタブが含まれます。
PEM の現在のバージョン (RFC 1421 で指定) では、大文字と小文字のローマ字アルファベット (A ~ Z、a ~ z)、数字 (0 ~ 9)、および "+ " および "/" 記号。「=」記号は、特殊なサフィックス コードとしても使用されます。元の仕様である RFC 989 では、さらに "*" 記号を使用して、出力ストリーム内のエンコードされたが暗号化されていないデータを区切りました。
ご覧のとおり、タブ文字は含まれていません。ただし、もちろん、タブ文字を base64 文字列にエンコードできます。
もちろん。TabはASCII文字9であり、他の整数と同じようにbase64表現を持っています。
Base64 仕様 ( RFC 4648 ) のセクション 3.3では、別の仕様で明示的に許可されていない限り、検出されたアルファベット以外の文字は拒否されるべきであると述べられています。
実装は、このドキュメントを参照する仕様で明示的に別段の記載がない限り、
ベース エンコードされたデータを解釈するときにベース アルファベット以外の文字が含まれている場合、エンコードされたデータを拒否する必要があります。
そのような仕様では、代わりに、MIME と同様に、データを解釈するときにベース エンコーディング アルファベットの外にある文字は単純に無視されるべきであると述べている場合があります (「受け入れるものには寛容であれ」)。これは、隣接するキャリッジ リターン/ライン フィード (CRLF) 文字が「非アルファベット文字」を構成し、無視されることを意味することに注意してください。
PEM ( RFC 1421 ) や MIME ( RFC 2045 ) などの仕様では、Base64 文字列を空白で分割できることが指定されています。参照されているRFC 822に従って、タブ (HTAB) は空白文字と見なされます。
そのため、Base64 が MIME または PEM (およびおそらく他の同様の仕様) のコンテキストで使用される場合、エンコードされたコンテンツをデコードする際に、タブを含む空白を処理 (削除) する必要があります。
ハハ、回答からわかるように、これは実際にはそれほど単純なはい、いいえの答えではありません。
変換後の結果のBase64文字列にはタブ文字を含めることはできませんが、それを求めていないように思えますが、Base64でタブを含む文字列(変換前)を表すことができるかどうかを尋ねているようです.そうです。
ただし、実際にすべきことは、文字列のエンコーディングを保持するように注意することです。つまり、正しいエンコーディング(Unicode、UTF-8など)でバイト配列に変換してから、その配列を変換しますバイトを base64 に変換します。
編集:簡単なテスト。
private void button2_Click(object sender, EventArgs e)
{
StringBuilder sb = new StringBuilder();
string test = "The rain in spain falls \t mainly on the plain";
sb.AppendLine(test);
UTF8Encoding enc = new UTF8Encoding();
byte[] b = enc.GetBytes(test);
string cvtd = Convert.ToBase64String(b);
sb.AppendLine(cvtd);
byte[] c = Convert.FromBase64String(cvtd);
string backAgain = enc.GetString(c);
sb.AppendLine(backAgain);
MessageBox.Show(sb.ToString());
}
Convert.FromBase64String()
.NETフレームワークではそれらを気にしないようです。文字列内のすべての空白は無視されると思います。
string xxx = "ABCD\tDEFG"; //simulated Base64 encoded string w/added tab
Console.WriteLine(xxx);
byte[] xx = Convert.FromBase64String(xxx); // convert string back to binary
Console.WriteLine(BitConverter.ToString(xx));
出力:
ABCD DEFG
00-10-83-0C-41-46
RFC-2045の関連条項(6:8)
エンコードされた出力ストリームは、それぞれ76文字以内の行で表す必要があります。 表1にないすべての改行またはその他の文字は、デコードソフトウェアで無視する必要があります。base64データでは、表1以外の文字、改行、およびその他の空白は、送信エラーを示している可能性があります。状況によっては、警告メッセージまたはメッセージ拒否が適切な場合があります。
ここには多くの混乱があるようです。驚くべきことに、ほとんどの回答は「いいえ」です。それは良い標準的な答えだとは思いません。混乱の理由は、おそらく Base64 が厳密に指定されていないという事実です。複数の実用的な実装と解釈が存在します。これに関する詳細については、リンク テキストを参照してください。
ただし、一般に、準拠している base64 コーデックは、いくつかの base64 定義 (76 文字のセグメント、次に改行など) によって義務付けられているため、改行を理解する必要があります。このため、ほとんどのデコーダーは、インデントの空白と、4 文字の「トリプレット」の間の空白を許可します (3 バイトをエンコードするため、このように命名されています)。
そのため、実際にはタブやその他の空白を使用できる可能性が高くなります。
ただし、サービスに送信される base64 コンテンツを生成する場合は、自分でタブを追加することはありません。送信するものには保守的であり、受信するものには (より) 寛大です。
はい!
Base64 は、安全な文字セットを使用して任意の 8 ビット値 (10 進数 0 から 255) を文字列にエンコードするために使用されます。TAB は 10 進数の 9 です。
Base 64 は、次の文字セットのいずれかを使用します。
Data: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
URLs: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_
テキストのバイナリ添付ファイル (例: 電子メール) も、このシステムを使用してエンコードされます。