修正UTF-7 IMAPエンコーダ
IMAPサーバーが期待するフォルダー名をそのまま作れます。Inbox/日本語はInbox/&ZeVnLIqe-になり、ログに出てくる読めない名前も元の表記に戻せます。英字だけの名前は変わりません。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- テキスト
- Inbox/日本語
- 計算モード
- Encode
- 結果
- Inbox/&ZeVnLIqe-
- エンコード
- modified_utf7_imap
- 入力の長さ
- 9
- 出力の長さ
- 16
ワイヤ上のIMAPメールボックス名は、修正UTF-7（RFC 3501 5.1.3節）と呼ばれるUTF-7の方言を用います。アンパサンドを除く印字可能なUS-ASCIIはそのまま残り、単独のアンパサンドはアンパサンドとハイフンの二文字列になり、それ以外の文字—アクセント、CJK、絵文字、制御コード—は、アンパサンドで始まりハイフンで終わる修正Base64区間にUTF-16BEとして詰め込まれ、スラッシュはカンマに置き換えられます。本ツールは人が読めるUnicodeフォルダ名をそのワイヤ文字列へ符号化し、またはLIST／SELECT応答を可読テキストへ復号します。
IMAP修正UTF-7とは何か、この変換器が返すもの
標準のメールボックスプロトコルは、利用者が日本語・スペイン語・アラビア語や絵文字のラベルを作っても、フォルダ名を7ビット安全な文字列として交換し続けます。IMAPはサーバ経路ごとに生のUTF-8を使う代わりに修正UTF-7でこれを解決しました。英語だけの名前はほぼ可読のままで、国際化セグメントはアンパサンドで包まれた短いブロックになります。
符号化規則は厳密です。 スペースからチルダまでの範囲でアンパサンドを除く文字は無変更で書かれます。アンパサンド自体は決して裸のままにせず、必ずアンパサンドのあとにハイフンを付け、続くBase64ブロックを意図したシフトとして扱えるようにします。
直接集合外の文字はまとめて走査され、ビッグエンディアンUTF-16符号単位へ変換されたうえで、64番目の記号がスラッシュではなくカンマである古典的アルファベットのBase64で符号化され、パディングの等号は省略されます。encodeモードはそのワイヤ文字列に加え、解決済みのモード、固定の符号化ラベル、入出力長を返します。
入力の確認と変換できない場合
modeの既定はencodeでdecodeも受け付け、別名op、direction、actionは同じ切替に対応します。encodeは文書化された文字上限までの整形式Unicode文字列を受け付け、BMP外の文字のサロゲートペアが分かれてしまわないよう符号単位を注意深く歩き、壊れたBase64を出す代わりにペアのないサロゲートを拒否します。
decodeは整形式の修正UTF-7を要求します。アンパサンドとハイフンの間の空のBase64区間は拒否されます。合法な空シフトは単独アンパサンド用の専用リテラル「アンパサンド・ハイフン」だけだからです。
メールクライアント・サーバ・テストにおけるメールボックス名符号化の位置づけ
クライアント作者はCREATE、RENAME、LIST、LSUBを実装し、国際フォルダについてDovecot、Cyrus、Exchange、Gmailが期待するワイヤ名と一致させる必要があるときに修正UTF-7に出会います。サポート技術者はプロトコルログの難解なフォルダトークンを貼り付け、デスクトップクライアントを開かずに人間向けラベルを必要とします。
バックエンドサービスは、IMAPプロキシへ保存する前や統合テストでSELECT対象を比較する前に、利用者向けフォルダ題名を正規化します。品質技術者は契約テスト用にencode／decodeの対を生成し、ライブラリ更新がBase64のカンマ対スラッシュを黙って変えたりアンパサンドのエスケープを落としたりできないようにします。
教育者はUTF-8メールボックス拡張、レガシー修正UTF-7、ワイヤに出ない表示名の違いを教える際に同じページを使います。メールとMIME向けの決定的テキストツールの小さな実験室を作るときは、カタログ内の他の無料エンコーダと組み合わせてください。
活用例
IMAPクライアントとサーバのデバッグ
CREATEやSELECT用にUnicodeフォルダ名を符号化するか、アンパサンドで包まれた修正UTF-7区間を含むLIST応答を復号します。
サポートログの翻訳
プロトコルトレース上の難解なワイヤメールボックストークンを、フル機能のメールクライアントなしで可読なUnicodeラベルへ戻します。
よくある質問
IMAP修正UTF-7は通常のUTF-7とどう違いますか？
IMAPはシフト文字にプラスではなくアンパサンドを使い、Base64アルファベットはスラッシュの代わりにカンマを使います。アンパサンド自体はアンパサンド・ハイフンと書かれます。パディングの等号は省略されます。
プレーンASCIIに対してencodeモードは何を返しますか？
同じ印字可能ASCII文字列です。アンパサンドを除く直接US-ASCIIはそのまま自分自身を表すためです。非直接文字と裸のアンパサンドだけが書き換えられます。
リテラルのアンパサンドはどう符号化されますか？
二文字列アンパサンド・ハイフン（&-）としてです。名前の後ろに本当のBase64区間が続くときも、シフト解析が曖昧になりません。
ログにあるInbox/&ZeVnLIqe-のようなフォルダー名はどう読みますか？
デコードを選び、表示されたとおりに名前を貼り付けます。アンパサンドとハイフンに挟まれた部分が元の文字に戻るので、Inbox/&ZeVnLIqe-はInbox/日本語として読めます。
修正UTF-7の名前を元に戻せないのはどんなときですか？
末尾のアンパサンドに閉じるハイフンがない、区間に英数字・プラス・カンマ以外が入っている、区間が空、区間の外にASCII以外の文字がある、といった場合です。推測で直さず、問題を知らせます。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/utf7-imap \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Inbox/日本語"}'const res = await fetch("https://api.kit.forhosting.com/enc/utf7-imap", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "Inbox/日本語"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/utf7-imap",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "Inbox/日本語"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/utf7-imap", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"Inbox/日本語"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"Inbox/日本語"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/utf7-imap", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"text": "Inbox/日本語"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.utf7_imap",
"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 | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
アルゴリズムは完全に決定的で、ブラウザ内で無料実行され、不正なシフト列・不正なBase64・シフト外の裸の非ASCIIを推測せずinvalid_inputで報告します。成功したAPI呼び出しは各$0.002、検証失敗は課金されません。
IMAP修正UTF-7とは何か、この変換器が返すもの
decodeモードは経路を逆にし、直接ASCIIをコピーし、アンパサンド・ハイフンを単一のアンパサンドへ展開し、各アンパサンド・ペイロード・ハイフン区間をUnicodeへ戻します。
textとmodeの検証方法とリクエストが失敗するとき
必須フィールドはtextで、別名input、value、sによりフォームやスクリプトが既存の列名を再利用できます。入力末尾の閉じハイフンのないアンパサンド、A–Z a–z 0–9 プラス カンマ以外のBase64ペイロード、奇数バイトに復号されるペイロード、シフト区間外の非ASCIIはいずれもinvalid_inputと明確なメッセージで失敗します。検証失敗は課金されないため、不正なLIST行を安価に試しつつ、成功した変換は項目あたり$0.002のままです。
メールクライアント・サーバ・テストにおけるメールボックス名符号化の位置づけ
本ページでは変換はブラウザで無料実行され、APIでは成功した各要求が$0.002で、応答後に何も保存されず、数学はRFC例（台北と日本語の古典的パスがアンパサンド包みの修正Base64列になる例など）と一致します。
連携の活用例
プロトコルフィクスチャの生成
単体テスト、ゴールデンファイル、複数ロケールのIMAP統合確認向けに再現可能なメールボックス名の対を作ります。
技術的な質問
どの誤りがinvalid_inputを起こしますか。
未終端のアンパサンドシフト、不正なBase64文字、奇数長の復号バイト列、ペアのないサロゲート、シフト区間外の裸の非ASCII、欠落したtextです。失敗した呼び出しは課金されません。
APIの料金はいくらですか。
成功した要求ごとに$0.002です。ブラウザ内ツールは無料です。無効な入力は課金されません。