2006-12-26
■Windows VistaのJIS2004対応 まとめなおし
とりあえずこのぐらいはね
この話については、Character Set(文字集合)と符号化(Encoding)の違いを意識しておく必要があるだろう。
ピンとこない人は以下のエントリあたりで。
404 Blog Not Found:Unicodeは文字集合か符号化方式か
404 Blog Not Found:備忘録: Unicode, UCS, and UTF
Character Set vs. Encoding
このあたりをちゃんと認識していないと、余計な手間が増えるだけだと思う。
で、どんな環境でテストするのさ
Windowsの次期バージョンWindows Vista(TM)において日本語フォント環境を一新
マイクロソフト,新文字セット「JIS2004」への移行措置を明らかに - ニュース:ITpro
MSゴシックファミリー、MS明朝ファミリーと、Vistaで追加になるメイリオフォントが対象。
"JIS2004に対応した"とここで言っているところのフォントは、あとあと Windows XP に対しても配布されるらしい。(2007/6/19 追記:配布されているなぁ)
ちなみに、
http://www.asahi-net.or.jp/~sd5a-ucd/freefonts/XANO-mincho/index.html.ja.sjis
の様なフォントを使うことでXPでもアプリケーションのテストなどはできる。
(追記 2008/05/19)
メイリオも正式にXP向けに提供された。
JIS2004とはいうものの
JIS2004対応とは言っても、JIS X 0213(JIS2004のことね)に記述がある符号化——EUC-JIS-2004, ISO-2022-JP-2004, Shift_JIS-2004——のことは無視して、Unicodeでの符号化だけしかとりあえず考えてない。まぁ、問題ないよな?
Vista のメモ帳(notepad)で保存するときにそれらの符号化が選べるのかどうか、http://q.hatena.ne.jp/1167033462 で質問をした。
あと詳しくは見ていないが、EUCの場合は新しく追加になる文字も今までと同様の考え方で符号化できる……らしい。
文字集合としては、JIS2004の全ての文字はUnicodeでもすでに定義済みである(Unicode3.2で完全に定義されたようだ)。
どんな文字が問題なの?
(1)字形が変更になる文字がある
code point はそのままだが、字形が変わる文字がある。
詳細は以下のpdf。
「JISでは字形は規定していない*1」ので、「パソコンなどに搭載される字形の変更を求めるものではない」が、Vista で搭載されるフォントでは間違いなく字形が変更される。
エンドユーザへの周知が必要である、という点を除けば大きな問題ではないだろう*2。
Vista と XPとで、同じデータを同じアプリケーションで見ているのに字が違うとなるわけだ。
そんなケースでは因果が判りやすいのだが、クライアント(例えばブラウザ上で走っているWebアプリケーション)からの要求を受けて、サーバ側の方でプリンタから出力になるケースでは混乱するかも。Webサーバとか、プリンタサーバとかネットワーク機能搭載の複合機とかが間に入ると、エンドユーザには判りにくくなるのではないか。
あと、フォントを埋め込まないPDFがどうなるかも確認が必要?
2007/1/24追記
Vista搭載のフォントでJIS2004での変更以外にも、‖という記号が字形(?)が変化していることを発見。
2007/1/30追記
そんな簡単な話じゃなかった。U+2016(DOUBLE VERTICAL LINE)はそのままの字形だけど("VERTICAL"だからそりゃそうだ)、U+2225(PARALLEL TO)の方の字形が変わっている。(実体参照で書いておく。‖→‖, ∥→∥。Vista で見ると字形が異なって見えるはず)
コンバータにCp932を指定してJIS X 0201→Unicodeへのcode pointの変換をすると字形が変わった様に見える。他のコンバータでは問題ないだろう。きっと。
2007/3/5追記
これで意味が通らない人は、
http://www.ingrid.org/java/i18n/unicode.html
http://www.ingrid.org/java/i18n/encoding/ja-conv.html
を参照のこと。
(2)文字が追加される case1
UTF-8で3バイト、UTF-16で2バイトに符号化される範囲の未定義だったcode pointに、新たに文字が定義された。
アプリケーションで気をつけることは多くない。
文字種チェックのロジックがすでに入っている場合は、それが正しく機能するかを確認する必要はある。
他のシステムとの連携があってそちら側がShift-JISしか受け付けませんよ、という様なケースでは当然どこかにデータの範囲をチェックするロジックがあるはず。入力時に入れさせないのか、出力時に下駄(〓)にするのかという選択肢はあるだろうが、いずれにせよチェックは必ずしている。
Javaでコード変換の時に'?'になるからそれに任せてしまえ、みたいな対応をしていたりして……。
(3)文字が追加される case2
UTF-8で4バイト、UTF-16で4バイトに符号化される範囲のcode pointに、新たに文字が定義された。
極端なケースを挙げると、漢字1文字を格納する領域(DB上の項目とかメモリ領域とか)として、UTF-8での符号化を前提に3バイトしか確保していない、なんて対応をしていると問題がある(というか、今までも問題はあったのだけど表面化していないというだけである)。
UTF-16での符号化を前提に1文字あたり2バイトしか確保していない、などはいかにもありそうである。10文字の入力に対して20バイトを確保しておいてそれでOKとしているようでは危ない。
ところで、まさかとは思うけど、UTF-16が"1文字を2バイトに"符号化する方法だといまだに思っている人はいない……よな?
ちなみにUTF-8で3バイトに符号化されるcode pointの範囲は、UTF-16では2バイトになる(逆は当然真ならず)。UTF-8で4バイトに符号化されるcode pointの範囲はUTF-16では4バイト必要だし、逆もまた真。
Javaって文字の内部表現はUnicodeじゃなかったっけ
Javaについては、とりあえず資料だけ探しておいて、
にリンクを書いた。一筋縄ではいかなさそう。
Webはどうなるの?(実体参照編)
HTMLでの扱いは色々と考える部分がある。
まず実体参照*3。HTML自体はEUC-JPで書かれたものであっても実体参照として 𪚲 と書くと…… 𪚲 となってフォント次第では表示可能。これはdankogaiさんのエントリを読み直していて気がついた。
まず、この文字を表示可能なフォントがインストールされていることが大前提。
(1)Firefoxの場合
実体参照が解決されその漢字が表示される。ブラウザのフォントを特別指定していなくても——つまりMSゴシックなどを指定していたとしても、その漢字の部分だけ別なフォントで表示される(フォント内のメタデータ(?)の Unicode Range を参照して、表示可能なフォントを探し出しているのか?)。
(2)IE6の場合
フォント設定で、表示可能なフォントを設定しておく必要がある*4。
UTF-8,UTF-16をcharsetに指定したHTMLで、UTF-8/UTF-16で3バイト/2バイトに符号化される文字は表示可能だが、UTF-8およびUTF-16で4バイトに符号化される文字は表示できない。中黒(・)の様な表示。
shift_jis, EUC-JPをcharsetに指定したHTMLでは表示できない。
(3)IE7(WinXP)の場合
フォント設定で、表示可能なフォントを設定していない場合。
IE6のUTF-8,UTF-16をcharsetに指定したHTMLと同じ様に表示がされる(shift_jis, EUC-JPをcharsetに指定したHTMLであっても)。
フォント設定で、表示可能なフォントを設定した場合。
UTF-8,UTF-16をcharsetに指定したHTMLはIE6と同じ表示。
shift_jis, EUC-JPをcharsetに指定したHTMLはUTF-8およびUTF-16で4バイトに符号化される文字もちゃんと表示できる。
なんでshift_jis, EUC-JPの方が表示される範囲が広いんだ? なんでだ……??
(4)IE7(Vista)の場合
初期状態で MS ゴシックファミリーがフォント設定されている。
shift_jis, EUC-JP, UTF-8, UTF-16 のどれであっても実体参照から正しい文字が表示される。
ただ、UTF-8, UTF-16 だとゴシックで表示されないんだよなぁ……。ちょっと不思議。
(5)表示はできないものの……
表示できないがしかし、選択してコピーするとちゃんと「その文字」である。メモ帳あたりにペーストして、UTF-8やUTF-16("UNICODE"という名前になっている。ややこしい)で保存すると正しい符号になる。
Webはどうなるの?(UTF-8, UTF-16編)
追記予定
とかいって枠を開けておいたものの、実体参照編と同じ結果になった。そりゃそうか。
Webはどうなるの?(フォーム編)
JIS2004とは全然関係ない話だけど*5、まとめてここに書いておく価値はあると思う。
shift_jis や EUC-JP で書かれたページのフォームに、Unicodeにしか無い文字を入れたらどのように振る舞うのか?
例えば、𪚲 (月に亀)の文字を入れると、
p=%26%23173746%3B
という様なCGIパラメータがわたされる。%26が'&'を、同様%23が'#'を、%3Bが';'を示し、CGI関連のライブラリはこれを"𪚲"という文字列に変換するだろう。これは実体参照の形に他ならないが、ここからUnicodeのcode point U+02A6B2 の文字だと認識して処理することは普通やらない。
と書いたのは、フォームを置いてあるページが shift_jis や EUC-JP で符号化されているケースだから。これをどう処理するかはCGI次第。少なくとも、無駄な負荷が発生してCGIの結果が返ってこない、なんていうことにならないようにはしたいものだ。
UTF-8 や UTF-16 で書かれたページのフォームに入力される場合は、書くまでもなくその方式で符号化されて、
p=%69%D8%B2%DE
とか、
p=%F0%AA%9A%B2
などと来ることになる。
どんなアプリケーションが危ないの?
フロントエンドがUTF-8のcharsetで、バックエンドがshift_jisなシステムなんていうシステムを考える。受け取った入力(画面,ファイル,CGIパラメータなどなど)は途中まで内部コードがUnicode*6で処理されるだろう。どこかでshift_jisに変換しなければならないが、その時に(それはないだろうとも思うけど)Unicodeにしか無い文字があることを失念していたり、今回追加になる範囲のcode pointを考慮していないとか(こちらはありそう)そんなことがあると、どこかでおかしくなる。
このあたりをよく考慮せずにJavaで作っていたりすると途中で'?'に化ける。で、SQLに like '?%' みたいな条件が入って誤ヒットとか起こしそう。
編集のために
UTF-8/UF-16で4バイトに符号化される文字を扱うには、実はメモ帳がよい。Unicode対応したとされている秀丸やEmEditorでも、その様な文字を使うと正しく符号化されないように見えた。
秀丸については現時点でβテスト中のバージョンを以て改善される様だ
もっと深く知るために
下のエントリの本がオススメ。
■電脳社会の日本語
読了。とはいえちょっと読み急ぎすぎたか、理解不足の感あり。
まずはクイズです。「裏」の部首はなんでしょうか? 答えはエントリ末にて。
第二章 アルファベット世界への参入
1byteが5bitや6bitだった時代、アルファベットの符号がアルファベット順じゃなかった時代の話を読めるのが新鮮。
p57〜p58
ASCIIは制御符号と文字を分離しているだけでなく、アルファベットをAからZまで連続して配置している。
五ビットないし六ビットコードのコンピュータがほとんどだった時代に、あえて七ビットコードにしてた点も重要である。(略)
たが、制定時点では、六ビットのままでよいという反対論が強かった。(略)ANSIが七ビットコードを選んだのは英断というほかない。
第三章 国際文字コードとしての漢字
(特に漢字において)「文字」とは一体どういう概念を示すのか?
コンピュータが電子計算機だった時代に、いずれ文字や文章をデータとして扱うことを予見していた先達達の記録。
よくよく考えてみれば、文字コードの制定というのはコンピュータで漢字が扱える様になる前の話なわけで、例示字体*7は様々な写植・書体の切り貼りと手書きで作成されたという。そりゃそうか、と思ったが今まで気がつかずにいたのがちょっと恥ずかしい限り。
第四章 漢字制限論争の亡霊
「かな漢字を棄ててすべてローマ字にするべきだ」という明治時代に起こった運動。
まさかそれが1980年代まで——否、今現在まで影響を及ぼしていようとは。
これも正直考えもしなかった歴史がある、ということに圧倒される。
シフトJISの思わぬ普及と、83JISによる大混乱。
日本語を取り巻く様々な「流れ」を知る資料である。
第五章 グローバルスタンダードをめぐる攻防
このあたりからやっとなじみの話が出てくる。
ユニコードの理想。甘い見通しによる迷走。結局、サロゲートペアを使った拡張が様々な世界に影響を与えつつある。上のエントリで書いたJIS2004対応フォントなど、まさにその発露。
第六章 文字コードの現在
といいつもすでに過去の一時点になってしまっている。この本全般に言えることだが、書かれた時期が少し古いために、「現在への流れ」を多少なりとも念頭において読まねばならないのがちょっと苦痛ではある。
第二版の刊行を望む。それほどにまとめられた貴重な資料だと思う。
p187
「裏」が(略)「衣」だとはなかなかわからない(上下に割った「衣」の間に音符の「里」をはさんだ字形で、横に並べると「裡」になる)。
ちょっとびっくり。哀衰喪衷嚢褒蓑簑簔袁袞袤裹襃襄褻裵。このあたりは全部「衣」が由来。
最後に印象的だった、そして深く頷いてしまった言葉を。
p200
ユニコードは国際化のための文字コードというより、地域化を能率的におこなうために作られた文字コードと考えた方がいいだろう。
きっと、また読むことになるだろう。面白かったし、ためにもなった。
*1 後述する本「電脳社会の日本語」p86には「逆説的に規格票の例示字形に規範的な重みをあたえる結果になった。個々の漢字の『文字概念』は例示字形を唯一の手がかりに推定するしかないからである。」とある。JISが「コードが振った」のは字形に対してでなく「文字概念」なるものに対してであった。にもかかわらず「文字概念」そのものの説明が欠けていた、という趣旨である。このことは現在に至るも影響が少なくないように思う。
*2 技術的な問題ではない、という意味。文化的な問題は非常に大きい。
*3 ここではないどこかで「それは実体参照じゃない。数値文字参照と呼ぶんだ」というツッコミを見かけました。その通りで、数値文字参照と書くべきです。と追記しておく。
*4 と書いてはみたものの、UTF-8,UTF-16をcharsetに指定したHTMLのレンダリングは言語日本語で指定したフォントを必ず使うわけじゃないのか? 判らなくなってきた……。
*5 IE7とも関係ない。IE6でもFirefoxでもずっと昔からこういう動作をしていたはずだから。
*6 UTF-8でもUTF-16でもJavaでもなんでもよいので"Unicode"と表記。
*7 なんで例示字形じゃないんだろう? と頭をひねっていた。誰か教えてくださいませ。
2006-12-25
■無題
歴史的経緯を頭から追い出してこのページを見ると、「わたしってこんなところで話題になっているんだよ」と言いたい様に見えるのだけど。
あ、それと、
http://www5.diary.ne.jp/logdisp.cgi?user=521442&log=20061222
に書いてある「規約」がなんなのか判らない。それにリンクの許可のための連絡先が判らないのでどうして欲しいのか全く判らない、とも思う。
追記、というか半端に更新してしまっただけなのだけど
「歴史的経緯を頭から追い出して」なんて書き出しにしたのは意味があって、「無断リンク禁止」を擁する人で「無断でリンクすることを快く思わない人がいてかつそう表明しているのだから、相手の気持ちを思いやってしかるべきではないか」という論旨の文を目にしたことがある。でも、今相手にできるのは、今あるコンテンツだけなのだ。今あるコンテンツから「なんでこの人はこんなことしてるんだろう?」と思ってもその人がかつて書いた(と思われる)コンテンツは霧散していて、提示することはおろか参照することすら不可能。その様な状態が作り出されている中で「相手の気持ちを思いやる」ことなんてできやしない。だってその「気持ち」とやらは一体どこにどう書かれているの? たとえ「ここにこう書いてある」とリンクを提示されても、そのリンクがどれだけの「気持ち」を表現していると言える? 今からサイドバーやヘッダ、フッタにその言明が追加されたとして、だってさっきまでは無かったよね? 今ふとそういう気持ちになってコンテンツに追加したのと、もともと強く強くそう思っていたのだけど今まで書いてなかったから追加したのと、何かが違うとでも?
……いや。そんなことが言いたかったわけじゃなくて。
手段が目的のためにそぐわないというか、まっこう正反対、逆効果なことしかしていないよね、という話だったのだけど、なんか脱線。
■ヤフオクで大規模詐欺?
まぁ、まだ(一応)疑問符つきだけど。
Zaurusを買おうか迷っている時に価格を調べていてこの出品者は結構見たと記憶している。この出品者によくビッドできるなぁ、と思っていたのだけど、記憶違いじゃないよなぁ……。
ヤフーは、「Yahoo!オークション」で電化製品を出品していた販売業者「家電ドットコム」が落札者に商品を発送せず、被害報告が寄せられていることを明らかにした。
ヤフオクで「家電ドットコム」の落札商品届かず、被害総額は最大1億超
■偏差値っていったいどういう見方をされているんだか
日本の子供はもっと学力を上げるべきだと思いますか?ここでいう学力とは"総合的な学習"的なものではなく,ガリ勉・塾通・偏差値で語られるニュアンスものもです.
http://q.hatena.ne.jp/1167039638
偏差値って母集団の中でどの辺に位置しているか、っていう指標だからこの文意にはそぐわない様な。
んでもって偏差値ってのを平気でこんな風に使ってしまう人に教育のことを語られても、って気も(語ってないけどね)。
■Amazonと新ISBNの微妙なカンケイ
あとは「ISBN:9784767805115」と「ISBN:4767805112」が同じページへ行くようになればカンペキダ!
まんぷく::日記 - ISBNの13桁化あれこれ、そしてはてなはどうなる
カンペキじゃないでーす。
オンラインツールで、13桁のISBNを10桁のISBNに変換してくれるサービスを発見したのですが、ここで生成された10桁のISBNを利用して、アソシエイト・リンクを作成することはできますか?
いいえ、アソシエイト・リンクは、10桁のASINを使用した場合にのみ有効ですので、こういった方法で算出した10桁のISBNをリンクに使用することはできません。この場合、お手数ですが、リンク作成画面で該当する商品の商品名・著者名・アーティスト名やメーカー名でサーチをしていただき、該当するASINを選択していただきますようお願いいたします。
ヘルプ - Amazon.co.jp アソシエイト・セントラル
(註:アソシエイトIDでのログインが必要です)
というQ&Aがあります。
当面使われる9784〜体系の新ISBNは、4〜の旧ISBN体系に変換可能(先頭'978'の削除とチェックディジットの再計算でよい)ですが、このアナウンスを見る限りは新ISBN→ASINの変換はその様な見かけ上単純な規則ではなさそうです。
洋書の扱いを考えるとある意味——というのはASINを10桁に固定することを優先するならば、ということ——当然です。洋書の新ISBNへの移行で新ISBN→ASINへの変換規則を作るでしょうから、和書の方も今の段階からそれに倣ってしまえ、となるでしょう。
まぁ,ふたを開けてみないと判らないんですが。
「ISBN:9784767805115」と「ISBN:4767805112」と、さらに「ASIN:??????????」(この形式がまだ不明)が同じページへ行くようになれば完璧です(このISBNに新ASINが付くことはないでしょうけど)。
はてなブックマークのコメント見て追記
自動化された方法、またはプログラムを組むことによって、13桁のISBNからアソシエイト・リンクを作成することはできますか?
はい、13桁のISBN(以下、新ISBN)への移行後は、Amazon Webサービスの一部である、Amazon E-Commerce Service (ECS) のシステムを利用して、新ISBNをもとにアソシエイト・リンクを生成することが可能になる予定です。
ヘルプ - Amazon.co.jp アソシエイト・セントラル
というQ&Aもあります。はてなの中の人ががんばれば、新ISBN→新ASIN ははてなのシステムの中で解決可能です。と、他人事の様に書いているけど、私もこのblogのASINリンク機能を修正しなければならないです。もっとも私は私の都合だけ考えればよくて、当面はAmazonの商品ページを一々開いてASINをコピーするという運用での「逃げ」が打てるので、おいおいやっていけばいいや、って感じです。
id:Hebi さんのコメントに「Amazonひどい」とありますが、ASINを「10桁から13桁にします」ということに決定されたら、AmazonのWebサービスを使っている人はさらに苦しむことになると思うんです。もちろんAmazonのエンジニアもですが。ASINは10桁で続行して、新ISBN→新体系ASIN のAPIを提供する、というのは妥協点として決して「ひどい」案ではないと思います(理想的でもありませんがね……)。
過去エントリ
で結局どうなったかというと……
トホホ。
追記
きくところによると、日本は9784〜のコードで当分の間(10年ぐらい?)やっていけるそうで。
2006-12-24
■色々書いてなかったのでまとめて
さすがにこの年齢になると「ためになる」話が少なくなってくるというか、ネット時代になって情報に触れる量が多くなってきてしまっているのか。
春日部さんで締め。やっぱそうじゃないと。「11人しかいない!」がよかった。が、11人もいるのか……。
表紙ヴァリエーションでこっちも買ってしまいそうな予感。珍しいことだ。
「完全版」の名に恥じない装丁。カラーページ。
集英社のあれらとはちと違う。
内容は今更言うまでももなく、最高。
川原由美子はこれからどこにいくのか
あれ? なんか読んだおぼえの無い作品がチラホラ。スルーするか迷ったけど、買ってよかった。
「案山子亭」はお気に入り。
珍しく積み込みをネタにしたエピソードが。最後の五千円札がいいなぁ、うまいなぁ、と思った。
おまけ。
届いた。半分ほど読んだか。面白い。
本屋で見かけたので購入。
まだ、
の途中なのに。
2006-12-23
■科学
「科学的に間違い」と「非科学的」を混同するなかれ。
「非科学的」な手法を採れば「科学的に間違い」なことも正しいと主張できるだろう。
「科学的に間違い」と「非科学的」の区別がつかない人は——あるいは区別をしない人は——その主張が間違っていることを認識できない。
■痛快パロディ
それが科学的な誠実さだからしょうがないのです。ところが「ニセ脆弱性」は断言してくれます。
高木浩光@自宅の日記 - マスゴミの似非科学に脆弱性報告文化を破壊されるおそれ
2006-12-22
■CSSハック
基本なんだけど、自分で書いて確かめたこと無いのでこの機会にやってみよう。
まずは標準準拠モード。
http://materia.jp/demo/Strict.html
ふむ。Firefox2 と IE6 で同じ表示。
次が後方互換モード
http://materia.jp/demo/Transitional.html
おぉ。IE6だと思いっきり小さくなっとる。
で、後方互換モード、CSSハック付き。
後方互換モードだとpadding が 10px,border が 5px あるので、100+(10+5)×2=130 で、height, width は130px 要る。
_height:130px;
_width:130px;
を、height,widthの後ろに置く。
http://materia.jp/demo/Transitional-CSS-hack.html
うむ。IE6とFirefoxで同じ様になった。
確かに、DTDが関係あったとは言いがたいか。うかつだった。
■blogはニュースじゃない
うむ。格好いい。
If you want to get into the majority of articles, you need to pitch yourself as an expert on an idea.(...)The book or blog is not the news, the ideas are.
How to get your blog (or yourself) mentioned in print >> Brazen Careerist
via
雰囲気だけで読んでいて、多分ちゃんと意味をとれてないと自分で思う。なのでmemo。


