ForHosting KIT · 開発者向けツール

Ascii85 / Base85 エンコーダー

「Hello, world!」はAdobe Ascii85(Base85)で87cURD_*#TDfTZ)+Tになります。4バイトを5文字の印字可能な文字にまとめるのでBase64より短く、PDFやPostScriptのツールが求める形です。復号もでき、ブラウザで無料で使えます。

  • 無料
  • ブラウザで動作
  • 登録不要
  • データは端末の外に出ません
ご利用方法 ウェブAPIメールTelegramアプリ 近日
入力した場合
テキスト
Hello, world!
結果
結果
87cURD_*#TDfTZ)+T
計算モード
Encode
バリアント
ascii85
バイト数
13

Ascii85(Base85 とも呼ばれます)は、4 バイトごとに感嘆符から小文字 u までの 85 記号から選んだ 5 文字へ写像し、ゼロバイト連続には特別な z 省略を使うことで、Base64 より密な印刷可能アルファベットにバイナリデータを詰めます。符号化は決定的で、UTF-8 のあと Adobe Ascii85 算術です。復号は任意の less-than-tilde と tilde-greater-than 区切りを受け付け、空白を除去し、不正記号は黙って置き換えず拒否します。

UTF-8 テキストを Adobe Ascii85 / Base85 に符号化

エンジンは文字列を Unicode テキストとして解釈し、UTF-8 バイトに直列化し、そのバイトを 4 つずつ big-endian の 32 ビット値にまとめ、各グループを感嘆符から小文字 u までの Adobe アルファベット 5 文字に展開します。4 バイト全部がゼロの完全グループでは、感嘆符 5 個の代わりに z 1 文字が出力されます。

これは PDF と PostScript ツールが期待する古典的なゼロ連続圧縮です。末尾の 1〜3 バイトの部分グループは算術のためにゼロで埋められ、残データ n バイトに対して n プラス 1 文字だけが出力され、復号側が正確な長さを復元できます。空文字列は有効で、0 バイトの空結果に符号化されます。

多言語テキスト、絵文字、句読点はフル UTF-8 経路のため往復でき、Latin-1 の近道ではありません。入力が同一なら出力も常に同一です。アルゴリズムは純粋な算術で、ネットワークも乱数ソルトも壁時計も使いません。

短い設定断片、ドキュメント用サンプル、Adobe 風のバイナリ・イン・テキスト経路で、Base64 より密なテキスト安全な表現が必要なときにこの経路を使います。

Base85 をテキストに戻し、不正文字を扱う

mode を decode にし、text に Ascii85 または Base85 文字列を置きます。先頭・末尾の空白(スペース、タブ、改行を含む)は取り除かれるため、複数行の貼り付けも機能します。アルファベットは厳密で、感嘆符から小文字 u までと、ゼロ 4 バイト用の単独 z だけが受け付けられます。

z でない場合、アルファベット文字が 2 未満の不完全な末尾グループは拒否され、2〜4 記号の短い末尾グループは算術のために u で埋められ、Adobe 規則どおり記号数より 1 少ないバイトになります。成功時の result は復元文字列、mode は decode、variant は ascii85、bytes は復号後 UTF-8 長です。

人が読める内容向けの Ascii85 エンコーダー、Base85 デコーダー、adobe ascii85 変換という検索意図ならこの機能を選び、バイナリ画像 data URI や標準 Base64 は別ランディングの別ツールのままにします。

Ascii85が役立つ場面と注意点

教室デモ、サポート用プレイブック、PDF ストリーム確認、OpenSSL ラッパや言語固有パッケージなしの単発変換には、ブラウザ内の無料 Ascii85 Base85 エンコーダーを使います。

典型的な流れは、テキスト専用チケット向けに短い設定値を符号化し、メールやチャットで送り、受信サービスで mode decode して bytes が元の長さと一致することを確認することです。

別の流れでは、リリース前にドキュメント用サンプルが文書化された平文にまだ復号できるかを確認し、encode と decode の両方のフィクスチャを固定して継続的インテグレーションがアルファベットの意図しないずれを検出できるようにします。

入力テキストは他の KIT parse 項目と同じ保持規則に従い、アルゴリズムはアイソレート間で完全に決定的なため、結果は継続的インテグレーション用フィクスチャに固定しても安全です。

テキストを Ascii85 / Base85 に符号化するには?

応答の result が Ascii85 文字列、bytes が UTF-8 長です。

Base85 をテキストに戻すには?

mode を decode にし、text に Ascii85 文字列を置きます。任意の Adobe <~ ~> 包みと空白を受け付けます。result は復元された UTF-8 テキストです。

不正な Base85 文字があるとどうなりますか?

Adobe アルファベット(!から u)外の文字とゼロ連続用の特別な z 以外は拒否され、検証失敗は課金されません。

Base64 との違いは何ですか?

Ascii85 は 85 記号のアルファベットを使い、4 バイトを 5 文字に詰めます(オーバーヘッド約 25 %、Base64 は約 33 %)。本ツールは Adobe Ascii85 を実装し、RFC 4648 の Base64 アルファベットではありません。

Ascii85の結果に出てくるzは何ですか?

zは省略記号です。4バイトの組がすべてゼロのとき、感嘆符5つの代わりにz1文字が書かれます。PDFやPostScriptのツールでおなじみの短縮で、デコード時も正しく読み取ります。

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

POSThttps://api.kit.forhosting.com/enc/base85

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

curl -X POST https://api.kit.forhosting.com/enc/base85 \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"Hello, world!"}'
{
  "text": "Hello, world!"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "enc.base85",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

HTTPコード意味
401unauthorizedAPIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
402insufficient_balance残高が不足しています。チャージ後に再度お試しください。
404unknown_type指定されたタスクタイプは存在しません。タイプ名を確認してください。
429rate_limitedリクエストが多すぎます。しばらく待ってから再度お試しください。

PDF ストリーム、PostScript 断片、レガシーな Adobe 風ペイロード、あるいは古典的 Base64 よりコンパクトでテキスト安全な形式を好むパイプラインでは、Ascii85 エンコーダーや Base85 デコーダーが求められます。この機能はその日常作業に特化しています。mode で encode または decode を選び、テキスト欄を送ると、変換後の文字列とバイト長が返り、デコード対象に Base85 アルファベット外の文字があれば明確な invalid_input エラーになります。

UTF-8 テキストを Adobe Ascii85 / Base85 に符号化

必須の文字列フィールド text に Ascii85 で表したい平文メッセージを入れた JSON 本体を送り、mode は既定の encode のままにするか、明示的に encode を設定します。古いフォーム名からクライアントを生成する場合、同じフィールドに任意の別名 input、value、s も受け付けます。応答には常に Ascii85 文字列の result、mode が encode、variant が ascii85、符号化前の UTF-8 長の bytes が含まれ、テストでペイロードサイズを検証できます。

Base85 をテキストに戻し、不正文字を扱う

先頭の less-than-tilde と末尾の tilde-greater-than という任意の Adobe 区切りは存在すれば除去され、区切りなしのペイロードも同様に有効です。それ以外の文字(u より後の文字、他符号化から借りた URL 安全句読点、バイナリノイズなど)は、不正な Base85 文字条件を名指しするメッセージ付きで即 invalid_input になり、クライアントは壊れた Unicode を受け取る代わりに貼り付けを直せます。アルファベット検証のあと、復元バイトは致命的デコーダで UTF-8 として解釈され、有効な Unicode テキストでなければ置換文字ではなく invalid_input になります。検証失敗は前払い API で課金されないため、疑わしいトークンの試行は運用者に安く、利用者にも安全です。

API の使い方・料金・ワークフローと実用上の限界

バックエンド、サーバーレス関数、SDK が同じ符号化・復号ステップを残高管理下で必要とするときは、成功アイテムあたり $0.002 の前払い KIT API を使い、エンジンが拒否したあとの検証失敗は残高を消費しません。相手システムが Base64 しか話さないときはこのエンドポイントを Base64 ツールと組み合わせつつ、各ページが単一の検索意図(Ascii85 の密度対 Base64 の普及)に合うよう手順は別ランディングに分けます。SDK を出荷する作者は result フィールドをそのままコピーボタンに写せ、mode と variant のラベルは Adobe アルファベットと z のゼロ連続省略だけを知る読者にも OpenAPI 例を自明にします。

PDF と PostScript の Ascii85 ストリーム

PDF フィルタ、PostScript 断片、古典的アルファベットと z のゼロ連続を期待するレガシーなバイナリ・イン・テキスト経路を調べるとき、Adobe 風 Ascii85 ペイロードを符号化または復号します。

より密なテキスト安全な設定トークン

チケット、チャット、JSON 向けに短い UTF-8 設定断片を Base64 より密に詰め、同じ mode フィールドで受信サービス側で復号します。

ドキュメントと CI の golden 検査

encode と decode のフィクスチャを固定し、Ascii85 アルファベットや不完全グループ規則がずれたらドキュメント用サンプルと継続的インテグレーション試験がすぐに失敗するようにします。

Ascii85 Base85 エンコーダーは無料ですか?

ブラウザツールは端末上で無料です。API 呼び出しは成功アイテムあたり $0.002 の前払い KIT 残高を使い、検証失敗は課金されません。

KITの完全なドキュメントを見る →