[1] Unicode の NFC (正規化形 C) は、 http://www.unicode.org/reports/tr15/#Normalization_Form_C で規定されている Unicode 文字列の正規形のひとつです。

NFC は、大まかには、正準分解を行った後に正準結合を行います。 これによって、ひとつの文字に複数種類の表現が対応するときに、 (Unicode 的に) 等価でもっとも短い形にすることができます。

[17] Unicode の正規形を用いるほとんどの場面では、 NFC が採用されています。

仕様書

定義

[2] 詳しい定義はこうです。 (実装はこれと同じ結果が得られるなら、他の方法を使ってもかまいません。)

  1. 原始文字列 S の正準分解を、 実装が対応している最新版の UCD の正準写像に従って生成する。
  2. 分解中の最初から最後までのそれぞれの文字 C について、次の操作を繰り返す。
    1. C が最後の開始子 L から妨害されておらず、 L と初等結合できるなら、 L を合成 L-C で置換し、 C を削除する。
  3. これによって得られた文字列 S' が S の NFC である。

[5] 仕様書:

文脈

[32] 一般論として、 Unicode文字列は NFC とするのが好ましいと考えられています。

[33] しかし、文字列の生成者は NFC を使うべきですが、 消費者は勝手に正規化するべきではないとされています。

[50] 実際には、正規化は破壊的な操作なので、情報交換では使うべきではありません。 プロトコルが要求する場合だけに限るべきです。 正規化

NFC によるデータ破壊

[57] NFC は破壊的操作です。データが不可逆に変化します。 恒久的に保存される、または外部に送信されるオリジナルデータに適用するべきではありません。 Unicode正規化

変種

[56] KS X 1026-1

[66] Encode-MAB2/lib/Encode/MAB2.pm at master · andk/Encode-MAB2 · GitHub, https://github.com/andk/Encode-MAB2/blob/master/lib/Encode/MAB2.pm#L102

デマ

[64] 普通のUnicodeはNFCなのか – ものかの, , https://tama-san.com/unicode-nfc/

「普通のUnicodeはNFC」というおかしな風説が流布されています。

「普通のUnicodeはNFC」と同様の風説に「WindowsはNFC」があります。

NFC を採用するプロトコル

[34] Web において NFC が使われる場面は、次の通りです。

[35] その他色々な場面で NFC が使われることがあります。

[65] ファイル名も参照。

[58] Unicode正規表現は実装が入力に適用してもいいとしています。

[4] 第18版 (Unicode 3.0 に対応) UTR #15-18 を採用する応用仕様:

[3] 第18版 (Unicode 3.0 に対応) UTR #15-18 と正誤表2 Cor. #2 を採用する応用仕様:

[6] 最新版を採用する応用仕様:

[7] RFC 5335 (電子メイル頭部の国際化) は、 RFC 5189 を参照しつつ、 NFC を推奨しています。 (名無しさん)

[8] (RFC 5335 4.1)

[9] NFC FAQ ‎(Macchiato)‎ ( 版) http://www.macchiato.com/unicode/nfc-faq

This really depends on the kind of text involved. For example, according to data at Google:

Of course, this represents data from just a sample of the web (in this case, the total characters in 700,000,000 documents as of January 23, 2009). Proportions may differ somewhat depending on which sample is chosen, and may change over time as the percentage of languages on the web changes. Normalization is important for some languages like Vietnamese and other languages of South and Southeast Asia even though their percentage of total text is small.

[10] ECMAScript Language Specification (HTML version) ( 版) http://bclary.com/2004/11/07/#a-6

[11] ES3 は UTR#15 の「1998年版」 (Unicode 2.1 世代) を引用し、 ソース・テキストは NFC で正規化されていることが期待されているが、 適合ECMAScript実装が正規化することは必須ではない、としています >>10。

必須ではない、ということはしてもよい、ということになります。

[61] RFC 4329 は JavaScript のプログラムは NFC であることが期待されるexpected、 正規化されていないとセキュリティー的危険が伴うので注意必須、 としていました >>60。 16年越しに改訂された RFC 9239 もそのままでした >>59。

[62] 明記されていませんが、期待されるとは ES3 に従ったものかと思われます。

[12] Web Applications 1.0 r7195 Revert r6810 since it doesn't work. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7194&to=7195

[13] [DRAFT]Near Field Communications Working Group Charter ( ( 版)) http://www.w3.org/2012/05/nfc-wg-charter.html

[14] XML Encryption Syntax and Processing Version 1.1 ( ( 版)) http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/#sec-EncryptedType

[15] XML Encryption Syntax and Processing Version 1.1 ( ( 版)) http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/#sec-Processing-Encryption

[16] XML Signature Syntax and Processing Version 1.1 ( ( 版)) http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/#sec-c14nAlg

[18] XSLT and XQuery Serialization 3.0 ( ( 版)) http://www.w3.org/TR/xslt-xquery-serialization-3/#uri-escaping

[19] Character Model for the World Wide Web 1.0: Normalization ( ( 版)) http://www.w3.org/TR/charmod-norm/#sec-UnicodeNormalized

[20] Extensible Markup Language (XML) 1.1 (Second Edition) ( ( 版)) http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-CharNorm

[21] Charmod でUnicode正規化済みUnicode-normalizedとは NFC のことをいいます >>19, >>20。 NFC とマーク付け言語の構造の組み合わせにより取り込み正規化済み、 完全正規化済みという正規化の形が定義されています。 XML 1.0 と XML 1.1 は構文解析対象実体が完全正規化済みであるべきとしています。

[22] RFC 5335 - Internationalized Email Headers ( ( 版)) http://tools.ietf.org/html/rfc5335#section-4.1

[23] RFC 6532 - Internationalized Email Headers ( ( 版)) http://tools.ietf.org/html/rfc6532#section-3.1

[24] RFC 6570 URI Template は Unicode 6.0.0 NFC を採用しています。

[25] RFC 5198 Net-Unicode

[26] RFC 7542 - The Network Access Identifier ( 版) https://tools.ietf.org/html/rfc7542#section-2.1

[27] 基本認証の charset="" の値 UTF-8

[28] RFC 7542 - The Network Access Identifier ( 版) https://tools.ietf.org/html/rfc7542#section-2.1

Strings that are not Normal Form Composed (NFC)

are not valid NAIs and SHOULD NOT be treated as such.

[29] Open Publication Structure (OPS) 2.0.1 v1.0 ( 版) http://www.idpf.org/epub/20/spec/OPS_2.0_latest.htm#Section1.3.6

To aid Reading Systems in implementing consistent searching and sorting behavior it is required that Unicode Normalization Form C (NFC) be used

[30] Model for Tabular Data and Metadata on the Web ( 版) http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/#encoding

CSV files should be encoded using UTF-8, and should be in Unicode Normal Form C as defined in [UAX15].

[31] RFC 7564 - PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols ( 版) https://tools.ietf.org/html/rfc7564#section-5.2.4

In accordance with [RFC5198], normalization form C (NFC) is

RECOMMENDED.

[40] XSLT and XQuery Serialization 3.1 () https://www.w3.org/TR/2017/REC-xslt-xquery-serialization-31-20170321/#uri-escaping

[41] 159891 – [encoding] Support for GB18030 () https://bugs.webkit.org/show_bug.cgi?id=159891

[42] XLIFF Version 2.0 () http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html#slr_storage

[43] Dropbox - Core API - endpoint reference () https://www.dropbox.com/developers-v1/core/docs

Every string passed to and from the Dropbox API needs to be UTF-8 encoded. For maximum compatibility, normalize to Unicode Normalization Form C (NFC) before UTF-8 encoding.

[44] RFC 8162 - Using Secure DNS to Associate Certificates with Domain Names for S/MIME () https://tools.ietf.org/html/rfc8162#section-3

If the local-part contains any non-ASCII characters, it SHOULD be

normalized using the Unicode Normalization Form C from [UNICODE].

Recommended normalization rules can be found in Section 10.1 of

[RFC6530].

[45] UTS #22: CharMapML () http://www.unicode.org/reports/tr22/tr22-8.html#att_u

Where possible, this should be in Normalization Form C.

[46] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile () https://tools.ietf.org/html/rfc5280#section-4.2.1.4

[47] rdf:XMLLiteral

[48] 215970 – Remove NFC normalization when submitting forms and encoding URL queries and fix EUC-JP encoding () https://bugs.webkit.org/show_bug.cgi?id=215970

[52] ヘルプ:異体字 - Wikisource (, ) https://ja.wikisource.org/wiki/%E3%83%98%E3%83%AB%E3%83%97:%E7%95%B0%E4%BD%93%E5%AD%97#%E3%83%97%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%83%BB%E4%BF%9D%E5%AD%98%E6%99%82%E3%81%AB%E5%88%A5%E3%81%AE%E5%AD%97%E4%BD%93%E3%81%AB%E5%A4%89%E3%82%8F%E3%82%8B%E6%96%87%E5%AD%97%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99

入力した文字がCJK互換漢字(U+F900 - U+FAFF)及びCJK互換漢字補助(U+2F80 - U+2FA1)(以下まとめてCJK互換漢字と呼びます)の場合、プレビュー・保存等を行った場合、MediaWikiの仕様により、UnicodeのC型正規化(NFC)を行い、CJK統合漢字に分解(変換)されます。例えば「神」と入力した場合、プレビューや保存をすると「神」に正規化されます。

[53] Non-Cognate 互換漢字一覧表 (, ) http://kanji-database.sourceforge.net/variants/non-cognates.html

本表は、大漢和辞典・康煕字典などで別字(non-cognate)とされているUCS互換漢字の一覧を示します。

[54] hcl/spec.md at main · hashicorp/hcl · GitHub, https://github.com/hashicorp/hcl/blob/main/spec.md#primitive-types

HCL は string (文字列) 型の equal (等価性) の判定に NFC を採用。

[55] eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01, , http://docs.oasis-open.org/xacml/3.0/errata01/os/xacml-3.0-core-spec-errata01-os-complete.html#_Toc297001140

[63] Canonical JSON (OLPC)