Base64 エンコーダー / デコーダー

いいえ。Base64 はエンコーディングです——鍵も秘匿性もない、可逆な衣装替えにすぎません。Base64 文字列を見た人は誰でも即座にデコードできるため、「API キーが設定ファイル内で Base64 エンコードされている」とは、API キーが事実上平文で設定ファイル内にあるという意味です。記事 Base64 は暗号化ではない では、エンコーディング、暗号化、ハッシュの違いと、それぞれの混同が生む間違いを解きほぐしています。

位置のない「不正な文字」は、総称的なデコーダーがあなたの午後を無駄にするやり方だからです。貼り付けられた文字列が失敗する原因は通常 3 つのうちの 1 つです。周囲のテキストから紛れ込んだ余分な文字（引用符、カンマ、ログの 1 行）、文字集合の取り違え（URL セーフな文字列を標準デコーダーに与えた）、コピーの途切れです。ここでは最初の問題文字がそのインデックスとともに示されるので、その正確な場所を見て、3 つのうちどれが起きたのか分かります。

文字集合です。標準 Base64 は + と / を使いますが、これらは URL の構造文字であるため、URL セーフな Base64 はそれらを - と _ に置き換え、通常 = のパディングを落とします。これがすべての JWT の内部で使われている変種です。一方の変種を他方のデコーダーに与えることが、最初の + や / の位置でのデコード失敗の最も一般的な原因です——このツールはモードを分離しているため、エラーメッセージがまさにそれが起きたことを伝えられます。

はい——変換はあなたのブラウザ内、このページで実行され、貼り付けた内容が送信されたり保存されたりすることはありません。それが重要なのは、デコードされるものが資格情報であることがあまりに多いからです。設定ファイル内の Base64 ブロック、Kubernetes のシークレット（それは Base64 であって暗号化ではありません——上の質問を参照）、トークンのペイロードです。同じ文字列を AI チャットに貼り付ければ、ログの残る第三者のシステムにコピーが送られます。チャットボットにシークレットを扱わせてはいけないを参照してください。

それがバイナリだからです——画像、アーカイブ、コンパイルされた何か——そしてバイナリはテキストではありません。テキストデコーダーは、文字化けを渡す代わりに拒否します。テキストボックスの下にあるファイルセクションを使ってください。Base64 をそこに貼り付け、バイト列が無事なまま再構築されたファイルをダウンロードできます。