10.10以降のnfc nfd問題

気がついた点をいくつか・・・

ファイル名をコピぺして，そのコードを調べたところ，

そのボリュームのフォーマットは何でしょう？

重ね文字ではないことが見つかりました．

これはどう確認したのですか？

Finder？　ターミナル？

いつ頃か，macはnfdを使わなくなったのでしょうか．

正確には「Macがnfdを使う」という表現は間違っていると思う。

HFS+が「UFT-8-MAC」を採用している、、だと思う。

今でもHFS+のFileSystemはUFT-8-MACですよ。

Tanaka_Kurochan さんの現状としては、以下は OK。

open パット.txt open abcパット.txt open ab[tab]

以下は NG。

open パ[tab]

ということですよね。ならば、当方 (Mac OS X 10.6.8 / Terminal 2.1.2) でも同様です。そういうものではないでしょうかね。

NFC の「パ: U+30D1」ではなく、

open パ[tab]

UTF-8-MAC の「パ: U+30CF + U+309A」

open パ[tab]

としてみてはどうでしょうか。当方ではこれで大丈夫です。

あと、正規化は NFD ではなく UTF-8-MAC です。両者は異なるので注意してください。

それと、HFS+ に保存されるファイル名のテキストエンコーディングは UTF-16 で、正規化は変形 NFD。いわば UTF-16-MAC？。それを UTF-8 に変換したのが UTF-8-MAC (実際はテキストエンコーディングの他に「:」を「/」に変換するとか、その他諸々) ということでしょうかね。めんどくさ〜い。

Tanaka_Kurochan さんによる書き込み:

今日とてもおかしな事象に出会いました．

大変申し訳ありませんが、書き込まれた内容が私には高度で理解できません。

とはいえ、確認させていただきたいのが「今日」遭遇とお書きですが同じOS のバージョンで遭遇しなかったことがあるのでしょうか。

ファイル名をそのテキストエディタにコピーした段階で、そのエディタが NFD を NFC に変換しているのではないですか。

実際の Normalization Form は例えば下記のスクリプトのようなもので確認すればよいです。OS X 10.6.8 で動作確認しました。

#!/bin/bash DIR=~/Desktop/nfd_name_test mkdir -p "$DIR" && cd "$DIR" || exit touch 'バット' ls | perl -CSDA -e ' use strict; use Unicode::UCD qw(charinfo); while (<>) { for (split //) { my $ci = charinfo(ord $_); my ($code, $name, $u10) = @{$ci}{qw(code name unicode10)}; printf qq([%s] U+%s %s\n), $_, $code, $u10 ? $u10 : $name; } }'

出力例

[ハ] U+30CF KATAKANA LETTER HA [゙] U+3099 NON-SPACING KATAKANA-HIRAGANA VOICED SOUND MARK [ッ] U+30C3 KATAKANA LETTER SMALL TU [ト] U+30C8 KATAKANA LETTER TO [ ] U+000A LINE FEED (LF)

HFS Plus 名は当初からの NFD (一部のコード領域で NFC を使っている変則型）で変わっていないはずです。このようなものを変えるとファイルシステムの互換性に問題が発生する。

参考文献

[1] Internationalization Programming Topics

http://web.archive.org/web/20140713204101/https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPInternational/BPInternational.pdf

cf.

Internationalization Programming Topics

> File Encodings and Fonts

> File Systems and Unicode Support

[2] Technical Q&A QA1173 Text Encodings in VFS

https://developer.apple.com/library/mac/qa/qa1173/_index.html

cf.

Technical Q&A QA1173 Text Encodings in VFS

> Precomposed versus Decomposed

参考資料としてこれも貼っておきます。

HFS+のファイル名を比較する厳密な方法

http://d.hatena.ne.jp/ytqwerty/20130208

# Apple さん BPInternational.pdf を復活してくれ〜と言ってみる。

ーーーーー

ついでに、NFD と UTF-8-MAC について。

QA1173 にあるように、HFS+ における変型 NFD (いわゆる UTF-8-MAC) では U+2000 から U+2FFF、U+F900 から U+FAFF、及び U+2F800 から U+2FAFF は (正規) 分解されません。一方 Unicode 正規化の NFD ではこの範囲も分解されるので、正規化の結果が異なります。

例えば「示偏の神: U+FA19」。この文字は NFD で正規化しても NFC で正規化しても「ネ偏の神: U+795E」に変化します。一方 UTF-8-MAC では分解されないので、「示偏の神: U+FA19」のままとなります。

ネ偏の神: U+795E

printf '%s' $'\347\245\236' | hexdump #=> e7 a5 9e

示偏の神: U+FA19

printf '%s' $'\357\250\231' | hexdump #=> ef a8 99

NFC で正規化

printf '%s' $'\357\250\231' | perl -CIO -MUnicode::Normalize -ne 'print NFC($_)'| hexdump #=> e7 a5 9e

NFD で正規化

printf '%s' $'\357\250\231' | perl -CIO -MUnicode::Normalize -ne 'print NFD($_)'| hexdump #=> e7 a5 9e

UTF-8-MAC → UTF-8

printf '%s' $'\357\250\231' | iconv -f UTF-8-MAC -t UTF-8 | hexdump #=> ef a8 99

UTF-8 → UTF-8-MAC

printf '%s' $'\357\250\231' | iconv -f UTF-8 -t UTF-8-MAC | hexdump #=> ef a8 99

なるほど。一部で勘違いしていました。

というわけで、前述の

NFD (一部のコード領域で NFC を使っている変則型）

は、誤っているので、下記のとおり

NFD (一部のコード領域で Decomposition を適用しない変則型）

に訂正します。

追記。

BPInternational と題する文書自体は今も下記のリンク

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPInternational/

にあるのですが、中身が Internationalization Programming Topcs から Internationalization and Localization Guide に変わっていて、新しい文書では Unicode Normalization に関する記述がそっくり欠落しています。又、この文書の pdf 版は前はあったのですが最近削除されました。Apple は技術文書の pdf 版をかたっぱしから削除しています。読みたい場合は、archive.org で探すしかありません。

因に、新文書の pdf 版は

http://web.archive.org/web/*/https://developer.apple.com/library/mac/documentation/macosx/conceptual/bpinternational/BPInternational.pdf

から辿れます。

$ touch バット

とした時は，，「バ」が重ね文字になっているとして，

それでは，なぜ

$ open バ+tab

とした時は，ファイル名の補完機能が働かないのでしょうか．

入力はUTF8、、、でしょうね。

でも、FileSystemにUTF8で書き込んでも、そこでUTF-8-MACに変換されて書き込まれます。

つまり、、書き込んだ時はUTF8でも、次に読み出してみたらUTF-8-MACなのです。

PS　HFS+が実際に（磁気的に？）保持するデータがUTF16だったとは初めて知りました。

　　　HFS+が開発されたとき(Copland)にUTF8なんてまだなかったと思うし、固定長のほうが便利ですものね。

　　　とても勉強になります。＞ALL

$ open バ+tab

とした時は，ファイル名の補完機能が働かないのでしょうか．この時の「バ」は重ね文字ではないのでしょうか．

「バ」をターミナルに直接入力 → E38390（UTF-8）

「バ」を Finder からターミナルにコピペ → E3838FE38299（UTF-8-MAC）

Finder では UTF-8-MAC は強制です。Finder からコピペした「バ」なら補完できるはずです。

他所で、BPInternational.pdf と QA1173 に記載の分解除外範囲が違う？なぜ？な〜んてやり取りをしたことがあります。結論は出ず。Apple に直接聞くのが一番だろうけど、面倒になっちゃいました。

BPInternational.pdf

U+2000-U+2FFF, U+F900-U+FA6A, U+2F800-U+2FA1D

QA1173

U+2000-U+2FFF, U+F900-U+FAFF, U+2F800-U+2FAFF

それはともかく、UTF-8-MAC の説明をする際は、QA1173、BPInternational.pdf、HFS+のファイル名を比較する厳密な方法は、おすすめの3点セットですね。

BPInternational.pdf には UTF-16 云々と、分解除外範囲の両方が載ってるので、とても役立つ資料だったのに、なくなってしまったのは実に残念です。

既に解決済みのようですが、このスレッドで何度も使われている UTF-8-MAC という言葉には私は非常に違和感があるので、そのことについて少しだけ。

１）Unicode Encoding Form と Unicode Normalization Form は全く別の概念である。

２）UTF-8-MAC などという Encoding Form は The Unicode Consortium で定義されていない。

３）HFS Plus で採用されている Unicode は 基本的には NFD であり、一部のコードポイント領域で NFD から逸脱している。これは Mac 版の NFD （いわば NFD-MAC）なるものがあることを意味するのではなく、単に HFS Plus の Unicode Normalization が一部で規範から逸脱していることを意味しているだけである。

４）UTF-8-MAC という名称はおそらく iconv が勝手に導入したもので、Encoding Form と Normalization Form をごちゃまぜにした不明瞭な概念である。したがって、それは UTF-8 と対比されるべき概念ではなく、又、NFD や NFC と対比されるべき概念でもない。

というわけで、便宜上使うだけなら許されるのかもしれませんが、私には UTF-8-MAC という用語は、iconv の定数として以外では使う気にはなれない、相当にいかがわしいものです。

言葉を混乱させると世界が混乱する、ということへの覚え書きでした。

確かに何の説明もなく UTF-8-MAC と書くのはまずいですね。以後気をつけます。