Windows Vistaの文字セット問題 124
ストーリー by yoosee
日本語処理は本当にややこしい 部門より
日本語処理は本当にややこしい 部門より
yejunkiee 曰く、
文字コード界隈ではよく知られている京都大学の安岡孝一助教授が、 Vistaで化ける字，化けない字、 Vistaで化ける字，化けない字（続報）という記事をITProに 書いている。 Windowsでは文字コードにUnicodeを使いながら JIS X 0213を サポートするという方式を取っており、それによって CP932, JIS X 0212, JIS X 0213もみんなまとめてUnicodeで扱うということになっているらしい。 幾つかの文字に関しては字体がXPとVistaでは異なるものが出てきているという ことで、記事ではおそらくその全てを調査しているようだ。 これを見ると、漢字データを扱うアプリの担当者は大変だろうなぁと つくづく思ってしまう。
字形の違いを「文字化け」と言うな (スコア:4, 参考になる)
勝手に「文字化け」の意味を拡大解釈した上でタイトルとして使うのはどうなのかと。この記事は XP と Vista では字形が変わるという問題だけ言っていてソリューションを一切説明していない辺りが微妙すぎます。
わざとなのか知らないのかは知りませんが (おそらく後者)、Vista で採用されている MS 明朝/ゴシック 3.2 は XP や Server 2003 にも提供されます。このため、XP 環境でも Vista と同じ字形での表示は可能となります。
さらに移行期間中の措置として、XP で採用されている MS 明朝/ゴシック 2.5 を Vista や Longhorn Server へ提供することも決まっています。このため、ソフトウェア側が対応していなくても Vista 側でも JIS90 を普通に表示することが可能です。
また、OpenType Feature Tag を利用して JIS90 のグリフで表示することも可能とされていますので、MS 明朝/ゴシック 3.2 を入れた後でも (ソフト側でしっかり制御していれば) JIS90 の字形のままということも出来ますし、JIS2000 の字形で表示する事もできます。
という話は結構前からアナウンスされているので、こうした記事を書く以上はここまでしっかり書いて欲しいのですが。続報には書くかと思っていたのですが、結局書かれていない辺りがなんとも。
おそらくこの辺りは Windows Update の推奨更新で出てくるのではないかと思いますが、この形で出てきた場合には SUS による一括配布などを利用する事で企業内でも特に問題の無い移行が行えるのではないかと思います。
文字合成に関しては「同じ扱いをしなければいけない」のは今更過ぎる話だし、MS 明朝/ゴシック 3.2 を入れることで XP 側に字形が存在していないコードポイントにも字形が入るわけで Vista と同じ扱いで構わなくなるだけ。
問題をわざと大きくしようとしているとしか見えない煽り記事でしょう。
一般ユーザの視点に立っただけでしょう (スコア:3, 興味深い)
一般ユーザの視点に立っただけでしょう。日経 IT Pro から「そのように書いてほしい」と頼まれた可能性もあるでしょうし。
安岡氏の続報には
と書いてありますから、「一切説明していない」は言い過ぎでしょう。
そもそも、日経 IT Pro では『複数の事象を混同しがちなVistaの文字問題 [nikkeibp.co.jp]』という記事を 12/15 時点で提供しており、『Windows Vistaの新文字セットが引き起こすトラブル [nikkeibp.co.jp]』という特番サイトも設置しているわけで、安岡氏が全てを説明する必要はないのです。安岡氏の記事だけを抜き出したタレコミ者と編集者には問題があるかもしれませんが。
Re:字形の違いを「文字化け」と言うな (スコア:2, おもしろおかしい)
あの・・(^^;
文字コードモヒカン族最右翼の安岡センセが知らない可能性は０．００００１％もないと思いますよ。
さらにいうと、解決策は統一的な解決策はなくて、アプリ依存になってしまうので、
適当に解決策の１つをあげて読者に間違った安心感を与えてしまうのは余計問題だと思います。
てゆーか、ここまで親切に問題点を指摘してくれたらアプリ設計の見直しぐらい自分でやれよ。とかオモタ。
＃この人の本の文字コードオタクっぷりはマジで感動するからぜひ読んでみそ。
文字コードモヒカン族 (スコア:3, 参考になる)
Re:字形の違いを「文字化け」と言うな (スコア:1)
日本語以外の環境で開発され、後に国際化され日本語も扱うようになるアプリケーションについては?
WindowsOSであっても、日本語版以外の環境に日本語を扱えるように設定するときに問題発生するのかしないのか?
しっかり制御されていないソフトに付いては今のうちから対応をはじめる必要があるのでは?
いずれの場合についても大問題になりそうですので、早めに「現状でも面倒な文字化け問題が、今後は更に拡大する」と警鐘を鳴らすことは重要なことだと思いましたが、素人判断ですかね?
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:字形の違いを「文字化け」と言うな (スコア:5, 参考になる)
Windows 以外の OS は、そもそもメイリオや MS 明朝/ゴシックといったフォントはライセンス上利用できないので、メイリオや MS 明朝/ゴシックフォント固有の話は全く関係ないのではないでしょうか。それぞれの OS 上で利用しているフォントデータが JIS78 しか対応していなければ JIS78 の字形になるでしょう。それだけのことです。
GTK+ for Win32 などは Windows 固有の部分にこうした辺りの管理を乗せるかもしれませんが、それは Windows 固有部分の話であって Windows 以外の OS の話ではありません。
日本語以外の環境で開発されて I18N 化された物に関しては、OpenType Feature Tag はそもそも日本語固有の話ではないですから利用したらいいだけですし、そうしたソフトが JIS90 が表示できなかったりしても、別に何の問題も発生しないかと思います。今まで JIS90 に依存していたとも思えませんから。どうでしょうか。
日本語版以外の環境で日本語を扱えるようにする場合に問題が発生するのではないかということですが、具体的にどのような問題が発生すると思いますか? 私にはそういった状況が想像できませんが。組み合わせ可能文字って、Unicode 1.0 からの話ですから今更感は全く拭えない話ですし。
しっかり制御する必要があるソフトは今から対応する必要はあるでしょう。そうでしょう。そして、OpenType Feature Tag に対応したフォントは Windows Vista RTM に付いて来ていますし、そうしたソフトを作成しているベンダは MSDN なりでとっくに入手しているでしょう。Windows Vista 対応の Windows SDK も出ていますし、これを Visual Studio 2005 へ組み込んで利用できるようになっていますので、開発環境として不足している点は全くないでしょう。
元記事は読まれていますか? 非常に重要な問題として警鐘を鳴らすことは確かに大切ですが、元記事では XP 向けに Vista 互換フォントが提供されること、逆に Vista 向けに XP 互換フォントが提供されること、MS 明朝/ゴシック 3.2 でも JIS90 字形が利用できることといった点は全く書かれていません。そうした点を全く説明せずに問題だけ挙げ、解決手段に全く触れていないのが最大の問題です。これじゃ FUD でしょう。
Re:字形の違いを「文字化け」と言うな (スコア:1, 興味深い)
kamuy氏が指摘しているのは、例えば「Vistaのメモ帳で作成したテキスト(と作成者は思っている)データが、他の環境で作成者の意図どおりに正常に表示できるか」という話だと思います。OpenType Feature Tagというものについて深くは知りませんが、それは前述のようなテキストデータに付与されるものなのでしょうか？
ほとんどのWebアプリケーションは、最終的にはHTMLで記述された(XMLかもしれないけど)文字情報としてサーバー－クライアント間でデータをやりとりします。サーバー側とクライアント側で全く同じコード体系を使用する場合を除けば、必ず文字コードの変換を行なう必要があります。その際、コードポイントと字形は1対1で対応していないと不具合が発生する場合が多々あります。円マークやWavedashの問題などは典型的でしょう。
Vistaクライアントが送出する可能性のあるサロゲートペアを使用する文字をきちんとハンドリングできるWebアプリはかなり少数だと思います。「他のOSではメイリオなどのWindows固有のフォントは提供されないのでそもそも問題にならない」というのは、明らかに論点がずれている、もしくは問題を過小評価していると思います。
Re:字形の違いを「文字化け」と言うな (スコア:1, すばらしい洞察)
問題提起とそれに対する答えが同時に出ている問題に対して、問題提起だけを取り上げて掘り下げられてもありがたくもなんとも無いでしょう。同じ掘り下げるなら、既に出されている答えがどれほど有効なのか、未だ残る問題はどういったことなのか。そこまで掘り下げた方が読者にも余程有意義だと思います。
この記事だけ読んだ人には問題だけあって解決方法が全く提供されていないと感じるかと思いますが、どうでしょうか。
Re:字形の違いを「文字化け」と言うな (スコア:1)
元コメントに書いた内容は、Microsoft のサイトから 11 月中旬には (誰でも) ダウンロードできた資料を元に書いています。手元のものはバージョン 3.3 (2006/11/15 版) です。
そして、今回のストーリーで出されている記事は、前編が 12/14 公開です。
さすがにほぼ 1 ヶ月もあって「間に合わない」というのは、(雑誌ではないのですから) 一言言及することすらできないほど短い期間だとは思えません。
Re:字形の違いを「文字化け」と言うな (スコア:1, 参考になる)
ということでITProの特集ページから
つWindows Vista対応支援センター [microsoft.com]
CharNextW/CharPrevWの動作 (スコア:4, 参考になる)
結果としてはVistaでも従来同様、CharNextW/CharPrevWはサロゲート・ペアを2文字として扱うようです。
合成文字のほうは複数ワードを1文字として移動してくれます。
（どちらもWindows2000と同じ動作）
L"\x30D5\x309A"(合成文字"プ") : 1回で2ワード分移動
L"\x0075\x0308\x0304"(合成文字"ǖ") : 1回で3ワード分移動
L"\xD840\xDC0B"(サロゲート・ペア"��") : 1回で1ワード分のみ移動
てっきりCharNextW/CharPrevWで1文字として扱ってくれると思っていたので、この動作は意外でした。（互換性を考慮したためなのでしょうか？）
この超基本的なAPIがサロゲート・ペア対応していないとなると、アプリでの対応はあまり期待できなさそうな……。
Re:CharNextW/CharPrevWの動作 (スコア:3, 参考になる)
代替手段としては、IS_SURROGATE_PAIR [microsoft.com]、IS_HIGH_SURROGATE [microsoft.com]、IS_LOW_SURROGATE [microsoft.com]などを使って、自前でポインタを進めるという手ですかね。
昔はみんな if( iskanji1(*p) )p++; みたいなことやってたよね。
サロゲートペア領域のほうは (スコア:3, 興味深い)
U+10000 以上のサロゲートペア領域についてですが，
まず，XP では「・」と表示されます． また，別の文字を使えば，同じフォルダ内に「・.txt」「・.txt」と見えるファイルを作成することができます． おそらくはフォントが無い，というだけで，内部の処理は UTF-16 対応しているように見えます．
あと，2000 では「□□」と表示されます． １文字として認識されていないようです．
あと，Vista で U+10000 以上の領域で増えているのは，JIS に収録されている漢字だけではありません． JIS で定義されていない漢字（例えば，吉野家の吉 = 土 + 口，など）もあります． IME では候補には上がってこないようですが，
- web ページからコピー＆ペースト
- IMEパッドを利用
で，入力できたりします．Microsoftの責任か？ (スコア:3, 興味深い)
JIS規格の例示字形の変更に伴って起こったものでしょうし
元を正せば、国語審議会が正字と異体字を入れ替えてしまったのが
原因のような気がします。
「字体が違う」のを「化ける」というのか (スコア:2, 興味深い)
Re:「字体が違う」のを「化ける」というのか (スコア:4, 興味深い)
「文字化け」の例として、「辻」という字がありますが、XPではしんにょうの点は1つ、Vistaでは2つだそうです。点2つの辻さんは「自分の名前が正しく表示される」と喜ぶでしょうが、点1つの辻さんは「自分の名前が文字化けする」と怒るでしょうね。
# 83JISで懲りなかったのかと小一時間........
Re:「字体が違う」のを「化ける」というのか (スコア:5, 興味深い)
預金口座開設時に誤って正字で登録されていると本人確認が出来ないと
いうことで預金が下ろせないことがあったりします。昔は（といっても数年前）
そこまで厳しくなかったので解ったはいたのですが放っておいたら
ついこの間銀行の窓口で変更しないと定期を解約できないと言われてしまいました。
Re:「字体が違う」のを「化ける」というのか (スコア:5, 興味深い)
というのも、自身の戸籍は登録(出生)時は、二点しんにょうの辻だったのですが、数年前に戸籍謄本を取る必要があり確認してみたところ、いつの間にか勝手に一点しんにょうの辻に変えられていました。
役所に聞いたところ、台帳の電算化に伴い、出来るだけ異字体を排除すべく処理を行ったとのこと。
変更時に世帯主に「登録字形を変えるがいいか？」という確認の手紙を出して、変えるなという返事が来た人以外を変更していったとのことです。
＃言われてみれば(変更されたとされる)当時は扶養家族の身でした。
で、今は一点しんにょうの「辻」を使っていますが、これがVistaに乗り換えると今まで書いた文書を表示・プリントさせると勝手に二点しんにょうになるわけです。
それを役所に持っていっても、今度は受理されないということになります。
このように字形の問題は繊細かつ、その字を使っていない人が考える以上の問題になります。
他のコメントツリーにあるように、銀行口座の登録とか住民基本台帳とか、対応部署は結構頭の痛い問題でしょう。
個人的には「読めりゃいいじゃん」と思うんですがねえ…。
あーそうそう、字体が変わると画数も変わるんで、占い好きな方々にとっては大問題ですね。:-p
＃姓名判断したら、一点と二点で正反対の結果が出たのでID
変更の元兇 (スコア:3, 参考になる)
この問題は、根本的には
2000年の「国語審議会2000/12/08 答申」 [mext.go.jp]
に起因する問題です。その答申では、「ワープロ」等の字体も答申の字体に変更するようにと書かれています。
したがって、その時点でJISの変更（後の2004年2月20日、 日本語文字コード規格の1つであるJIS X 0213を改正する「追補1」が官報で公示された [impress.co.jp])も予測され、今回のVistaの書体になったわけです [itmedia.co.jp]。
また答申に伴い、学校で教える字体も変更になり、2000年以降に学校教育を受けた人は、辻は二つ点の「辻」を書いていると思います。
ちなみに、国語審議会の答申が出たのは、江藤淳氏らの「森鴎外」発言（森鴎外の「鴎」の字がパソコンでは正しくでない。）が元になったと思います。
花を召しませ～ (スコア:1)
しつもーん！
“辻”って人名漢字なんですが、いつから常用漢字入りしたんですか？
#それはともかく、一点之繞は二点之繞を省略させた同じ字ということを浸透させるのが先。
#同様にだな、高田の“高”は“はしご高の高なんだよ、とか言うのもヤメレ。
リアル厨房時代、国語教師に「“はしご高”は高の旧字」といけしゃあしゃあと言われた
ことに未だむかつくのでID。
画数は変わりません。 (スコア:2, 参考になる)
一点しんにょうの辻も二点しんにょうの辻も同じ字です。
二点しんにょうは「いわゆる康煕字典体」とその系統を受け継ぐ明朝体から派生したスタイルの活字のデザイン上の飾りであって、楷書でしんにょうの点を二つ書いたりはしません。
Re:画数は変わりません。 (スコア:2, すばらしい洞察)
世紀の愚問 (スコア:2, 参考になる)
参考：
Ｑ．さいたま市の「さ」の字体は、つながっているのが正しいのですか？ [saitama.jp]
Nullius addictus iurare in verba magistri
Re:「字体が違う」のを「化ける」というのか (スコア:1)
Re:「字体が違う」のを「化ける」というのか (スコア:1, すばらしい洞察)
それを「文字化けする」って言わないんじゃないでしょうか？
点1つの辻さんは「自分の名前の漢字が出てこない」というのではないかな。
元記事をよく読めばわかる？ (スコア:3, すばらしい洞察)
記事の一番最初に「ここでは，本来表示されるべき文字の形が少し違ったものが表示されるケースも“文字化け”として扱う。」と書いてあるのですから、記事中だけの話でしょう。
Re:「字体が違う」のを「化ける」というのか (スコア:3, すばらしい洞察)
表示されるケースも“文字化け”として扱う」と補足されてはいますが、
これを「文字が化ける」というのは誤解を招きそうな。
（コンピュータ業界で「文字化け」というのは、今回のとは別の事象を指す
ことが多いですから）
普通に、「字体が変わる」ではいけなかったんですかね。
Re:「字体が違う」のを「化ける」というのか (スコア:1, 参考になる)
#もちろん印刷会社にもよると思いますが。
フォントの問題と規格に収録された字の違いの問題とUnicodeの実装の問題 (スコア:2, 参考になる)
「フォント間の字体の違い」の問題と「最新のJISとMSのSJISに収録された文字の違い」の問題と「XPではUnicodeのサロゲートペアが扱えない」問題が立て続けに扱われているので、読みにくいですね。
特に「フォント間の字体の違い」を「文字化け」と評するのは、どうかと。
# For man might be free./人は自由になれるかもしれないから。
いつか通る道だが遅い&対応が稚拙 (スコア:2, 興味深い)
>アップルは「Mac OS X」で「Shift_JIS X 0213」に対応しています。
>Windows Vistaでもファイルの入出力ぐらいは「Shift_JIS-2004」
>をサポートしてくれても良かったのではないかと思っています。
VistaでUnicode以外の選択肢はなかったのか？──京大の安岡助教授が語る [nikkeibp.co.jp]
Re:いつか通る道だが遅い&対応が稚拙 (スコア:1, すばらしい洞察)
まあ、どっかでやっちゃうしかないんですけど、こういうのって下手に互換性云々とか言わないでエイ、ヤーで変えたほうが実はダメージが少なくなるもんなんだよね。
Vista の問題と Vista の標準フォントの問題 (スコア:1, 参考になる)
これまでも標準以外のフォントを使えば同様の問題は起きる可能性があった。
またデータ（文字コード）が勝手に改竄されない限りは、
乱暴に言えば表示上の問題でしかなかった。
自分もまだ大まかな話しか聞いていないけれど、Vista への移行ではこれに加えて、
サポートするコード空間の拡張があって、
例えば Web アプリ等で Vista から文字入力を受け付ける際、
うまく処理できなくなる可能性もあると聞いている。
またローカルで動作するアプリに関しても、
例えばこれまでも、内部で SJis しか扱えないアプリに
補助漢字を入力できないなんて問題があったのだけれど、
同じような問題が再度起こる可能性もあるようだ。
何にせよまだリリース版の Vista を触った人間は限られているし、
βを含めてもあらゆるアプリのあらゆる機能が試されたとはとても言えないだろう。
その上俺の得た情報も伝聞の伝聞、何が起こるかびくびくしつつ、
どんなレイヤーでどんな問題が起こり得るのか、できるだけ整理したいとは考えるのが今は精一杯。
Re:Vista の問題と Vista の標準フォントの問題 (スコア:2, 興味深い)
Vistaの正式版を評価利用中ですが、追加された文字をVistaのMS-IMEで入力しようとすると、
環境依存文字（Unicode）と変換候補リストに表示されます。
以下の文字が新規追加文字です。
（MS-IMEいわく"デザイン差"の文字）
俱 剝
Re:Vista の問題と Vista の標準フォントの問題 (スコア:2, 興味深い)
続き。
これらが通常の字体です。
倶 剥 叱 呑 嘘 妍 屏 并 痩 繋
たとえば、倶楽部（くらぶ）と変換しようとすると、環境依存字体の「倶」を含んだ変換候補も表示されるといった具合。
話は変わり、Webアプリの分野。
ASP.NETであれば、ValidateRequest="true"の場合、これらの文字をPOSTすると例外が戻されます。
How To: ASP.NET でクロスサイト スクリプトを防止する方法 [microsoft.com]
もちろん、.Netのこのチェックのみでは漏れがあるので、Webアプリ独自のチェックと併用している場合が多いでしょう。
ただ、ValidateRequest="false"にして、独自のチェックのみを行っている場合は要注意でしょうか。
Webアプリといっても他のシステムとの連携もあるでしょうから難しいところですね。
#Insert前のフィルタリングで「叱」の別字体以降がちょん切られたのかな。
#プレビューの段階では表示されていたのですが。
Re:Vista の問題と Vista の標準フォントの問題 (スコア:1, 興味深い)
あちこちで(blogサービス等等）「Vista拡張文字に対応には対応してません」の文言が追加されるんだろうな。
フォントでなんとかならないか (スコア:1)
＃すんません。よく分かってません。
Re:フォントでなんとかならないか (スコア:5, 参考になる)
問題は先延ばしにされますが、いつかは移行しなければならないことに
かわりはありません。
Impress PC Watch [impress.co.jp] Microsoftのダウンロードセンターから入手して、字体を旧版にしたい
全てのクライアントにインストールしないといけないので、それなりに
大変な作業になります。
個人ならPC 1台に入れればいいでしょうけど、役所などでは混乱必至。
Re:フォントでなんとかならないか (スコア:1)
そこで文章を切ってしまうとそういう形に見えますが……。
「Windows Vista に提供」は 「Vista に組み込まれて出荷される」に置き換えて読むとわかりやすくなるかと思いますが、その後の提供は Windows Update 経由ですよ。
「フォント化け」とでも言えば良かったのか？ (スコア:1)
XPでも同じフォントを使えるようになる、とのことですがそれでは話が逆。
今まで使ってたものを使えるようにするのが筋だと思うのですが。
>漢字データを扱うアプリの担当者は大変
データ（文字コード）が変更になるわけではないので・・。
「既存のシステムで拡張になった部分も対応できるようにしろ」という話ならともかく、アプリではなくWindowsでのアプリ一般の見た目の話なのでは。
名称や住所を特に重要に扱うアプリ（DTP関係 DM業者）なら大変かもしれませんが。
住基ネットは問題ないの？ (スコア:1, 参考になる)
Windows上で漢字を扱うシステムとしては、おそらく国内最大規模であろう住基ネットでは問題出ないのかな？
ほら貝の情報 [horagai.com]によると、住基ネットはXKP [xkp.or.jp]や専用の文字コード／フォントを使ってるみたいだけど、そのあたりのアーキテクチャはVistaと整合性取れてるの？
Re:住基ネットは問題ないの？ (スコア:2, 参考になる)
専用の文字セットと専用のフォントを使ってますんで、問題の起きようがありません。
# ACにするしかないんでAC
Re:住基ネットは問題ないの？ (スコア:1)
リプレイスまでＸＰの継続利用でしょう。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
腐ってやがる・・・早すぎたんだ (スコア:1, おもしろおかしい)
もう少し準備をしてから公表すべきではないかと思います。
#ユーザーテストといえばいつものユーザーテストでしょうけど。
#早々こんな [excite.co.jp]話も出てますがいつものことと言えばいつもの事ですけど
企業ユースに特化してみるテスト。 (スコア:1)
ざっとみるかぎり
a. Vistaとそれ以前で多少形がかわる文字
b. Vistaでは表示されるが、それ以前の環境では表示されない文字
の2パターンで、「XP以前の環境では表示されるがVistaでは表示されない」というパターンはないようですね。
a. はすっとぼけていればよさそうですが;-) b.は案外問題になるかもしれません。
「ｘｘ部から来たメールが読めない！」
とかいうユーザが来て、しらべたらｘｘ部ではVistaだったりとか...
対策としては、Vista側で互換性のあるフォントをつかう(ってか、それしか使用NG)ってことでいいのかな。
苦い思い出・・・ (スコア:2, 参考になる)
「顛」末書で出したら上司に怒られました。
メール以外でも半角カタカナや機種依存文字を使うな！と注意する
人の多いこと・・・ウチもお客もWindowsしか使わんでしょーが。
ドライバの標準設定で、MS明朝/MSゴシックを独自の置換フォントで
印刷するプリンタが結構あります。
この機能により丸囲み数字すら印字できなくなる機種もありました。
VB6.0以前で作成したソフトでは(シフト)JISコード割当のない文字を
使用できず、変換しても「？」になります。
「WordやExcelで使える文字がなぜ使えない！」って言われてもねぇ。
と、このようにフォントや文字コードは苦い思い出が多いです。
その度に外字エディタによる力技で解決してきましたが、3番目の
置換フォントが設定で回避できると知ったときはもうガックリ。
匠気だけでは商機なく、正気なだけでは勝機なし。
参考資料を見つけたので (スコア:1)
Microsoft のサイトで参考となりそうな文書 [microsoft.com]を見つけたので置いておきます。
上記のところにおいてある PDF のタイムスタンプ的には 11/28 なのですが、JIS2004対応について [msdn.com]の blog エントリ自体は 12/18 だったりします。
このストーリーを読む上では重要な文書に思えます。
しかし、この文書を良く見てみると MS 明朝/ゴシックが Ver 2.3 → Ver 5.0 になってるのですが、バージョン飛びすぎ。
Re:IE7の文字処理問題 (スコア:1)
そこに出ている話は、Web上からダウンロードしてファイルの保存する際に、「\」(円・バックスラッシュ)と「|」(パイプ)がエスケープされるということのようです。
そもそもそんなところにマルチバイト文字を使うことや、保存時のファイル名の初期値の定義はHTTPの規格外でしょうし、そのサービスがずいぶんとヤクザな仕様に感じます。
Re:IE7の文字処理問題 (スコア:1)
0x5c は \、0x7c は | ですから、これ単体で見るとどちらも元々ファイル名として利用できない文字です。こちらは普通に Shift_JIS の取り扱い問題ではないでしょうか。
なお、Web サーバ側にファイル名が Shift_JIS になるように置いてみた場合に 2byte 目が 0x5c となる文字で試してみたところ、確かに IE7 で名前は変わってしまいましたが、同じ文字でも UTF-8 ならコードが変わるためそのままの名前でダウンロードできました。なので、リンク先にある「※本現象は、インターネットディスクのWebビュー利用に限らず、一般サイトからのファイルダウンロードでも発生します。」はちょっと言いすぎな気がします。
Re:IE7の文字処理問題 (スコア:1)
ナンセンスさに関しては、「\\||.zip」なんてファイル名を付けることのナンセンスさと同じだという程度には理解していますよ。
ところで、UTF-8 の場合、マルチバイト文字は全て 8bit 目が 1 になるはずなのですが、マルチバイト文字の一部に 0x5c や 0x7c が存在するパターンってあるのでしょうか。
それと、Shift_JIS で応答を返したところで正確にファイル名を要求するにはパーセントエスケープ (URL エスケープ) で参照する必要があるのですが、これはつまりファイルシステム上に Shift_JIS で記録する必要があります。
で、日本語のファイル名を Shift_JIS で Web 向けに公開する際に付けるのって一般的な事なのでしょうか。
Re:SDKの場合 (スコア:2, 参考になる)
なので、IsDBCSLeadByte/IsDBCSLeadByteEx は今回の変更とは無関係ですので、影響は一切受けません。