2016年12月01日

以前も話題にした、いわゆる「波ダッシュ問題」の続きで、macOSでのマッピングがわかったので、ここにまとめておく。なお、これは個人的な調査の結果であり、内容について何ら保証をするものではない。なお、丸付数字や顔文字など、JIS X 0208範囲外の文字については対象外である。

Mac OS Xの文字コード問題に関するメモ』の記事「Snow LeopardのMailはUTF-8のメールを量産する」によれば、波ダッシュなど、JIS X 0208とUnicodeの間のマッピングがシステムによって異なるいくつかの文字について、macOSでの対応は次の通りになっている。なお、ここではJIS X 0208のxy点をx-yと略記する。また、比較のため、Windows (CP932) およびLinux (glibc 2.*) のマッピングも併記する。

JIS X 0208 macOS Linux Windows
01-29 ダッシュ(—) U+2014 U+2015 U+2015
01-33 波ダッシュ(〜) U+301C U+301C U+FF5E
01-34 双柱(‖) U+2016 U+2016 U+2225
01-61 マイナス記号(−) U+2212 U+2212 U+FF0D
01-81 セント記号(¢) U+00A2 U+00A2 U+FFE0
01-82 ポンド記号(£) U+00A3 U+00A3 U+FFE1
02-44 否定記号(¬) U+00AC U+00AC U+FFE2

Linuxとの違いは、ダッシュ(―)がU+2014 (Mac) になるか、U+2015 (Linux) になるかだけだ。 JIS-Unicode間の変換表の選択についてによれば、JRE 1.4.0以降のJavaでのEUC_JPのマッピングが、このmacOSと同じ方式になっている(それ以前はLinuxと同じ)。 Javaについては、資料によればEUC-JP関係のマッピングが3種類あるが、EUC_JP_LINUXのマッピングはLinux式だろうから(まさか「残念、cp51932でした」とは言うまい)、あとはEUC_JP_Solarisがわからないだけ。しかし、EUC_JP_Solarisは別名がx-eucJP-Openなのだから、まあ見当は付く。 波ダッシュ問題についての調査の現状は以上の通り。

2016-12-26追記

Oracle SolarisのLive DVD版を起動しiconvを実行して、ざっと調べてみたところ、次のようになっている:

  • SolarisのEUC-JPはeucJP-openそのもので、特に拡張はされていない。
  • マッピングは、JIS X 0208の1区については、Linuxのものと同じ。

その他は標準的なものだとすれば、NEC特殊文字、IBM拡張文字およびユーザー定義文字を追加すれば全体のマッピングは完成するだろう。というところで、JavaでいうEUC_JP_Solaris(別名x-eucJP-open)の内容は推測できる。(Javaでやってみればわかるだろうって? それだけのために、JDKまで導入するのは面倒すぎるのよ。今回だってSolarisのインストールまではやっていない。)

私の関心は、波ダッシュなど一部の文字のマッピングがどうなっているか、というところだけで、それについてはSolarisはLinuxと同じだったということがわかったので、この件については終わりにする。

ところで、PerlのEUC-JPの、野放図な拡張文字の山を見ると頭がくらくらする。誰が考えたのかな。JIS X 0213? それはEUC-JISX0213であってEUC-JPではないのだが。

さらに追記

Mac OS Xの文字コード問題に関するメモ』の2012-04-19の記事「iPhoneの波ダッシュと全角チルダ」によれば、iPhoneでは波ダッシュ(U+301C)と全角チルダ(U+FF5E)の両方が簡単に入力可能だそうで、そのくせ両方が混じっているとメールが化けるのだそうな。 さらに、同ブログの別記事をいろいろ見てみたところでは、

  • charset=CP932が出現するのは、SoftBank以外のiPhoneでメールを出した場合で、
  • そして、同様の場合にSoftBankではcharset=Shift_JISで送信するが、それにも問題があり、
  • さらに、化けるかどうかはメールアプリとメッセージアプリの使い方により、
  • メールの返信によって発生したり、しなかったりして、
  • それからGmailを使うか携帯キャリアのメールを使うかで現象が異なり、
  • なおかつ携帯キャリアによっても動作が違い、
  • おまけにテキストメールかHTMLメールかでも変わるということで、
もう何が何やら、常人には理解不能な世界。 iPhoneには魑魅魍魎が憑いているに違いない。つっこんでもSAN値を削られるだけなので、見なかったことにしよう。

とにかくiPhoneユーザー様におかれてましては、署名にUnicodeにしか存在しない文字でも入れていただいて、UTF-8で送信いただくのがよろしいかと(でも、やってくれないんだよなあ)。



(13:00)

2016年11月29日

さて、次はTOG/JVC CDE/Motif技術検討WG(長い)の話。CDEといいMotifといい、GUI実装の名前なのだが、やっていることは文字コードの話ばかり。なにやってんだか。……すみません。議長が悪いんです。 他にDCE WGなんてものもありました。何をやっていたのか忘れたけれど。

ここでの一番重要な仕事は、EUC-JPとUnicodeの間の変換規則を(やっと)決めたこと。といっても3種類もあるけれど。

一つはWindowsとの互換性の為に、どうしても決めるべきだったもの。これはもう、他を一切差し置いてもなんとかすべき、義務のようなものだった。

もう一つは、JISに義理立てしたもの(JIS化委員の経験者もいたし、世間様への体面もあったし)。関係者一同、誰も使わないと思ったし、実際誰にも使われなかった。でも、一つだけしか決めなかったら(そして、それがWindows対応のものだけだったら)、やはり許されなかったと思う。

最後の一つは、一番の自信作……のはずだったのだが、さっぱり使われなかった。無念。

あの文書の一番の見どころは、実はそんなところにはなくて、一つ一つの課題を取り上げ、それぞれに対して検討を加え、最終的な結論に至る過程を全て書いてしまったことにある。何を考えて、どんな案を出して、どういう理由で捨てたかまで書いてある。

なぜそんなことをしたか。結論だけ書いておしまいにするのは嫌だった。それにも増して嫌だったのは、「これは決まったことだから」といって絶対化されることだった。 新しい論点が出てくれば、それに合わせて変えられるようにしたかった。それには、何が論点だったか、どう考えたかを記録しておけば、何が足りなかったがわかり、後で再検討するのが最短で済む。そういう風にしたかった。それが成功したかどうかはわからないけれど。

(その英訳で死ぬほど苦労したのは、また別の話だ。英語にするのは最初から必須要件だった。日本語に対応するための規定を、日本語だけでしか書かないのは、90年代当時から許されなかったのだ。こんなことなら、最初から英語で書いておけばよかったのにね。)



(13:00)

前の記事ですこし触れた、UI-OSF-USLP共同発表でのテーマであるJIS X 0212補助漢字への日本語EUCの対応をめぐる話は、「補助漢字と日本語EUC」という名前の記事で以前に詳しく書いたので、そちらを参照されたい。いまやJIS X 0212補助漢字は継子扱いされ、もはや黒歴史と化している。漢字をたくさん使いたければ、中途半端なものには手を出さず、ご遠慮なくUnicodeをお使いください。もう、誰も気にしませんから。90年代の、あの大騒ぎは、いったいなんだったのでしょうね。はあ。

さて、気を取り直して、本題に移る。1993年のUI-OSF日本語環境実装規約は、UNIX APIの基本であるPOSIX標準に適用する日本語機能を定義したもの。 実装規約(プロファイル)というのは、選べるほどたくさんある標準の中から、どれとどれを選択し、オプション機能のどれを採用し、パラメタをどの範囲に収めるかを取り決め、それによって相互運用性を確保するためのもの。 POSIX国際化機能に当てはめる日本語機能は、ベンダー各社が独自仕様を実装すると移植性を確保できない。そのために共通仕様を規定するのは、一種の実装規約と考えられる。狭い意味でのロケール定義よりも広範囲の取り決めなので、ロケールという名前にはならなかった。当時の関係者には、こういう知識が共有されていたのだ。 (実際は、出来合いの枠になかなかうまく収まってくれなくて、苦しんでいるのがよくわかる。枠だけ決めても駄目だ。)

日本語EUCという観点からは、1991年に共同発表された日本語EUCをeucJPという名前に決めてしまったのが大きなところ。ここでもやっぱり0x5Cをバックスラッシュとするか円記号とするかで悩んで、例の通り玉虫色の解釈になっている(そうそう、最近Twitterで\2,500という表記を見かけました。ははははは(乾いた笑い))。当時はJIS X 0208とUnicodeの間の変換規則について、正式のものは何も決まっておらず、それについては全く言及していない。そんな話をするのは、みんな嫌だったんだよ。

ちなみに、JIS X 0208とUnicodeの間の変換規則については、1995年のJIS X 0221:1995(ISO/IEC 10646-1のJIS版)で「附属書(参考)」として公開され(なぜ参考扱いなのかというと、それは本来JIS X 0208本体で規定すべきものだから)、JIS X 0208:1997で正式に標準となった。一つ一つの文字について文字名称が規定されているが、これがISO/IEC 10646 (Unicode)の文字名称と一対一対応になっていることにより、変換規則が確定することになる。名前は重要です。

このときの検討内容について、少し面白い話を。年月日の日付を数字と記号だけで表現する方式については、日本では標準的なものはない。月日だけなら、たとえば5月27日であれば5/27のように書くのだが、年まで入れようとすると皆さん悩むらしく、2016.5/27といった珍妙な表記にお目にかかることになる。MicrosoftはMS-DOSの頃から2016/05/27という形式を使っているし、賞味期限はピリオド区切りで2016.05.27のように書く。最近はピリオド区切りが優勢のようだが、スラッシュ区切りも見かける。 しかし、月日はスラッシュ区切りの方が多いので、月日をそのままにして年月日をピリオド区切りにするとなると、整合性をどう取るのだろう。 ちなみに、国際標準ISO 8601では2016−05−27となるのだが、こちらはあまり人気がない。

同様に、マイナスの金額を円記号と組み合わせて書くときの標準的な方式はない。某大手スーパーのレジでは−¥1234のように表示され、某大手書店のレジでは¥−1234のように表示される。見ていると面白いのだが、こんなことに興味を持つのは私くらいらしい。



(12:50)

少し興味があって日本語EUCについて調べてみたところ、結構誤解が広まっており、関係者の一人として放置しておくのも不愉快なので、ここで説明しておきたい。もうずいぶん昔のことだが、いまだにあちこちで使われているし、これについて興味のある方もいらっしゃるようだ。記録として残しておくのも悪くないだろう。なお、もう当時の資料は手元になく、記憶に頼る部分も多いので、その点は了解されたい。

まずは明らかな誤りについて。

Wikipediaの誤り

2016年11月現在、日本語版WikipediaのEUC-JPの項では、「日本語EUCの定義と解説, Revision 1.7, UI-OSF-USLP共同技術資料 (1991年12月10日)」が中原康氏の著作とされており、日付が12月10日となっており、Revision 1.7とされているが、いずれも間違いである。

正しくは、著作者はUNIX International、Open Software FoundationおよびUNIX System Laboratories Pacificの3社であり、発表は12月12日であり、バージョン番号は付いていない。たしかに中原氏は筆者の一人ではあるが、それはただちに著作者であることを示すものではない。だいたい、個人の著作を3社が共同発表などするわけがないではないか。常識で考えてもらいたい。

次にバージョン番号について詳しく述べよう。この文書はこの時に発表されたものがすべてで、改訂されたことはないし、発表時にバージョン番号は付いていなかった。なぜかUnapproved Draft 1.7なるものが公開されているが、その名が示す通り正式版ではない。 1.7という番号は原案編集の都合上付けられたものであり、公開を意図したものではないのだ(Unapproved Draft 1.7が勝手にRevision 1.7になっているのも謎)。 だいたい、こんなものが部外者の手に渡っていること自体がおかしなことである。

この発表資料はUI-OSF 日本語環境実装規約 version 1.1附属書Cに全文が収録されている。こちらは正式版であり、章・節の番号の前に「C.」が付いている以外は全く同じものである。詳しくはそちらを参照されたい。

IANAの登録内容の誤り

IANA Character Set RegistryにはExtended_UNIX_Code_Fixed_Width_for_Japanese(日本語向けEUC等幅形式)なるものが登録されているが、こんなものがCoded Character Set (CCS)としてもCharacter Encoding Scheme (CES)としても使用されたことはない。

そもそも、この形式は、今でいうC言語のwchar_t型データのビットパターンとして定義されたもので、16ビット符号無し整数として使用することを想定したものである。UNIXの日本語機能が検討された際に「処理コード」として提案され、UNIX System V MNLSを含むいくつかのシステムで採用されたが、そのままファイルに書くようなものではない(そのための日本語EUCです)。ご丁寧にもビッグエンディアンで書いてあるが、そもそも内部処理用のデータであり16ビット単位で処理するものだから、バイト順は関係ない。

もちろん、wchar_tの内容に何を使うかは実装に任されており、実際、32ビット版では全然別の形式が使われている。登録するなら、ちょっとはものを調べてからにしてほしい。知らないことは罪ではないが、知りもしないことについて訳知り顔に語るのは罪深いのだ。わからないなら黙ってろ。

等幅形式がないのだから、当然、本来の日本語EUCをExtended_UNIX_Code_Packed_Format_for_Japanese(日本語向けEUC圧縮形式)と呼ぶのも間違いだ。EUC-JPがpacked formatなら、なぜEUC-KRやEUC-CNはpacked formatではないのか。本当におかしいとは思わなかったのか。小一時間問い詰めたい。

まったく、1991年のUI-OSF-USLP共同発表資料にも、1993年のUI-OSF日本語環境実装規約にも、1996年のTOG/JVCのコード変換規則にも、それについては何も言及していないのだから、どうしてそんなものが必要だと思ったのか、理解に苦しむ(念のため申し添えておきますが、これらの文書は、英語版も同時に発表されています。外国人だから知らなかったなどという言い訳は通用しません)。馬鹿は相手にしないということで黙っていたが、事実としてどうだったのか書いておかないと誤解が広まるだけなので、ここに明記しておく。



(12:30)

2015年08月21日

以前に公開されていて、リンク切れになっていたファイルが復活しました。 これは、Internet Archive: Wayback Machine に残されていたページを集めてきたものです。 ただし、すべてではなく、一部ファイルが復活できておりません。大勢に影響はないと思いますが、念のため、申し上げておきます。

復活したファイルは次の通りです。

組織名が入り組んでややこしいのですが、こういうことです。

  • Linux 関連
    • LI18NUX (Linux Internationalization Initiative) + LSB (Linux Standard Base) = FSG (Free Standards Group)
    • LI18NUX = OpenI18N (Open Internationalization Initiative)
    • FSG + OSDL = Linux Foundation
  • UNIX 関連
    • UI (UNIX International)
    • OSF (Open Software Foundation)
    • TOG (The Open Group)/JVC (Japan Vendor Council)
    • CDE (Common Desktop Environment) Technical WG

最後に、お決まりですが、これらの文書はすべて歴史的なもので、現在の有効性は保証できません。あしからず。



(18:00)

2015年04月01日

誰も期待してないとは思いますが、「WindowsでPerlを使ってUnicode処理(7)」で出てくる例のネタばらしです。全くの蛇足です。 別に知ったからといって何がどうというわけではありませんが、意味がわからなくて気持ち悪い方はお読みください。 (ネタは他にもあるだろうって? もちろん。)

前出の例ではいじってありますが、これの元ネタは某CDの曲名リストです。CDに収録された曲一式をディスク上にコピーしました。 (念のため言っておきますが、このCDは私の所有物ですので、これは著作権法上は合法な行為(私的複製)です。だいたい、こんなもの持っているやつはそういないし、欲しがるやつなんて、まずいないよ。)

ディレクトリ上の順番、つまり曲名の文字列としての順番は次に示す通り。

neta00
図1 文字順

これの一文字目の漢字の部首は次の通り。部首自体が画数順になっていること、同じ部首内で文字が画数順になっていることは、わかっていただけるでしょうか。

表1 文字と部首との対応
文字部首
人〜償の4行
情・愛
月・有

(なんでこの字がこの部首なんだって? 文句は康熙字典に言ってくれ。)

一方、これの収録された順番は次の通り。

neta01
図2 収録順

字面を見ればだいたい意味はわかると思います。

CDタイトルの「難忘的」は「忘れ難い」という意味で、曲名ではたとえば、「莫忘今宵」は「今宵を忘れないで」、「甜蜜蜜」は「甘い蜜」(そのまんま。「甜蜜」が「あまい」で、「蜜」が「みつ」)、「海韻」は「海の響き」、「何日君再來」は「あなたが帰ってくるのは、いつの日になるでしょうか」、「有誰知我此時情」は「誰か知る我が此の時の情を」(でたらめ古文風)でしょう。

ちなみに、「償還」は「つぐない」、「我只在乎你」は「時の流れに身をまかせ」、「情人的關懷」は「空港」、「冬之戀情」は「雪化粧」です。「愛人」が「愛人」なのはいうまでもなく。

※なお、このページはSeaMonkey Composerで編集し、手作業で修正しました。Netscape Navigator以来の伝統で、素直なHTMLには助かりました。



(12:00)

2014年05月28日

以前、次の記事からリンクしていた各種ファイルがリンク切れになっております。申し訳ありません。

まだ参照されている方もあるかもしれないので、入手方法をお教えします。 ただし、これらの文書は歴史的なものであり、現在ではまったく有効ではありません。 ご注意ください。

入手方法

Internet Archive: Wayback Machineに行き、次のURLを入力してください。

http://www.li18nux.org/~numa/

いくつか、過去に公開されていた版が残っているようですが、最新版を選べばよいでしょう。

Internet Archiveに残された記録に直接リンクするのは嫌なので、こうしております。あしからず。

他のURLでは記録されていないようなので、こちらをご利用ください。なお、これは将来の入手性を保障するものではありません。

# 本当は、もう少しフォーマルなところに置いてほしいものですが。

余談:当時からシンボルマークは同じペンギンちゃんです。進歩がない。 最近は地球を抱いてはおりません。 かわりに亀甲縛りになっていたりしますが。



(18:00)

2014年05月26日

友松直之監督のブログの記事に勉強させられる点が多かったので、ここで少し考えてみる。

なお、この記事は(大胆というか、無謀というか)ピンク映画館に1人で入る女性客が何を覚悟すべきかという点を、当の女性客とピンク映画監督が議論している内容である。 詳しくはリンク先を参照すべきではあるが、なにしろとんでもなく長いし、文脈を理解するにはかなりさかのぼって記事を読む必要があるし、ピンク映画館という特殊な空間における常識*1についての知識が必要でもあるので、ここでは一般に適用可能な部分だけを引用する。 なお、「お竜さん」というのは議論の相手である女性客の名前である。

*1
当然ながら、場によって許されること、許されないことは変わってくる。 一般には許されないことでも、ピンク映画館では許されることはあるのだ。 たとえば、人前で全裸になることは一般常識では許されないことだが、ストリップ劇場では、それがなければ成り立たない。 このように、特殊な場においては、何が常識とされるかが違っているのは当然なのだ。

「友松直之のブログ」内の記事「お竜さん通信 其の七「囚われの淫獣」他、俺組OPピンク映画DMM-R18で配信開始!」から引用:

(前略)

  • 無能を理由に努力を放棄するのは怠慢です。
  • 作品鑑賞に理解は無用ですが、相互理解を目標とした対話の場では、相手の意見をしっかりと吟味し、能力の有無に関わらず最大限の努力をもっての理解が必要となります。
  • 文章を発表すればそれは表現となり、批評の目にさらされます。
  • 書きたいことを書きたいように書くということは、ある一定の責任を伴います。
  • 悪口と読み取れる文章は、悪の自覚を持って書かれねばなりません。
  • 相手が傷ついたから謝る、傷つかなかったら謝らない、なぜなら私は悪くないから、という態度は自分の文章に対して無責任が過ぎます。
  • お竜さんがもっとも唾棄すべきものとする「人の顔色を伺う」ことは、コミュニケーションの基本であり、それほど悪いことではないと思われます。
  • 特に悪口の自覚と、悪を背負う覚悟がないなら、「人の顔色を伺」って、読む人を不快にしない文章を心がけるのも立派に大人の態度でしょう。
  • 反論が来るだろうと自分で予想可能な、特定の個人に対して挑発的だと自覚できる文章をネット上に放置したら、当然反論があります。

(中略)

  • 相互理解を目標とした対話の場において、相手の意見を理解しようと努めるべきと書きましたが、当然相手に理解してもらえるよう努めることも大切なことです。
  • 悪は、悪の自覚を持ってなされなければなりません。

(中略)

  • 正義とは悪を背負う覚悟のことを言います。そこに安易な投影や私怨が入り込む隙はありません。

(後略)

書いたものを公表することには責任が伴う、対話においては相手の意見を理解すべく努めるべきであり、また自分の意見は相手に理解してもらえるよう努力すべきである。 まったくその通りではあるが、できていないこと多い。自戒せねば。 「無能を理由に努力を放棄するのは怠慢です。」ということなので。

「悪口と読み取れる文章は、悪の自覚を持って書かれねばなりません。」「悪は、悪の自覚を持ってなされなければなりません。」これは至言。 自覚のない悪がどれほど厄介なことか。 悪意なく人を傷つける連中は、悪意を持って人を害する連中よりも数段たちが悪い。「悪気はなかった」と言えば許されると思っている。悪気があろうとなかろうと、やられた側にとっては変わらないのだから。 「無能で十分説明がつくことを、悪意と解釈すべきではない」とは言うものの、世の中には自分の無能を正当化するやつまでいるからなあ。

「正義とは悪を背負う覚悟のことを言います。そこに安易な投影や私怨が入り込む隙はありません。」 これは、ここの文脈では、一面で正義とみなされることが他面では悪になり得るということだろう。 絶対の正義なんてものはあり得ず、正義は常に一面的・相対的なものにならざるを得ない。 正義を主張するものには、その裏にある悪を認識し、それに対する責任を持つべきである。 そして、たとえ一面的なものであったにしても、正義を振りかざす以上は、そこに個人的な感情を持ち込むことはできないのだと。
まあ、正義を名乗るやつらは、たいてい胡散臭いってのもあるが。

……もともとはピンク映画の話だったのに、ここまで深い話になるとは。 監督恐るべし。

なお、ここにおける解釈は私個人によるものであり、原著者の認識とは必ずしも一致しない。また、部分的な引用によって誤解を招く可能性があるが、その責任は引用者にある。以上を明記しておく。



(12:30)

2014年03月28日

MacではNormalization Formが違うというので調べてみた。資料によれば、MacのHFS Plusファイルシステムでは、ファイル名は基本的にDecomposedを使うが、一部はDecomposeしない。その範囲は次のとおり:

  • U+2000−U+2FFF
  • U+F900−U+FAFF
  • U+2F800−U+2FAFF

U+2000−U+2FFFは、各種記号類(としかいいようがないような、雑多な文字。丸付数字やローマ数字や罫線素片も入っている。温泉マーク♨もあれば、はぁとまあくもあるよ♡)が入っていて、U+F900−U+FAFFおよびU+2F800−U+2FAFFは互換漢字になっている。たしかに、下手な変換をするとややこしそうなところではある。

注意:
UnicodeのNormalization(正規化)には、互換文字として正規の文字とは別に定義されている文字は、正規文字の方に変換するというルールが(少なくともNFC/NFDには)あり、その変換によって記号類や互換漢字のコードポイントが変更されてしまう。Mac特有のNormalizationは、それを避けるためのものである(いっぺん変換して、元に戻そうとするともどらない、というのは困りますから)。

で、それを処理するためにPerlではUnicode::Normalize::Macというモジュールがあって、 これを使えばNFC_mac()およびNFD_mac()という関数でMac特有のNormalizeができる。 Encode::UTF8Macというモジュールはこれを内部的に呼び出して、Encodeモジュールで利用できるエンコーディングにutf-8-macを追加する。

注意:
これは、utf-8-macという特別なエンコーディングがある、という意味ではない。エンコーディングとしては通常のUTF-8と同じである。ただ、変換モジュールでは、変換のためのエンコーディング名を指定する必要があるため、この名前を決めたものである。

説明を読む限りではファイル名だけに適用するように読めるけれど、ではファイル名以外のテキストデータはどうなっているのだろう? ファイル名がutf-8-macなら、ファイルの中身も同じになるというのが常識的だと思うが。

……調べてみたが、よくわからない。次のような情報は見つかった。どこまで正しいかは知らないので、鵜呑みにしないように。

  • NFC/NFD/...を変換するAPIは標準提供されている
  • システムAPIは入力としてNFD/NFCを両方受け付け、正しく処理できる。
  • ファイル名を返すAPIはNFD-macで返してくる。
  • キーボード入力はNFCである。
  • ファイルコンテンツはNFCであると主張する文書もある。

関連記事として「macOS/Linux/Windowsでの波ダッシュ等のマッピング」を書きました。こちらは、Mac/Linux/Windowsでの違いについて調べたものです。ご参考まで。






さて、ではWindowsのNTFSはどうなっているか、試してみた。といっても、「がぎぐげご.txt」という名前のファイルをNFDおよびNFCで作っただけ。結果は、驚くほどのことではないが、両方ともできてしまった。コンソールでdirコマンドを実行したら、NFDの方は「か゛き゛く゛け゛こ゛.txt」のような表示(濁点が違和感のある位置)になる。エクスプローラーで見るとどちらも同じに見えるので、同じ名前のファイルが2つ並ぶという、ありえない世界ができあがる。とにかくNTFSはNormalizationをしていない。入力方式がNFCしか生成しないから、たまたまそちらに統一されているように見えるだけ、というところか。

ちなみに、NFDのファイルに対してエクスプローラーで「名前の変更」を試してみると、Backspaceの1回で濁点が消え、2回で仮名が消えるという動作をする(Delだと1回でまとめて消える……濁点だけ残されても困るか)。ファイル名検索では、先頭1文字だけなら両方が一致するが、2文字以上になるとNFCのみ一致する。途中の文字で検索すると両方に一致するが、NFDのファイル名は一致部分が強調表示されない。いっぽうメモ帳(notepad.exe)では、編集はエクスプローラーと同様だが、検索は何文字でも問題なく可能。面白い。



(12:30)

2014年03月24日

コンソール入出力の文字エンコーディングについて、日本語Windowsではcp932(Windows版シフトJIS)に限られるという話があるが、にも関わらず表示できてしまう文字がある、のである。

最近のWindowsの標準ファイルシステムはNTFSで、これはファイル名をUnicodeで保持しているため、日本語版であるにも関わらず、日本語以外のファイル名でも作成できてしまう。 そういうファイル名は、エクスプローラーならともかく、コンソール画面では表示されない……はずなのだが、cmd.exeさんはがんばって、他のフォントから必要な文字をとってきて、表示してみせることがある。

次の例は、コンソールでdirコマンドを実行した結果である。でっちあげでないことを示すため、少々長く引用するが見てほしい。シフトJISに存在しない文字が表示されているのがわかる。


C:\temp\test>dir
 ドライブ C のボリューム ラベルは S3A7897D001 です
 ボリューム シリアル番号は 6219-CAAD です

 C:\temp\test のディレクトリ

2014/03/06  19:03    <DIR>          .
2014/03/06  19:03    <DIR>          ..
2014/03/05  09:40                14 何日君再來.txt
2014/03/05  10:48                 8 你好.txt
2014/03/05  11:00                10 你走你的路.txt
2014/03/05  11:48                12 冬之戀情.txt
2014/03/05  10:48                10 好久不見.txt
2014/03/05  10:47                 8 您好.txt
2014/03/05  11:47                14 情人的關懷.txt
2014/03/05  09:37                14 我只在乎你.txt
2014/03/04  11:17                 6 日本語.txt
               9 個のファイル                  96 バイト
               2 個のディレクトリ  96,188,071,936 バイトの空き領域

具体的には、「你」と「您」である。これらの文字は日本語フォントに存在しないので、「□」のような表示になってもおかしくないのだが、別フォントからとってきて表示してくれるのだ。すごい。

で、まあ、表示はできるのだが、そこから先が問題だ。それらの文字を画面からコピーして、たとえばechoコマンドの引数に貼り付けることができる。Enterを押すと、たしかにその文字をそのまま画面上に表示してくれるのだが、そういうサービスができるのはcmd.exeの内部コマンドだけなのだ。

たとえば、自作プログラムに「我只在乎你.txt」のファイル名をコマンド引数として渡して、それを開こうとしても、そのプログラムに渡されてくるのは「我只在乎?.txt」という文字列だけで、もちろんそんな名前のファイルはないから、開くこともできないのだった。

ああ、見えているのに触れない。これじゃまるで、「踊り子さんには手を触れないでください」の世界ではないか。なかにはツーショットのときにどさくさ紛れで触っている爺さんもいるけど。あれ、何の話だっけ。Windowsだ。飾り窓の女とか、額縁ショーとか。違う。

さて、上の例で興味深いのはファイル名の並び順である。みごとに部首画数順に並んでいるのがわかる。NTFSさんは康熙字典がお好き、と。ちなみに、dir /onを指定して名前順に並べると、今度はJIS X 0208コードの順になる(中国語の文字はその後)。これはエクスプローラーで名前順を指定したときと同じである。エクスプローラーさんはJISがお好き。

備考:
NTFSで「短いファイル名」 (short file name) を有効にしていれば、それを使えばよい。この名前は8.3形式で、ANSI CPの文字しか含まれない。dir /xでこの名前が参照できる。


(13:00)