ヘッダーQエンコード
メールの件名や差出人名にアクセント付きの文字を安全に入れられます。Hello caféは=?UTF-8?Q?Hello_caf=C3=A9?=になり、貼り付けた符号化語は読める文字に戻ります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- テキスト
- Hello café
- 計算モード
- Encode
- 結果
- =?UTF-8?Q?Hello_caf=C3=A9?=
- エンコード
- rfc2047-q
- 文字セット
- UTF-8
- 形式
- Encoded word
このヘッダー向けQエンコーダーは、平文のUTF-8テキストを非ASCIIメールヘッダー用MIME encoded-word内で使われるRFC 2047のQ形式へ変換し、その文字列を再び読みやすいテキストへ戻します。charset? Q? …?= の枠組みと混同しないようにします。よくある確認として、Hello café を =?UTF-8? Q? Hello_caf=C3=A9?= にエンコードし、その文字列を元の句へデコードします。
RFC 2047のQエンコードとは何か、このツールが返すもの
RFC 2047はencoded-wordを定義し、歴史的にASCII中心だったメールヘッダーでもSMTP経路の規則を壊さずに国際テキストを運べるようにします。Q方式は単純な端末でもラテン文字の大半を読めるように保ちます。
安全な印刷可能ASCIIはそのまま現れ、空白は好ましくはアンダースコアとして書かれ、それ以外のオクテットは等号のあとに大文字十六進二桁が続きます。等号・疑問符・アンダースコア自体はデータとして現れるときエスケープしなければなりません。encoded-wordの文法上の構造要素だからです。
本文quoted-printableのソフト改行はここには当てはまりません。encoded-wordは単一の原子トークンであり、ソフトブレーク列を含んではなりません。本ページは既定でUTF-8テキストについてこの契約に従います。
encodeモードは文字列をcharsetのバイトへ写像し、空白にアンダースコア、不安全バイトに等号十六進を出し、必要なら完全なencoded-wordで包みます。ストリーミング経路はなく、壊れたQテキストの黙った修復もありません。
ヘッダー向けに不透明なバイナリ詰めが必要ならB方式またはBase64ヘルパーを選び、本ランディングは件名・表示名が今も日常的に使う読みやすいQ経路向けです。
メールヘッダー・MIME・テストフィクスチャでのQエンコードの位置づけ
開発者は、等号・疑問符・UTF-8・疑問符・Qで始まるSubject行を調べるとき、FromとToの国際表示名を作るとき、あるいは生メッセージダンプでcaféのアクセントがアンダースコアと等号十六進の対になった理由を調べるときに、RFC 2047のQエンコードに出会います。
フロントエンドとサポートのチームは、空白をアンダースコアに置き換える扱いを誤るスクリプトや、本文quoted-printableとヘッダーQ規則を混同するスクリプトにデータを貼らずに、チケット調査中にQ断片をデコードします。バックエンドサービスは、8ビット無制限の転送が保証されないヘッダー欄へ入れる前に、設定サンプルや短い多言語文字列をエンコードします。
品質エンジニアは契約テスト用に決定的なencode／decode対を生成し、RFC 2047対応を名乗るメールライブラリが十六進の大文字小文字を黙って変えたり、空白を未エスケープのままにしたり、壊れた等号列を受け入れたりできないようにします。
教育者は、本文quoted-printableのソフト改行と、1トークンに留まらなければならないヘッダーQ原子の違いを教えるときにも同じツールを使います。
本文ではなくヘッダーを扱うときはMIME quoted-printableヘルパーと、密でバイナリに見えるヘッダーデータにはBのencoded-wordが適切なときはBase64ヘルパーと組み合わせてください。
活用例
Subjectと表示名のデバッグ
RFC 2047のQで符号化されたSubjectおよびFrom表示名の断片をエンコードまたはデコードし、アクセントと空白がメールクライアントの表示と一致するようにします。
レガシーゲートウェイ向けヘッダー準備
制限された7ビットメール経路へ送る前に、平文UTF-8を転送に安全なQ符号化ヘッダートークンへ変換します。
よくある質問
ヘッダーのQエンコードと本文のquoted-printableの違いは？
ヘッダーのQエンコード（RFC 2047）は空白をアンダースコアに写像し、encoded-word内のソフト改行を禁止し、=・?・_ を特別扱いします。本文のquoted-printable（RFC 2045）は空白に =20 を使い、行を76文字以内に保つソフト改行を用います。
空白がアンダースコアになるのはなぜですか？
符号化語はヘッダーの中で空白のないひとつのまとまりである必要があるため、Q方式では空白をアンダースコアで書きます。デコード時には空白に戻り、本文にある本物のアンダースコアはエスケープされます。
先頭の=?UTF-8?Q?は何を意味しますか？
符号化語の外枠です。最初に文字コード名、次に方式を示すQ、そのあとに符号化した本文が続き、最後を?=で閉じます。中身だけが欲しい場合は、外枠なしで出力することもできます。
Q方式でエスケープが必要な文字は何ですか？
本文に含まれる等号、疑問符、アンダースコアは、符号化語の構造に使われるためエスケープが必要です。それ以外の安全でないバイトは、等号と大文字の2桁の十六進数に置き換えられます。
エスケープが途中で切れているとどうなりますか？
推測で補わず、その文字列を受け付けません。等号のあとに正しい2桁の十六進数が続かない場合はコピーの途中切れや改変が考えられるので、元の文字列を確認してください。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/quoted-printable-q \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Hello café"}'const res = await fetch("https://api.kit.forhosting.com/enc/quoted-printable-q", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "Hello café"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/quoted-printable-q",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "Hello café"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/quoted-printable-q", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"Hello café"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"Hello café"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/quoted-printable-q", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"text": "Hello café"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.quoted_printable_q",
"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 | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
本文のquoted-printableとは異なり、ヘッダーのQエンコードは空白をすべてアンダースコアに写像し、encoded-word内のソフト改行を禁止し、疑問符とアンダースコアを予約して、メールパーサーがペイロードを =?件名の断片、表示名、フィクスチャ用の語句を転送に安全なヘッダートークンへするにはencodeを、すでにお持ちのQペイロードまたは完全なencoded-wordから元の文を取り戻すにはdecodeを選んでください。エンジンは完全に決定的で、同じ入力・mode・charset・formは常に同じ結果を返し、ネットワーク呼び出し、乱数ソルト、日付依存の近道はありません。メールのデバッグやヘッダーの練習にはブラウザで無料でご利用いただき、CIやバックエンドで再現可能なRFC 2047変換が必要なパイプラインでは、成功リクエストごとに $0.002 のAPIをご利用ください。
RFC 2047のQエンコードとは何か、このツールが返すもの
encoded-wordは「等号・疑問符・charset・疑問符・encoding・疑問符・payload・疑問符・等号」の形をとり、encoding文字はquoted-printableに似たQ方式、またはBase64のB方式です。decodeモードは完全なencoded-wordまたは裸のQペイロードを受け付け、アンダースコアと等号十六進を展開し、不完全または非十六進の列を推測せず拒否します。JSON応答には変換後文字列のresult、encodeまたはdecodeをエコーするmode、rfc2047-qに固定したencoding、charset、form（encoded_wordまたはpayload）、検証しやすい裸のpayload、テストでサイズを固定するためのinput_bytesとoutput_bytesが含まれます。文字列が有効か、invalid_inputで失敗するかのどちらかです。
text・mode・charset・formの読み方と結果の再現性
modeの既定はencodeで、decodeを明示的に受け付けます。別名op・direction・actionは、すでにそれらの名前を使うスクリプト向けに同じ切替へ写像します。charsetの既定はUTF-8で、encode時にencoded-wordへ書き込まれます。charset? Q? …?encodeはUnicode文字列を受け、選んだcharsetの規則で変換し、大文字十六進エスケープと空白ごとのアンダースコアでQトークンを出します。decodeは整形式のQ文字列を要求します。バイト復元後、charsetがUTF-8のときは致命的UTF-8デコードによりバイナリゴミが文字化けテキストにならないようにします。優先するペイロード欄はtextで、別名input・value・sによりフォーム、クエリ文字列、SDKクライアントが列名を変えずに同じ契約を再利用できます。完全なencoded-wordをデコードするときはトークン自身からcharsetを取り、裸のペイロードをデコードするときはcharset引数が、復元バイトをテキストへどう戻すかを選びます。formの既定はencoded_wordで、encodeはSubjectやFromの表示名断片にそのまま使える完全な =?= を返します。 単体テスト用や複数セグメントのヘッダーを自分で組み立てるときは、内側のQ本体だけが欲しい場合にformをpayloadにしてください。入力末尾の単独等号、等号のあとに一文字だけ、等号のあとに非十六進桁がある場合は、不正なエスケープを名指しする明確なinvalid_inputで失敗します。このページの無料ブラウザ実行と有料APIを組み合わせれば、RFC 2047表を自分で実装し直さずに自動化パイプライン内で同一の数学的結果を得られます。無効入力はinvalid_inputを返し課金されません。検証は安く、成功した変換は1件あたり固定の $0.002 のままです。
メールヘッダー・MIME・テストフィクスチャでのQエンコードの位置づけ
このページでは作業はすべてご利用のブラウザ内で走り、API経由の成功した照会はそれぞれ $0.002 で、失敗した検証は課金されず、応答のあと何も保存されません。無料の対話的探索と、結果が同一の有料APIという分け方はKITのティアAカタログの他項目と揃っており、教室デモから自動化パイプラインへ、エンコード結果を変えずに移れます。
連携の活用例
メールヘッダー用フィクスチャ生成
単体テスト、ゴールデンファイル、ヘッダー形式を検証するSMTPまたはIMAP連携チェック向けに、再現可能なencoded-wordを生成します。
技術的な質問
ヘッダー向けQエンコーダーの料金は？
このページではブラウザ内で無料です。APIでは成功したリクエストが $0.002 で、無効な入力は課金されません。
どのmodeとformが使えますか？
mode=encode（既定）は平文をQエンコードにします。mode=decodeはQ文字列をテキストに戻します。form=encoded_word（encode時の既定）は =?charset?Q?payload?= で包み、form=payloadは内側のQ本体だけを返します。
エスケープ列が壊れているとどうなりますか？
decodeはinvalid_inputで失敗します。不完全な =XX、= のあとの非十六進桁、Qペイロード内の不正文字は推測せず拒否されます。
結果は決定的ですか？
はい。同じ text・mode・charset・form は常に同じ結果を返し、ネットワーク・乱数・日付依存の挙動はありません。