UTF-7エンコード・デコード
7ビットしか通らない経路でも崩れないUTF-7のテキストを作れます。caféはcaf+AOk-になり、デコードすると元の単語に戻ります。英字はそのまま読め、それ以外の文字だけが短いシフト部分に入ります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- テキスト
- café
- 計算モード
- Encode
- 結果
- caf+AOk-
- エンコード
- utf-7
- 入力の長さ
- 4
- 出力の長さ
- 8
このUTF-7エンコーダーは、平文のUnicodeテキストをRFC 2152で定義された7ビット安全なUTF-7変換へ符号化し、UTF-7文字列を読みやすいUnicodeへ戻します。UTF-7は日常のASCII文字を読みやすく保ちつつ、非ASCIIの連続部分をUTF-16BEコードユニットから成るプラス記号始まりの修正Base64列にまとめます。そのため8ビット転送が保証されない環境では、レガシーメール経路、古いIMAPツールの議論、相互運用フィクスチャがいまだにこれを参照します。エンジンは完全に決定的で、同じ入力とモードは常に同じ結果を返し、ネットワーク呼び出し・乱数ソルト・日付依存の近道はありません。よくある確認として、caféをcaf+AOk-へ符号化し、その文字列を元の語へ戻す例があります。
UTF-7とは何か、このツールが返すもの
UTF-7は、7ビットASCIIの安全性しか保証しないシステムをテキストが通過できるよう設計された、Unicode向けのコンテンツ転送風の符号化です。直接集合の文字——英数字、短い句読点、任意の印字可能ASCII、通常の空白——はそのまま現れ、符号化後も英語の文が人間に読みやすく残ります。
アクセント付きラテン文字、ギリシャ文字、CJK、絵文字、BMP外の符号点など、集合外の文字はすべてシフト連にまとめられます。プラス記号、パディングの等号なしの修正Base64本体、次の文字がBase64アルファベットに吸収されてしまう場合の任意のハイフン終端です。リテラルのプラスはプラス・ハイフンとして特別に書き、誤ってシフトが始まらないようにします。
本ページは平文について常にRFC 2152の契約に従います。encodeモードはUnicode符号点を走査し、直接文字を通し、非直接の連をビッグエンディアンUTF-16単位としてまとめ、シフトBase64形式を出します。decodeモードは直接テキストをコピーし、シフト連を展開し、空または不完全なBase64本体は推測せず拒否します。
ストリーミング経路も壊れたシフトの黙修復もありません。
textとmodeの読み方、結果が再現可能である理由
modeの既定はencodeで、decodeを明示できます。別名op・direction・actionは、すでにそれらの名前を使うスクリプト向けに同じ切替へ写像します。
encodeは任意のUnicode文字列を受け取り、基本多言語面外のサロゲート対が保たれるよう符号点を歩き、Set D・Set Oの文字と空白をそのまま出し、裸のプラスをプラス・ハイフンに写し、非直接の連をシフト修正Base64で包みます。decodeは整形式のUTF-7文字列を要求します。
バイトを得た後はUTF-16BEコードユニットとして解釈し、JavaScript文字列へ組み立て直します。
メール・レガシーゲートウェイ・テストフィクスチャでのUTF-7の位置づけ
開発者は歴史的なメール符号化を調べるとき、RFC 2152例の笑顔シーケンスHi Mom -+Jjo!のような相互運用ケースを再現するとき、あるいはcaféのアクセントがメッセージ全体の不透明Base64ではなく短いシフト連になることを確認するときにUTF-7に出会います。
フロントエンドとサポートのチームは、ハイフン終端を誤処理したりプラス・ハイフンを空シフトとみなしたりする場当たり的なスクリプトにデータを貼らずに、チケット調査でUTF-7断片を復号します。バックエンドサービスは、8ビットクリーン転送が保証されない制限された7ビット経路に載せる前に、設定サンプルや短い多言語文字列を符号化します。
品質エンジニアは契約テスト用に決定的なencode／decode対を生成し、UTF-7対応を主張するライブラリが終端規則を黙って変えたり、シフト連の後の残余文字を落としたりできないようにします。本ページでは作業はすべてブラウザ内で行われます。
関連する転送符号化にはquoted-printableとBase64の補助を、無料で決定的なエンコーダーの小さな実験室を組むときは他のテキストツールと組み合わせてください。
活用例
レガシーメールの調査
歴史的メッセージのUTF-7断片を符号化または復号し、アクセントとシフトBase64連が古いゲートウェイの期待と一致するようにします。
7ビット経路の準備
ASCIIのみの制限チャネルへ送る前に、平文Unicodeを転送安全なUTF-7へ変換します。
よくある質問
UTF-7はBase64やUTF-8とどう違いますか？
UTF-8はUnicodeのバイト符号化です。Base64は各バイトを不透明なアルファベットに符号化します。UTF-7は大半のASCIIを読みやすく保ち、非直接文字だけをUTF-16BE単位のプラス記号Base64連へシフトします。
シフト列が不正な場合はどうなりますか？
末尾の単独プラス、プラス直後の空Base64本体、奇数の復号バイト長はいずれも推測せず拒否されます。
結果は決定的ですか？
はい。 同じtextとmodeは常に同じ結果を返し、ネットワーク・乱数・日付依存の挙動はありません。
UTF-7でcaféがcaf+AOk-になるのはなぜですか？
c・a・fは直接文字の集合に含まれるため、そのまま残ります。éは含まれないため、プラス記号、詰め物なしの短いBase64、終わりのハイフンからなるシフト部分にまとめられます。
IMAPのフォルダー名に使うUTF-7と同じですか？
いいえ。IMAPの修正UTF-7はアンパサンドで始まり、別の文字セットを使います。このツールはRFC 2152に沿った通常のテキスト用で、シフト部分はプラス記号で始まります。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/utf7 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"café"}'const res = await fetch("https://api.kit.forhosting.com/enc/utf7", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "café"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/utf7",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "café"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/utf7", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"café"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"café"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/utf7", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"text": "café"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.utf7",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
フレーズ・件名の断片・多言語フィクスチャを転送安全なUTF-7にするにはencodeを、すでに手元にあるUTF-7ペイロードから原文を復元するにはdecodeを選んでください。メール調査やUnicodeの練習にはブラウザで無料で使い、CIやバックエンドで再現可能なUTF-7変換が必要なときは、成功1件あたり$0.002のAPIをご利用ください。
UTF-7とは何か、このツールが返すもの
JSON応答には変換後文字列のresult、encodeまたはdecodeを示すmode、utf-7固定のencoding、テストでサイズを検証できるようJavaScript文字列長で測ったinput_lengthとoutput_lengthが含まれます。文字列が妥当なUTF-7であるか、要求がinvalid_inputで失敗するかです。不透明なバイナリ梱包が必要ならBase64またはBase64urlのエンドポイントを、アンパサンド導入のIMAP修正UTF-7（メールボックス名）が必要なら別アルファベットであり、このランディングではありません。
textとmodeの読み方、結果が再現可能である理由
優先するペイロード欄はtextで、別名input・value・sがあるため、フォーム、クエリ文字列、SDKクライアントが列名を変えずに同じ契約を使えます。入力末尾の単独プラス、ハイフン以外の非Base64が続くプラス、空のBase64本体、奇数バイトに展開されるBase64本体はいずれも、不正なシフト列を名指しする明確なinvalid_inputで失敗します。同じ数学的結果を自動パイプライン内で得たいときは、このページの無料ブラウザ実行と有料APIを組み合わせ、UTF-7表を自ら再実装する必要はありません。無効入力はinvalid_inputを返し課金されず、検証を安価に保ちつつ、成功した変換は項目あたり固定価格$0.002のままです。
メール・レガシーゲートウェイ・テストフィクスチャでのUTF-7の位置づけ
教育者は、主にテキストのペイロードについて、UTF-8バイトの16進ダンプ、quoted-printableのイコール16進エスケープ、UTF-7のプラス記号シフトBase64の違いを教えるときに同じツールを使います。API経由では成功した照会ごとに$0.002がかかり、検証失敗は課金されず、応答後に何も保存されません。無料の対話探索と同一結果の有料APIという分担は、KITのティアAカタログの他項目と一致し、教室デモから自動パイプラインへ符号化結果を変えずに移れます。
連携の活用例
RFC 2152フィクスチャ生成
単体テスト、ゴールデンファイル、RFC例に対する相互運用チェック用に、再現可能なUTF-7文字列を生成します。
技術的な質問
UTF-7エンコーダーの料金はいくらですか？
このページではブラウザ内で無料です。API経由では成功した要求が$0.002で、無効入力は課金されません。
どのモードが使えますか？
mode=encode（既定）は平文をUTF-7にします。mode=decodeはUTF-7文字列をUnicodeテキストに戻します。