無料WEBツールdigtoooooools

by 大阪のホームページ制作会社digrart

Macの濁点分離を即修復！Unicode正規化ツール(NFC変換)

🔧
貼り付けるだけで即修復

ワンクリックで濁点分離を解消

🍎
Mac濁点問題に完全対応

NFD→NFC自動変換

🔒
完全ブラウザ処理

テキストはサーバーに送信されません

⚡
外部ライブラリ不要

ブラウザ標準機能のみで動作

文字数: 0 | NFD検出: 0箇所
macOSのファイル名はUnicode NFD形式
macOS（旧HFS+およびAPFSファイルシステム）では、ファイル名のUnicode表現にNFD（Normalization Form Canonical Decomposition：正規分解形式）が使用されます。 これにより、「が」のような濁点付き文字が「か」+「゛」（結合済み濁点 U+3099）の2つのコードポイントに分解されて格納されます。同様に「パ」は「ハ」+「゜」（結合済み半濁点 U+309A）に分解されます。
WindowsやLinuxはNFC形式を使用
一方、WindowsのNTFS、LinuxのExt4など多くのファイルシステム、そしてWebサーバーではNFC（Normalization Form Canonical Composition：正規合成形式）が一般的です。 NFCでは「が」は1つのコードポイント（U+304C）で表現されます。見た目は同じでも、内部のバイト列が異なるため、ファイルの検索・比較・共有で問題が発生します。
「見えない文字化け」の危険性
NFDとNFCの文字は画面上では同じように表示されることが多いため、問題に気づきにくいのが厄介です。ファイル名の検索でヒットしない、Gitで同じファイルが重複表示される、Webフォームのバリデーションが通らない — これらはすべて「見えないUnicode正規化の不一致」が原因である可能性があります。
NFCとNFDの具体的な違い（コードポイント比較）
「が」をNFCとNFDで比較すると、次のようになります。NFC: U+304C（1つのコードポイント、3バイト）。NFD: U+304B（か）+ U+3099（結合濁点）の2つのコードポイント（6バイト）。見た目には同じ「が」ですが、バイト列が異なるため、プログラムで文字列比較すると不一致と判定されます。
クラウドストレージでのファイル共有
Google Drive、OneDrive、Dropboxなどのクラウドストレージを介して、MacユーザーがアップロードしたファイルをWindowsユーザーがダウンロードすると、日本語ファイル名の濁点が分離して表示されることがあります。「報告書.pdf」と名前を付けたファイルが「報告書.pdf」と表示されるなど、見た目は正常でもファイル検索でヒットしないケースが発生します。
ZIPファイルの送受信
Macで日本語ファイル名を含むZIPを作成し、Windowsで解凍すると、ファイル名の濁点・半濁点が分離して「か゛」「は゜」のように表示される場合があります。これはZIPファイル内のファイル名がMacのNFD形式で保存されているためです。特にmacOS標準のアーカイブユーティリティで作成されたZIPで頻発します。
Git管理のファイル名
MacとWindowsの開発者が同じGitリポジトリで作業する場合、日本語ファイル名の正規化形式の違いにより、存在するのに見つからないファイルや意図しない変更差分が表示されることがあります。Git自体にはUnicode正規化に関する設定（core.precomposeunicode）がありますが、完全に解決できないケースも多いです。
メール添付やNAS・ファイルサーバーでの共有
メールの添付ファイルやNAS（ネットワーク接続ストレージ）上のファイルも同様の問題が発生します。特に企業のファイルサーバーでMacとWindowsが混在している環境では、日本語ファイル名のトラブルは日常的に発生しています。
DTP・印刷業界でのデータ受け渡し
デザイン業界ではMacの使用率が非常に高く、制作データをWindows環境のクライアントに納品する際に問題が起きます。フォルダ名に含まれる「デザイン」「プレゼン」「ページ」などの濁点・半濁点付き文字が分離し、納品データが開けないというトラブルに繋がります。
Webフォームからのファイルアップロード
Macユーザーが日本語名のファイルをWebフォームからアップロードする際、サーバー側でNFC正規化を行わないと、データベースにNFD形式のファイル名が保存されます。その後Windowsユーザーがダウンロードしようとするとファイルが見つからない、というバグの原因になります。
NFC（Canonical Composition）— 推奨
正規合成形式。分解された文字を可能な限り合成（結合）します。Mac濁点分離の修復にはこの形式を選びます。WindowsやLinux、多くのWebアプリケーションで標準的に使われる形式で、日常的な用途では最も適しています。W3C（World Wide Web Consortium）も、Web上のテキストにはNFCを推奨しています。
NFD（Canonical Decomposition）
正規分解形式。合成された文字を基底文字＋結合文字に分解します。macOSの内部形式です。意図的にMac互換の形式に変換したい場合や、テキスト処理で文字の構成要素を分析したい場合に使用します。言語学的な分析や、アクセント記号の除去処理の前段階としても利用されます。
NFKC（Compatibility Composition）
互換合成形式。NFCの処理に加えて、互換文字の統一変換を行います。全角英数字→半角（Ａ→A、１→1）、丸囲み・括弧付き文字の展開（㈱→(株)、①→1、㍉→ミリ）、リガチャの分解（fi→fi）、上付き・下付き文字の正規化（²→2）など。テキストの正規化と統一に最適です。検索エンジンのインデックス処理でも広く使われています。
NFKD（Compatibility Decomposition）
互換分解形式。NKFCと似ていますが、最終的な合成を行わず分解したままにします。テキスト分析、検索エンジンのインデックス作成、文字の同一性判定など、技術的な用途で使用されます。アクセント記号を除去して「ラテン文字の骨格」だけを取り出す処理にも使われます。
正規化形式の選び方まとめ
Mac濁点修復: NFC。テキスト整形・全角半角統一: NFKC。Mac互換形式に変換: NFD。テキスト分析・検索: NFKD。迷ったらNFCを選択すれば、ほとんどの場合で問題ありません。
Unicode（ユニコード）
世界中の文字を統一的に扱うための文字コード規格です。日本語の漢字・ひらがな・カタカナ、英数字、絵文字など、約15万文字にそれぞれ固有の「コードポイント」（番号）が割り当てられています。例えば「あ」はU+3042、「A」はU+0041です。ISO/IEC 10646として国際標準化されています。
コードポイント（Code Point）
Unicode上での文字の識別番号です。「U+」に続く16進数で表記されます。例: U+304C（が）、U+3099（結合濁点）。1つの「見た目の文字」が複数のコードポイントで構成される場合があり、これが正規化問題の根本原因です。
NFD（Normalization Form Canonical Decomposition）
正規分解形式。合成済みの文字を「基底文字＋結合文字」に分解する正規化形式です。macOSがファイル名に使用する形式として知られています。例: 「が」（U+304C）→「か」（U+304B）+「゛」（U+3099）に分解されます。
NFC（Normalization Form Canonical Composition）
正規合成形式。分解された文字を可能な限り結合・合成する正規化形式です。WindowsやLinux、Webで最も広く使われる形式です。例: 「か」+「゛」→「が」（U+304C）に合成されます。W3CがWeb上のテキストの標準形式として推奨しています。
NFKC（Normalization Form Compatibility Composition）
互換合成形式。NFCの処理に加え、互換文字（全角英数字、丸囲み数字、リガチャ等）を標準的な文字に変換します。例: 「Ａ」→「A」、「㈱」→「(株)」、「fi」→「fi」。テキストの統一・検索に有用です。
NFKD（Normalization Form Compatibility Decomposition）
互換分解形式。NKFCの互換変換に加え、合成せず分解したままにします。テキスト分析やインデックス処理に使用されます。
結合文字（Combining Character）
単独では表示されず、前の文字に「結合」して表示される特殊な文字です。濁点（U+3099）や半濁点（U+309A）のほか、アクセント記号（例: U+0301 = ́）なども結合文字です。NFD形式では、こうした結合文字が基底文字から分離されて保存されるため、文字数が増加します。
基底文字（Base Character）
結合文字と組み合わせて使われる「主たる文字」です。例えば「が」をNFDに分解した場合、「か」が基底文字、「゛」が結合文字となります。
濁点（Dakuten / Voiced Sound Mark）
日本語の清音を濁音に変える記号です。Unicodeでは、結合濁点（U+3099: COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）と非結合濁点（U+309B: KATAKANA-HIRAGANA VOICED SOUND MARK）の2種類が存在します。Mac濁点分離で問題となるのは結合濁点（U+3099）です。
半濁点（Handakuten / Semi-Voiced Sound Mark）
「は行」を「ぱ行」に変える記号です。濁点と同様に、結合半濁点（U+309A）と非結合半濁点（U+309C）の2種類があります。Mac濁点分離の影響は半濁点にも及びます。
サロゲートペア（Surrogate Pair）
UTF-16エンコーディングにおいて、基本多言語面（BMP: U+0000〜U+FFFF）の範囲外の文字（絵文字や一部の漢字など）を2つの16ビット値の組み合わせで表現する仕組みです。JavaScriptの String.length はサロゲートペアを2文字として数えるため、正確な文字数には Array.from(str).length を使用します。
BOM（Byte Order Mark）
テキストファイルの先頭に付加される特殊なUnicode文字（U+FEFF）で、ファイルのエンコーディングとバイト順序を示します。UTF-8のBOMは EF BB BF の3バイトです。Unicode正規化とは直接関係ありませんが、文字化けの原因として併せて知っておくべき概念です。
ファイル名の修復例
修復前（NFD）: 「見積書_株式会社テ゛ィシ゛アート.pdf」 → 修復後（NFC）: 「見積書_株式会社ディジアート.pdf」。 濁点が分離していた「テ゛ィシ゛」が正しい「ディジ」に修復されます。
テキスト内容の修復例
修復前: 「東京タワーか゛ら見た風景は゜のらまビュー」 → 修復後: 「東京タワーがら見た風景パノラマビュー」。 文中の濁点（か゛→が）と半濁点（は゜→パ）がそれぞれ正しく結合されます。
NFKC変換の修復例
変換前: 「Ａ１２３ ㈱ディジアート ①②③」 → 変換後: 「A123 (株)ディジアート 123」。 NKFCでは濁点修復に加え、全角英数字の半角化や括弧付き文字の展開も同時に行われます。テキストデータのクレンジングに最適です。
文字数の変化
NFD→NFC変換では、結合文字が基底文字に吸収されるため文字数が減少します。例えば「がぎぐげご」（NFD形式: 10文字）は「がぎぐげご」（NFC形式: 5文字）に変換されます。文字数の差を確認することで、濁点分離が修復されたかどうかを判断できます。
JavaScript
String.prototype.normalize('NFC') メソッドを使用します。ECMAScript 2015以降の全モダンブラウザで利用可能です。ファイルアップロード処理では file.name.normalize('NFC') でファイル名を正規化してからサーバーに送信するのがベストプラクティスです。Node.jsでも同一のAPIが使用できます。
Python
unicodedata.normalize('NFC', text) で正規化できます。Webフレームワーク（Django, Flask等）のファイルアップロード処理で、受け取ったファイル名に対してNFC正規化を適用することを推奨します。Django の FileField や Flask の secure_filename() と組み合わせて使用します。
PHP
Normalizer::normalize($text, Normalizer::FORM_C) を使用します。intl 拡張が必要です。WordPressの sanitize_file_name() フィルターにNFC正規化を追加するプラグインも存在します。Laravel では Str::ascii() と組み合わせることも可能です。
Ruby
text.unicode_normalize(:nfc) で正規化できます。Ruby 2.2以降で利用可能です。Ruby on Railsでは、Active Storageのファイルアップロード処理にNFC正規化を組み込むことを推奨します。
Java / Kotlin
java.text.Normalizer.normalize(text, Normalizer.Form.NFC) で正規化できます。Androidアプリでファイル名を扱う際にも同一のAPIが使用可能です。
Go
golang.org/x/text/unicode/norm パッケージの norm.NFC.String(text) で正規化できます。ファイルサーバーやAPIサーバーの実装で活用できます。
Git の設定
git config --global core.precomposeunicode true を設定すると、macOSでGitがファイル名をNFC形式で扱うようになります。ただし、既存のNFD形式のファイル名は自動修正されないため、別途リネーム作業が必要です。.gitattributes ファイルでの制御も検討してください。
ファイルアップロード時のベストプラクティス
サーバーサイドでファイルを受け取る際には、必ずファイル名をNFC正規化する処理を入れるべきです。これにより、MacユーザーがアップロードしたファイルもWindowsユーザーが問題なくダウンロードできるようになります。データベースにテキストを保存する際も同様にNFC正規化を推奨します。
Q. 「濁点分離」は壊れたファイルですか？ 元に戻せますか？
A. ファイル自体は壊れていません。ファイル名やテキストのUnicode表現形式が異なるだけです。当ツールのNFC正規化で即座に修復できます。ファイルの中身（内容）には影響しません。
Q. なぜMacだけこの問題が起きるのですか？
A. macOSのファイルシステム（旧HFS+およびAPFS）が、ファイル名のUnicode表現にNFD（分解形式）を採用しているためです。WindowsのNTFSやLinuxのext4はNFC（合成形式）を使用しており、この形式の不一致が問題の根本原因です。Apple社の設計上の選択ですが、国際的な文字処理の正確性を優先した結果とされています。
Q. 濁点以外にも影響を受ける文字はありますか？
A. はい。半濁点（ぱ行）のほか、ヨーロッパ言語のアクセント記号付き文字（é, ñ, ü 等）も同様にNFDで分解されます。日本語では濁点・半濁点が最も影響を受けますが、多言語対応のシステムではより広範囲の文字が対象となります。
Q. NFC正規化で元のテキストの意味が変わることはありますか？
A. NFC（正規合成）では文字の意味は変わりません。見た目も同一のまま、内部表現のみが統一されます。ただし、NFKC（互換合成）を選択した場合は、全角英数字が半角に変わるなどの互換変換が行われるため、意図しない変更が生じる場合があります。通常はNFCを選択してください。
Q. このツールで変換したテキストをMacに戻しても問題ありませんか？
A. 問題ありません。macOSはNFC形式のファイル名も正常に扱えます。ファイルの読み書きに支障はありません。macOSが内部的にNFDに再変換する場合もありますが、ユーザーが意識する必要はありません。
Q. 大量のファイル名を一括で修正するにはどうすればよいですか？
A. 当ツールではテキストとしてファイル名を一括変換できます。ファイルシステム上の実際のファイル名を一括リネームするには、macOSではconvmvコマンド（brew install convmvでインストール可）や専用アプリの「FixFilename」が利用できます。
テキストに含まれるリスクのある情報
修復したいテキストには、プロジェクト名、顧客名、社内ファイル名など業務上の機密情報が含まれている可能性があります。これらをサーバーに送信するツールは、企業のセキュリティポリシーに抵触するリスクがあります。
ブラウザ標準APIで完結
当ツールで使用している String.normalize() はブラウザに組み込まれたネイティブ関数です。外部ライブラリのCDN読み込みすら不要で、ネットワーク通信は一切発生しません。入力されたテキストはブラウザのメモリ上でのみ処理されます。
企業のセキュリティポリシーへの準拠
外部サービスへのデータ送信を禁止する社内規定がある企業でも、当ツールは安心してご利用いただけます。処理はすべてブラウザ内で完結し、ページを閉じるとメモリは自動的に解放されます。ISO 27001やプライバシーマーク取得企業の情報セキュリティ管理基準にも適合します。
オフライン環境でも動作
当ツールのページを一度読み込んだ後は、ネットワーク接続がなくてもString.normalize()による正規化処理は動作します。社内ネットワークが制限された環境でも利用可能です。
画像処理・テキスト解析
WEB開発ツール
SEO対策
ネットワーク
セキュリティ
ビジネス
SNS・エンタメ
生活