01
バイトの表現を指定する
エンコード時の16進入力は完全な2桁の組で指定します。10進入力は0–255を半角空白で区切ります。0x、配列の括弧、カンマを自動除去しないため、貼り付ける前に表現を確認してください。
エンコードとエスケープ
Baseエンコード16 / 32 / 58 / 85
文字列かバイト列かを確認し、生成元と同じ方式を選びます。
Baseエンコード
入力
変換はこのブラウザー内で行い、入力は送信しません。
結果
変換オプション
UTF-8テキスト、16進バイト対、空白区切りの0–255の10進バイトに対応。0x、カンマ、配列の括弧は使えません。
Base32は大文字のみ。Base58はチェックサムなし。Z85は4バイト／5文字単位です。
入力65,536 UTF-16単位、最大1,000行。1件65,536バイト、Base58は4,096バイト／5,600文字まで。レポート2,000,000文字、処理2秒まで。
テキストを入力するかサンプルを選んでください。空入力の結果は空文字列です。
Baseエンコードでは、見た目が同じ入力でも解釈によって結果が変わります。41をテキストとして入力すれば2バイト、16進表現として入力すればAを表す1バイトです。ライブラリ間で結果が合わないときは、この違いから確認できます。
Base32エンコードとBase32デコード、Base58変換、Ascii85などを1ページにまとめています。日本語や絵文字はUTF-8で扱い、文字にならないデータは16進または10進バイトとして入力・確認できます。
Baseエンコードで確認できる違い
方式を結果と一緒に残す
BaseエンコードはBitcoinとFlickrを別々に表示し、Ascii85・Git b85・Z85も区別します。バッチレポートには設定が含まれるため、受け取った人が同じ方式で結果を再現できます。
途中のエラーで行を失わない
不正な文字がある行も、元の行番号とエラーを残します。ほかの行は変換を続け、デコード結果の改行はJSON文字列内に保持されます。行数だけを見て結果を対応付ける必要がありません。
入力の解釈と結果の境界を合わせる
02
分割単位を確かめる
Base32のパディング設定はエンコードにだけ影響します。Ascii85の囲みはGit b85には使いません。Z85は4バイト単位で、足りない分を自動的にゼロで埋めることはありません。
03
逆変換はプレビューで確認する
バイト詳細で16進と10進を比較できます。自動変換を切るとCtrl/Cmd + Enterで実行できます。逆変換は適用前に入力の置換を表示し、取り消す操作では入力と結果を一緒に戻します。
8種類の方式をバイト単位で検査
Base16と2種類のBase32
Base16は1バイトを大文字2桁で出力し、デコードでは小文字も受け付けます。標準Base32はA–Zと2–7、base32hexは0–9とA–Vです。後者は別のアルファベットであり、16進入力の別名ではありません。
先頭のゼロを保持するBase58
BitcoinとFlickrは文字の集合が同じでも並び順が異なります。先頭のゼロバイトごとに1を残します。数値の大きさだけを変換する処理とは異なり、元のバイト数を復元できます。
Ascii85・Git b85・Z85を分離
Ascii85は完全なゼロブロックのz省略と任意のAdobe囲みに対応します。Git b85はRFC 1924の文字表を使う4バイト分割方式です。Z85はZeroMQの文字表と完全なグループを使います。
文字にできなくてもバイトを調べる
成功したバイト変換にはバイト数、16進、10進の詳細が付きます。不正なUTF-8を代替文字に置き換えません。エラーがあっても取得できたバイトは残るため、出力表現を変えて内容を確認できます。
受け付ける形式と対応しない処理
- 文字やパディングを補正しない
- Base32は大文字のみで、O/0やI/1を置換しません。パディングは正確な形か完全な省略に限り、未使用ビットも検査します。デコード時に無視できる空白は半角スペース、TAB、CR、LFだけです。
- アドレスや写真IDの変換ではない
- Base58Checkのチェックサム、ネットワーク接頭辞、WIF、ウォレットアドレスを検証しません。Flickrは文字表のみを提供し、写真IDから短縮URLを計算しません。独自文字表やCrockford、Rippleにも対応しません。
- Base85の拡張を混ぜない
- Ascii85は生データか完全な<~ ~>を受け付け、btoaのyを拒否します。PDFの抽出は行いません。Git b85はIPv6全体を整数として扱うRFC 1924の元の方式とは異なります。Z85はゼロの追加や削除を行いません。
- バッチは物理行ごとの値
- CR、LF、CRLFで行を分け、完全な空行だけを除外します。空白だけの値も保持し、エラー行をJSONに残します。単一値では改行はデータです。JSONレポートを逆変換の入力として自動使用することはできません。
- 入力と実行時間に上限がある
- 入力は65,536 UTF-16単位、バッチは空行を含め1,000行まで。1件65,536バイト、Base58は4,096バイトまたは5,600文字までです。レポートが2,000,000文字、処理が2秒を超える場合は全体を失敗として扱います。
- テキストの文字コードはUTF-8
- ファイル、URL、PDFの取り込みやShift-JISの推定は行いません。有効なBOMと結合文字は保持します。表示は1件20,000文字、バッチは50行ずつですが、書き出しは最新結果の全文を使います。入力変更後の古い結果は書き出せません。
Baseエンコードのよくある質問
Base32のデコードでパディングエラーになるのはなぜですか？
MY======とMYはどちらもfを表しますが、MY=は不完全なパディングです。本ツールは正確なパディングか完全な省略を受け付け、末尾の未使用ビットも検査します。生成元がbase32hexやCrockfordでないかも確認してください。
Ascii85とBase85とZ85はどう違いますか？
文字表、囲み、短い末尾グループの扱いが異なります。Ascii85は!からuまで、Git b85はPythonのb85encode形式、Z85はZeroMQ用です。Ascii85のzやAdobe囲みをほかの方式へそのまま使うことはできません。
Base32で日本語などの多バイト文字を正しく扱うにはどうすればよいですか？
先に文字列をUTF-8バイト列に変換してからBase32にします。日本語や絵文字に対応し、結合文字も正規化しません。元がUTF-8でない場合は、デコード結果をテキストではなく16進か10進で確認してください。
Base58では先頭のゼロバイトをどう保持しますか？
両方のBase58文字表で、先頭のゼロバイト1個につき先頭の1を残します。00 00 01は112になります。整数の大きさだけを変換すると失われる先頭バイトを、このツールでは保持します。
Base85とAscii85を自動判別できますか？
信頼できる自動判別はできません。文字表の重なりが大きく、複数の方式で受理されても復元されるバイトが異なる場合があります。生成元の仕様を確認し、既知の値で選択した方式を検証してください。
Flickrの短縮URLをBase58で作るにはどうすればよいですか？
Flickrの短縮URLは写真IDを数値としてBase58に変換する処理です。本ページはFlickrの文字表でバイト列を変換します。写真IDをUTF-8テキストとして入力しても同じ計算にはならず、短縮URLも生成しません。
説明のない変換エラーがありましたか？