HTTP-Header-Case変換
content-typeはContent-Type、x-request-idはX-Request-Id、ACCEPT-LANGUAGEはAccept-Languageになります。ハイフン間の各部分を小文字にしてから先頭を大文字にし、ハイフンの追加、削除、移動はしません。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- テキスト
- content-type
- テキスト
- Content-Type
- 元の値
- content-type
- セグメント
- 2
ハイフンで区切られた各セグメントを小文字にした後、最初の大文字・小文字を区別できる文字だけを大文字にします。そのため、content-typeはContent-Type、x-request-idはX-Request-Id、ACCEPT-LANGUAGEはAccept-Languageとなり、ハイフンの位置や個数は変わりません。辞書、ネットワーク、乱数、現在日時によって結果が変化することはありません。
ヘッダー表記の意味と結果の中身
Content-Type、Cache-Control、Accept-Language、X-Request-Idなどが代表例です。本変換機能は、入力全体をハイフンで分割し、各セグメントを小文字化し、大文字・小文字の形が異なる最初の文字を大文字にしてから、元のハイフン構造で再結合します。一般的なタイトルケースよりも規則を限定しています。
空白を単語の区切りとは見なさず、略語辞書を参照せず、IDのような全大文字の略語も保存せず、新しいハイフンの位置を推測しません。したがって、x-request-idはスタイル辞書に左右されず、常にX-Request-Idになります。
応答のtextには主な変換結果、originalには監査用の正確な原文、segmentsには分割された部分の数、methodには処理を示す固定識別子が入ります。すでに整形済みの値へ再度適用しても結果は変わりません。この性質により、ドキュメント生成、スナップショットテスト、データ整理、一貫した表示規則を必要とする画面で安全に利用できます。
区切り、文字の大小、特殊なセグメントの扱い
ハイフンは入力の構造情報として扱うため、正規化せずそのまま保存します。先頭や末尾のハイフン、または連続したハイフンによって生じる空のセグメントも、出力内で空のまま残ります。この設計により、単なる表示整形が識別子を書き換えたり、情報を黙って削除したりすることを防ぎます。
空でない各セグメントには、まずUnicodeの小文字変換を適用し、その後で大小の形が異なる最初の文字を大文字にします。その文字より前にある数字や記号は移動しないため、2fa-tokenは2Fa-Tokenになります。数字や句読点だけのセグメントは実質的に変化しません。
空白も保持され、区切りには昇格しません。入力は1文字以上の文字列である必要があります。十万文字の上限によってメモリーと処理時間を制限します。
表示用の整形で、正しさの検証はしません
公開処理では、表記が混在したラベルを描画前に統一できます。移行スクリプトでは、手作業の置換表を保守せずに古いヘッダーマップを読みやすく表示できます。ただし、出力は表示形式の変換にすぎません。
また、この大文字表記が通信時に必須だと示すものでもありません。実際の要求や応答を確認する場合は、検証機能やヘッダー検査機能をお選びください。ブラウザーでは無料で実行できます。
両方の経路が同じ純粋関数を共有するため、貼り付け例から本番スクリプトへ移行しても規則は変わりません。
活用例
決定論的なテストデータ作成
大文字・小文字の処理を重複実装せず、スナップショットや互換性テスト向けの安定した期待値を生成できます。
設定画面を読みやすく整理
ダッシュボード、サポート用出力、監査レポート、従来の管理画面でハイフン付きキーを整形できます。
よくある質問
通常の文章にハイフンを追加しますか？
いいえ。 既存のハイフンを保存して各セグメントの大小文字だけを変更し、空白の置換や区切りの追加は行いません。
IDのような略語は大文字のまま残りますか？
いいえ、略語の一覧は使わず、すべての部分に同じ規則を当てるので、x-request-idはX-Request-Idになります。表記辞書に左右されないため、結果は毎回同じです。
部分が数字で始まる場合はどうなりますか？
数字や記号はそのままの位置に残り、そのあとの最初の文字が大文字になります。2fa-tokenは2Fa-Tokenになり、数字だけの部分は変わりません。
すでに整形済みのテキストに使っても大丈夫ですか？
はい、整形済みの入力はまったく同じ形で返るので、2回変換しても結果は変わりません。ドキュメントの自動生成やデータの整理にも安心して使えます。
先頭のハイフンや連続したハイフンはどうなりますか？
そのまま残ります。先頭や末尾のハイフン、2つ続いたハイフンは空の部分を作りますが、空のまま保たれるので、ハイフンの数と位置は変わりません。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/str/header-case \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"content-type"}'const res = await fetch("https://api.kit.forhosting.com/str/header-case", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "content-type"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/str/header-case",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "content-type"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/str/header-case", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"content-type"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"content-type"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/str/header-case", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"text": "content-type"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "str.header_case",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
制限
max_chars | 100000 |
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
ヘッダー形式のテキストを、予測可能な規則でHTTP-Header-Caseへ変換します。ドキュメント、設定画面、コード例、テスト用データ、従来型システムでHTTPフィールド名を読みやすく表示する際に役立ちます。対話操作はブラウザー内だけで完結し、APIも同一の決定論的な処理を使用します。空または不正な入力は明確に拒否され、APIでの正常な変換1回の料金は$0.002です。
HTTP-Header-Caseの意味と返却内容
HTTP-Header-Caseとは、ハイフンで区切られた各部分を大文字で始め、残りを小文字にする表示上の慣習です。
区切り、文字の大小、特殊なセグメントの扱い
本機能はハイフン区切りのテキストを想定しており、通常の文章からフィールド名を新しく作るものではありません。値の欠落、null、array、オブジェクト、真偽値、空文字列にはinvalid_inputを返します。ネットワーク、モデル、保存領域、乱数、時計を使用しないため、同じ有効な入力はブラウザーでもAPIでも常に同じJSONになります。
表示と自動化に使い、HTTP検証には別の道具を選びます
本変換機能は、人がフィールド名を読む場面で特に便利です。APIドキュメント、サポート記事、設定画面、自動生成表、コード例、変更履歴、テストレポートなどで利用できます。入力がHTTPの構文上有効なフィールド名かどうかを検証せず、公式登録情報を調べず、値を解釈せず、重複を統合せず、X-接頭辞の適否も判断しません。現代のプロトコルやライブラリでは小文字のフィールド名が広く使われ、HTTPフィールド名の意味は大小文字を区別しません。読みやすいHTTP-Header-Case表示が明確に必要な場合に本機能をご利用ください。正常な自動処理1回は$0.002で、検証失敗は型付きエラーになります。
連携の活用例
APIドキュメントの表記統一
大小文字が混在するフィールド名をHTTP-Header-Caseへそろえてから、リファレンスページを公開できます。
技術的な質問
HTTP-Header-Case変換の料金はいくらですか？
ブラウザーでの対話変換は無料です。正常なAPIリクエスト1回につき$0.002です。
IDやHTTPなどの略語を維持しますか？
いいえ。各セグメント全体を小文字にしてから最初の文字を大文字にするため、idはIdになります。
結果はHTTPフィールド名としての有効性を保証しますか？
いいえ。これは表示上の変換であり、プロトコル構文の検証や登録情報の照会ではありません。
HTTPフィールド名は大文字と小文字を区別しますか？
意味上は区別しません。この変換は見慣れた表示が必要な場合に使い、プロトコル上の必須条件とはお考えにならないでください。