Unicode NFD正規化
1つのéで書いたcaféは、c、a、f、eと結合用の鋭アクセントの5つのコードポイントになります。合成済みの文字を基本の文字と記号に分けるので、見た目が同じ文字列も両方をNFDにすれば一致します。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- テキスト
- café
- 結果
- café
- 形式
- NFD
- 長さ (in)
- 4
- 出力の長さ
- 5
Unicode正規化形式D（NFD）は、事前合成された文字を、見た目を決める結合文字が続く基底文字へ展開するよう文字列を書き換えます。事前合成のeアキュートを含むcaféは、c-a-f-eに結合アキュートを加えた5コードポイント列になります。ハングル音節はジャモに分割され、ÅはAと結合リングになります。本機能はテキスト欄を受け取り、Unicode Standard Annex 15に基づくプラットフォームのNFDアルゴリズムを適用し、正規化後の文字列と長さ統計、変更フラグを返します。
NFD正準分解が実際に行うこと
Unicodeは多くのアクセント付き文字を二通りで保持します。例としてラテン小文字eにアキュートのU+00E9のような単一の事前合成コードポイント、または基底のU+0065に続く結合アキュートU+0301です。描画上は同じに見えてもバイト列は異なり、文字列等価性を壊し、長さ検査、正規表現、データベースの一意制約を驚かせることがあります。
Unicode Standard Annex 15で定義されるNormalization Form Dは正準分解を適用します。正準分解写像を持つ文字はすべてその写像に置き換えられ、結合文字は結合クラスで並べ替えられ、等価な列は同一になります。NFDはその後に再合成しません。
再合成はNFCです。 互換写像も適用しないため、fiのような合字や全角数字はそのまま残ります。互換分解はNFKDとNFKCの領域です。ハングル音節は先頭・母音・末尾のジャモへの特別なアルゴリズム分解を受け、短い韓国語語が言語的には同じテキストのままコードポイント長で何倍にも伸びることがあります。
写像表とマーク順序はランタイムのUnicode版で固定されるため、同一入力は同一エンジン上で常に同じNFD文字列になります。本機能は現代のWorkerとブラウザで利用できるJavaScriptのString.prototype.normalizeをNFD形式で使い、ネットワーク呼び出し、乱数シード、壁時計タイムスタンプを結果に含めない決定的な処理です。
この安定性こそ、フィクスチャ、システム間差分、分解後にcaféとcaféを同じ基礎列として扱う必要があるセキュリティレビューでNFDが有用な理由です。
結果の見方と使い方
有限の数値と真偽値は文字列形に変換されます。空文字列は有効で、changedがfalseの空NFD結果を返します。典型的なcaféの例はスカラーが4から5に増え、結合マーク1個でchanged trueになります。
Helloのような素のASCIIはchanged falseのまま同一です。検証失敗は前払い残高を消費しません。製品名やサポート貼り付けの確認には無料のブラウザフォームを使い、大量フィクスチャや継続的インテグレーションのアサーションが必要なときは同一契約をスクリプトから呼び出してください。
実務エンジニアリングでNFDが現れる場面
検索とオートコンプリートのパイプラインは、言語ごとの手書きアクセント表を持たずにcafeがcaféに一致するよう、NFDの後にダイアクリティカルを除去することがよくあります。識別子やスラッグ生成は先に分解し、結合マークを落として、利用者向けタイトルから安定したASCII風キーを作ります。
ローカリゼーションQAは画面上は同じに見える二つのエクスポートを比較しますが、双方をNFDに揃えるまで等価テストは失敗します。フォントとシェーピングの技術者は、マーク付着とグリフ置換のデバッグ時に分解列を検査します。
セキュリティレビュー担当は、許可リスト検査の前にユーザー名とドメインラベルを正規化し、一方の形だけを列挙したフィルタを事前合成と分解の類似文字がすり抜けないようにします。下流が保存形としてNFDを文書化している場合、データ移行ジョブはNFC寄りレガシーコーパスをNFDへ変換します。
プログラミング講座は、NFD後に一つの見た目の文字が二つのコードポイントになり得ることを示して符号化を教え、専用の正規化ランディングはその検索意図を一般的なUnicodeコードポイント変換やBase64ツールに埋もれさせるよりよく満たします。
合成や互換折り畳みが必要なときは別のNFCまたはNFKCツールを選び、本ページはUnicode NFD正準分解と、テストとパイプラインで信頼できる決定的な正規化文字列を特に必要とする方を対象とします。
活用例
ダイアクリティカルを考慮した検索キー
商品タイトルとユーザークエリをNFDに分解し、結合マークを除去してアクセント非依存の検索・オートコンプリート索引を構築します。
ユーザー名とラベルの正規化
許可リストや一意性検査の前にアカウント名とラベルを正規化し、事前合成形と分解形が食い違わないようにします。
よくある質問
Unicode NFDとは何ですか？
NFDはUnicode Standard Annex 15のNormalization Form Dです。事前合成文字を基底文字＋結合文字にする正準分解を適用し、NFCへの再合成は行いません。
NFDはNFCやNFKDとどう違いますか？
NFCは分解後、可能な範囲で事前合成形へ再合成します。NFKDとNFKCは互換写像（合字、全角形など）も適用します。本ツールはNFD正準分解のみです。
textが欠落または無効な場合はどうなりますか？
欠落したtext、非文字列オブジェクト、非有限数、過大入力は拒否されます。検証失敗は課金されません。
ハングルは分解されますか？
はい。 事前合成のハングル音節はNFD下でアルゴリズムによりジャモへ分解されるため、短い韓国語テキストは同じ文のままコードポイント長が増えることがあります。
NFDでアクセントを取り除けますか？
その第一歩になります。NFDの後はアクセントが文字の後ろの別の記号になるため、検索やURL用の名前づくりでその記号を外せば、cafeでcaféが見つかります。このツール自体は分解だけで、記号は消しません。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/unicode-nfd \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"café"}'const res = await fetch("https://api.kit.forhosting.com/enc/unicode-nfd", {
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/unicode-nfd",
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/unicode-nfd", 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/unicode-nfd", 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.unicode_nfd",
"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 | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
不正または欠落した入力はinvalid_inputですぐに失敗し、悪いペイロードが誤った文字列を黙って作ることはありません。無料のブラウザツールと前払いAPIは同一の同型solve関数を共有するため、授業デモ、スクリプト、本番Webhookは常に同じNFD結果で一致します。
APIの呼び出し方と応答の読み方
必須の文字列フィールドtextを含むJSONオブジェクトを送信してください。textを省略した場合はinput、value、data、s、str、stringの別名が受け付けられ、簡易クライアントでも動作します。オブジェクト、配列、nullのtext、NaN、Infinityはinvalid_inputと明確な英語メッセージで拒否されます。文書化された最大長である六万五千五百三十六のUTF-16コード単位を超える文字列は、単一リクエストがWorkerを独占しないよう拒否されます。成功時、応答は元のtextをエコーし、resultをNFD正規化文字列、formを定数NFD、changedを通常のJavaScript文字列不等でresultがtextと異なるか、length_inとlength_outを正規化前後のUnicodeスカラー数、code_units_inとcode_units_outをUTF-16長、combining_marksを結果中の一般的な結合マークのコードポイント数、standardを短いUAX #15ラベルに設定します。成功したAPI呼び出しの料金は単位itemあたり公開基準の$0.002です。
実務エンジニアリングでNFDが現れる場面
本機能は純粋なparseエンジンのため、API料金は成功アイテムあたり公開基準の$0.002で、検証失敗は残高を消費しません。
連携の活用例
プラットフォーム横断の安定したゴールデンテスト
フィクスチャ文字列をNFDに強制し、元データが事前合成でも既に分解済みでも等価アサーションが通るようにします。
技術的な質問
料金はいくらですか？
ブラウザツールは無料でローカル実行です。APIリクエストは成功アイテムあたり$0.002で前払いKIT残高を使用し、無効入力は課金されません。