ForHosting KIT · 開発者向けツール

Base32768エンコーダー

テキストを、1文字に15ビットを載せるBase32768に変換します。UTF-16で扱う場面に向き、Helloはわずか3文字の䩲腻㐿になります。復号ではすべての記号と詰め物を確かめるので、壊れたコピーは失敗します。ブラウザで無料で使えます。

  • 無料
  • ブラウザで動作
  • 登録不要
  • データは端末の外に出ません
ご利用方法 ウェブAPIメールTelegramアプリ 近日
入力した場合
テキスト
Hello
計算モード
Encode
結果
結果
䩲腻㐿
長さ
3
入力バイト数
5
1文字あたりのビット数
15

Base32768 は、すでに UTF-16 を扱う経路向けのバイナリからテキストへの符号化です。結果を UTF-16 として保存・伝送するとおおよそ 93.75 パーセントの効率となり、同じ経路上の Base64 よりはるかに高密度です。本機能は qntm Base32768 プロファイルを端から端まで実装します。encode は平文を UTF-8 バイトとして読み取り Base32768 を出力し、decode は 15 ビットの主アルファベットと 7 ビットのパディング用副アルファベットに対して各記号を検証したうえで元の UTF-8 テキストを復元します。

Base32768 が安全な BMP 文字へ 15 ビットを詰める仕組み

Base32768 は入力を生バイトの連続ビット列として扱います。テキストの場合、本機能はまず UTF-8 で文字列を変換し、多バイト文字が言語やプラットフォームをまたいで移植可能であるようにします。ビットは最上位から取ります。

蓄積した 15 ビットごとに、基本多言語面の割り当て済み・非制御・非空白の Unicode 符号点の閉区間から成る 32768 エントリの主レパートリの 1 インデックスを選びます。最終余りが完全な 15 ビットブロックでないときは 1 で埋め、主記号で終えるか、128 エントリの別アルファベットから取る 7 ビットの副パディング記号で終えます。

復号は対応を反転します。各文字は 15 または 7 ビットを寄与し、8 ビットがたまると完全なバイトを出力し、残りのパディングビットはすべて 1 である必要があります。最終位置より前の副パディング文字も拒否します。

合法な符号化ではそのパターンが現れないためです。Base64 と比べると ASCII 専用アルファベットを捨てて UTF-16 下での密度を大きく上げ、Base65536 と比べると BMP 内に留まり各文字が単一の UTF-16 符号単位になります。

実務で Base32768 が現れる場面

UTF-16 テキスト列にバイナリ blob を格納するシステムは、BMP を出ずに Base64 より密な詰め込みを必要とすることが多いです。qntm 系の密度符号化を既に標準化したチームは、経路が UTF-16 ネイティブなら Base32768 を、別制約なら Base2048 や Base65536 を使います。

異なる Unicode 形式下の符号化密度を教える教材著者は、検索意図・アルファベット規則・効率数値が異なるため、汎用 Base64 ランディングに埋めるのではなく Base32768 専用ページを望みます。

TOTP 秘密向けの RFC 4648 Base32、URL 安全 Base64、UTF-8 下の basE91 密度が必要なら、この Base32768 エンコーダーページを過負荷にせず、別の検索意図とランディングとして扱ってください。

どの Base32768 プロファイルを使いますか?

qntm Base32768 プロファイルです。各 15 ビットを運ぶ 32768 個の主 BMP 符号点に加え、必要時の最終 7 ビットパディング記号用の 128 エントリ副アルファベットがあります。

エンコードとデコードの両方できますか?

はい。 mode を encode(既定)にすると平文 UTF-8 を Base32768 にし、mode を decode にすると Base32768 文字列からテキストを復元します。

Helloがたった3文字になるのはなぜですか?

Base32768の1文字は15ビットを運ぶためです。Helloは5バイトなので3文字で足り、最後の文字の余った部分は1のビットで埋められます。

UTF-16ではなぜBase64より密度が高いのですか?

Base64はASCIIの1記号に6ビットしか載せませんが、Base32768は1文字に15ビットを載せ、どの文字もUTF-16の1単位で表せるからです。UTF-16で保存すると、効率はおよそ93.75パーセントになります。

無効な文字が入っているとどうなりますか?

すぐに受け付けません。どちらの文字の表にもない文字のほか、詰め物の文字が途中にある場合や、詰め物のビットが正しくない場合も同じで、壊れたコピーが成功したように見えることはありません。

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

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

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

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

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

1リクエストあたり$0.002

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

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

JavaScript の文字列、Java の String、Windows のワイド API、NVARCHAR を使う多くのデータベースなどが該当します。Base32 や Base64 のように ASCII 記号へ 5〜6 ビットを詰めるのではなく、基本多言語面の安全な 32768 個の符号点から文字を選び、1 文字あたり 15 ビットのペイロードを運びます。不正な記号、誤位置のパディング、パディングビット不一致はすぐ invalid_input となり、壊れた貼り付けが成功に見えません。無料のブラウザツールと有料 API は同一の純粋な同型関数を共有するため、デモ・スクリプト・本番 Webhook は常に同じ変換結果に一致します。

Base32768 が安全な BMP 文字へ 15 ビットを詰める仕組み

これらの範囲は Unicode 正規化で壊れやすい文字、文字方向を乱す文字、整形に見える文字を意図的に避け、符号化後の文字列をほとんどの Unicode クリーンな API へ安全に貼り付けられるようにしています。両レパートリ外の文字は invalid_input を起こします。経路全体はネットワークなし・乱数なし・壁時計なしの決定的な整数演算なので、同一入力は常に同一の JSON を返します。

送る内容と返る内容

encode は text を平文 UTF-8 として扱い、Base32768 アルファベットの result 文字列を返します。decode は text を Base32768 として扱い、各記号を検証し、復元した UTF-8 文字列を result に返します。検証失敗は前払い残高を消費しません。無料のブラウザフォームを手早い確認や教室デモに使い、大量の不透明トークンや回帰フィクスチャが必要なときはスクリプトから同一契約を呼び出してください。必須の文字列フィールド text と、任意の mode(encode または decode)を送ってください。mode を省略すると既定は encode となり、単一ペイロードでも有用です。両方向とも mode、元の text、result、主出力文字列の length、15 に設定された bits_per_char、alphabet と plane のラベル、プロファイル確認用の短い標準参照をエコーします。encode は input_bytes も、decode は output_bytes も報告します。text 欠落、非文字列オブジェクト、未対応の mode、文書化された上限を超える文字列、認識できない Base32768 文字、末尾前の副パディング文字、パディングビット不一致、有効な UTF-8 でない復号バイトはすべて invalid_input と明確な英語メッセージで失敗します。古典的な確認例は Hello を 3 文字の短い Base32768 ブロックへ符号化すること、hello world を形式で公開された参照文字列へ符号化すること、その文字列を元の 11 バイトのペイロードへ復号することです。成功した API 呼び出しの料金は公開ベースの $0.002 です(1 件あたり)。

実務で Base32768 が現れる場面

JSON に埋め込んだゲームセーブ blob、クリップボード API 経由のコンパクトな設定フィンガープリント、JavaScript 文字列の往復に耐える短いオフライントークンは、いずれも 1 文字 15 ビットの恩恵を受けます。サポート窓口はチケットから不透明な文字列を貼り付け、誤ったペイロードを生むゴミ記号を受け付けない厳密なアルファベット検証を必要とします。本機能は純粋な parse エンジンなので、API 料金は成功 1 件あたり公開ベースの $0.002 であり、検証失敗は残高を消費しません。

UTF-16 高密度の不透明トークン

UTF-16 密度が ASCII 安全性より重要なとき、短いバイナリ安全なペイロードを Base32768 に符号化して NVARCHAR 列・JavaScript 文字列・クリップボード転送に使います。

ランタイム横断のゴールデンフィクスチャ

qntm Base32768 参照と一致する encode/decode ベクトルを生成し、多言語 CI が 15 ビット詰め込みの単一の正解を共有できるようにします。

貼り付け時の厳密検証

主または副アルファベット外の記号があるとき、明確な invalid_input でユーザーが貼り付けた Base32768 文字列を復号します。

Base32768 文字列に無効な文字があるとどうなりますか?

認識できない記号やパディング問題を示す invalid_input でデコードが失敗します。検証失敗に料金はかかりません。

なぜ Base32768 は UTF-16 下で Base64 より高密度ですか?

各 Base32768 文字は単一の BMP 符号単位(UTF-16 の 16 ビット)で 15 ペイロードビットを運び、効率は約 93.75 パーセントです。Base64 は ASCII 出力の 12 ペイロードビットに 2 個の UTF-16 単位が要るため、UTF-16 経路上の密度ははるかに低くなります。

料金はいくらですか?

ブラウザツールは無料でローカル実行です。API リクエストは成功 1 件あたり $0.002 の KIT 前払い残高を使い、無効入力は課金されません。

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