そもそも日本がISO/IEC 10646第5版のドラフトに反対票を投じてまで統合を求めたのですよね。
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg46/IRGN2146CDof5thEdition.pdf#page=20
U+2339Fに対してMJ037911の字形でhorizontal extensionを提出すべきものではないですか。

とりあえずグリフウィキでU+32FFを表示するためだけのフォントを生成してみました。Firefoxではインストールして再起動するだけで表示できましたが、Chrome、Edge、IEはフォントを明示しないとダメっぽいです。

あとフォントの作り方が悪いのか表示環境が悪いのかは不明ですが、縦書きはうまく表示できませんでした。

https://www.unicode.org/versions/Unicode1.0.0/CodeCharts2.pdf#page=188
https://www.unicode.org/versions/Unicode1.0.0/CodeCharts2.pdf#page=191
https://www.unicode.org/versions/Unicode1.0.0/ch06.pdf#page=131
確かにU+337Bはコードチャートに載っているのにマッピングテーブルにはありませんね。

U+337BのソースはMacJapaneseの0x87E8だと思っていましたが、少なくとも『Unicode 1.0』は裏付けになりませんね。

タレコミ「検索トラフィックが44％も減少」
ストーリー「有料会員数が4倍に」

どっちも偏向がひどい

Build 14986が来たので、動作を確認してみた。

CreateSymbolicLinkはblog記事通り、SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATEフラグの指定が必要になった。開発者モードが無効だとフラグを指定してもERROR_PRIVILEGE_NOT_HELDになる。

なおCreateSymbolicLinkを使わずFSCTL_SET_REPARSE_POINTで直接シンボリックリンクのデータを書き込んで作成することは従来通り可能で、開発者モードが有効なら特権も不要になっていた。こちらの方法で作成する場合、特権は持っているだけではダメで自分でAdjustTokenPrivilegesで有効にする必要があったから、SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATEフラグは内部的に特権の有効化をスキップしているのだろう。

Build 14972以降とか言われても、まだ(PCでは)Insider Preview出てないだろ! と思ったが、窓の杜の情報によるとBuild 14971ですでにサポートされていたらしいので試してみたところ、たしかに開発者モード有効なら特権不要でシンボリックリンクを作成できた。それどころかBuild 14965ですでにサポートされていたようだ。Build 14393 (Anniversary Update)ではまだ特権が必要だったことも確認。

なおSYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATEフラグはBuild 14971でもまだ実装されていないらしく、フラグなしで普通に作成できた一方、フラグを指定するとERROR_INVALID_PARAMETERになった。Build 14972でわざわざフラグを追加したということは、互換性に問題が出たのだろうか(ERROR_PRIVILEGE_NOT_HELDになることを期待するアプリか何かがあったとか)。

あと「Windows 7では特権不要だった」「Windows 8/8.1では特権不要だった」「mklinkが自主規制していただけ」等々の怪情報が飛びかっているので念のため確認しておいたが、やはりWindows 7でもWindows 8.1でもCreateSymbolicLink関数を直接使っても特権は必要だった(Windows 8は環境がないので未確認)。

95329033とUCSの対応はどうするのがよいとお考えですか?

1. U+20089のまま(U+E817をGB18030で表せなくなる)
2. U+20089のままで、U+E817を表す4バイト符号を追加(U+20089の重複符号化)
3. U+E817と入れ替え(JIS83の悪夢再び。まあA8BCをGB18030-2005で入れ替え済みだけど)
4. その他

いらっしゃいませ。某所ではお世話になりました。

# とりあえずなりすましではないと仮定して

> #Windows8.1やMac OS X 10.10で動く、鮪に対応したビューワってあるのかな？
JavaScriptでサクッとでっちあげてみました。MacがないのでSafariで動作確認できていませんが、とりあえずFirefox、Chrome、IEの最新バージョンでは動いているようです。
http://emk.name/2015/03/magjs.html
昔はアセンブラで書かないとまともなスピードが出なかったり640KBのメモリで動くように書かなければいけなかったりしたものですが、今では仕様書の通り素直に実装するだけでいいのだから、楽な時代になったものです。

VistaからOSはIVSに対応とか書いてあるのを見たんですが、そう簡単にはいかないのですね。

どこでご覧になったのかわかりませんが、VistaはIVSによる字形切り替えに対応していません。IVSをちゃんとDefault Ignorableな文字として描画する(というか描画しない)という意味では対応していますから、「IVSに対応」と書かれていたこと自体は間違いではないのかもしれませんが、ちょっと誤解を招きそうですね。

http://glyphwiki.org/wiki/User:emk
IPAex明朝2.01から、Default UVS Tableを使うようになっていますね。1.03までは使っていなかったのですが。Windows 8ではメモ帳やIE11などでも字形切り替えが効いたので、このバグは直っているようです。FirefoxはOSの機能に頼らず独自にIVS対応を行っているため、Windows 7でもXPでも字形切り替えが効きます。
Chromeは少なくとも現バージョンでは字形切り替えを効かせることができませんね(IPAexのみならずWindows 8付属のMS明朝でも)。昔試したときはできたような気がするのですが…。

あとUTS#37の定義

An Ideographic Variation Sequence (IVS) is a sequence of two coded characters, the first being a character with the Unified_Ideograph property, the second being a variation selector character in the range U+E0100 to U+E01EF

によると<U+5140 U+FE00>や<U+5C22 U+FE00>や<U+66F8 U+FE00>をIVSと呼ぶのは正しくないような気がします。

「兀」と「兀」が両方ともU+5140、「尢」と「尢」が両方ともU+5C22 (ついでに言うと2日前の「書」と「書」も両方U+66F8) になっているのは意図的なのでしょうか。

http://blog.livedoor.jp/numa2666/archives/52344853.html
> Mac OSはNFD、WindowsはNFC。
Mac OSのファイル名は互換漢字を分解しない独自の正規化形式です。Windowsのファイル名に正規化の概念はありません。たまたま合成済み文字で入力されることが多くてそれを素通ししているだけです。
この文脈でのNFD/NFCは「漢字イン」とか「サニタイズ」とか「DNS浸透」並みのNGワードなのでご注意。Unicode::NormalizeではなくEncode::UTF8Macを使いましょう。

http://blog.livedoor.jp/numa2666/archives/52344855.html
世の中にはJPerlをこきおろしつつ(しかも「国際化に対応できない」とかなんとかもっともらしい理屈をつけて)、openに渡すファイル名の変換はcp932決め打ちとかいうちょっと意味のわからない「モダンPerl流」の紹介文書があふれているので、Encode::Localeが出てきて安心しました。
まあANSI CPにない文字を含むファイル名を扱うならWin32::UnicodeかWin32::LongPathを使うかWin32::APIでゴリゴリやるしかないんですが。

http://blog.livedoor.jp/numa2666/archives/52344856.html
C++ならGetCommandLineWとCommanLineToArgvWでUnicodeのコマンドラインを直接取得できます。PerlモジュールではWin32::Unicode::NativeにUnicodeコマンドライン取得の機能があります。あるのはいいのですが、このモジュール他にも副作用がいろいろあるのが困ります。ほしいのはコマンドライン取得の機能だけなのに。なにかいい方法はないでしょうか(なぜか逆質問)。