前 5 - 05 p ｜ 
もくじ i ｜ 次 5 - 07 n 
再び古典ギリシャ語
ネスケ４がIE6を打倒！
話題の「致命的問題」は5秒で修正可能
2002-03-17 数値参照を使わず、ギリシャ語を実体で書いてみました。Ziro だと完璧なのだが、BOMがつくので（UTF-8）PHPと相性が悪い。xyzyy（UTF-8N対応）ではフォント選択の制約のため一部の文字が表示できないけれど、ちゃんとその文字になってます。
καὶ εἴρηκέ μοι, Ἀρκεῖ σοι ἡ χάρις μου. ἡ γὰρ δύναμίς μου ἐν ἀσθενείᾳ τελειοῦται.
すると主は、ぼくに言ったのです。「あなたは充分に恵まれている。ちからは非力さのなかでこそ、まっとうされるからだ。」(2 Cor. 12:9)
xyzzy で古典ギリシャ語混在編集、30KB
同じ文を数値参照で書いたもの。
καὶ εἴρηκέ μοι, Ἀρκεῖ σοι ἡ χάρις μου. ἡ γὰρ δύναμίς μου ἐν ἀσθενείᾳ τελειοῦται.
ちなみに参照で書く場合のソースです:
καὶ εἴρηκέ μοι, Ἀρκεῖ σοι ἡ χάρις
μου. ἡ γὰρ δύναμίς μου ἐν ἀσθενείᾳ τελειοῦται.
PHPから読み込むXMLファイルならBOMがあっても大丈夫なので、これから多言語な記事は Ziro で編集しようかな、と思いかけてます。下の画像は、ごらんのこの記事を Ziro で編集しているシーン。xyzzy と違ってギリシャ語拡張のフォントもちゃんと表示されてます。といっても、表示まわりに関しては、単に Unicode バージョン2 の全グリフを含む Arial Unicode MS フォントを選択できる、というだけの違い（バージョン3以降のユニコード文字の一部も含む TITUS Cyberbit なんかも選択可能）。まだユニコード・エディタは発展途上期。
Ziroはすべてのユニコードフォントを選択できる: 31KBイメージのサムネイル
一方、有料配信に対する使用料はといえば、価格の3.5%～7%程度でした。（これは安い。安すぎませんか？）感覚的には、無料配信はもっと安くなるはずです。ということは、ちょっと面白い事態が発生すると考えられます。
これは、確実に無料配信コミュニティを生み出します。誰かが代表で安価な著作権料を支払えば、全員が手に入れることができる。グループで行えば、ちょっと怖いものがあります。こうなると、制作サイドは飢え死にでしょう。（おそらくここが難航している理由です。）ここまででは、おもしろくありません。面白いのはここからです。
まず、制作者はＪＡＳＲＡＣとの契約を解除せざるを得ません。同時にレコード会社との契約も打ち切る。それは、独自にネット上で音楽を有料配信するために、です。この場合独自に著作権を主張できますから、価格の設定は自由です。違法サイトには訴訟で対抗。宣伝もインターネット上で行えるのですから、制作者にとってのレコード会社との契約の意義はほとんどありません。
では、音楽の値段が上がるのかといえば、それは逆です。売上が制作者にダイレクトに入ってくるのですから、販売価格自体は押さえられるのです。今カラオケ曲が1曲１５０円です。このうち７％が制作者に入ると、一曲１０．５円。ＪＡＳＲＡＣの手数料が１０％の１．０５円ですから、制作者には９．４５円が支払われます。一曲１５円で制作者が直接販売したほうが、ずっとまし。安い分、当然流通量も増えますよね。
とどのつまりは、「レコード会社」はいずれ消える！ということですね。過去のＣＤを販売する、という形で続いて行くのでしょう。
うまくすると「アーティストが直接、販売する」というその「販売」自体がなくなるかもしれないと思うのです。
他方、自分としては、一万円くらいなら支払って「正規」に新居先生の曲なんか配信したいとも思うのですが（もちろん非営利で）、ＪＡＳＲＡＣのサイトが使いにくい……。途方もないコストをかけて個人からも「利用料」をとるなど「オンライン販売」体制を強化しながら、そのじつ、どうやって買い物すればいいのか分かりにくい。いまどき商品をオンライン販売するサイトなんていくらでもあると思うのですが、これじゃ、一般客は「買い物」できない……。まぁ善意に解釈すれば、一般向けの商売を始めたばかりで、まだ慣れてないのかもしれませんが……。法律関係やめんどくさい手続きは苦手じゃないのだが、それでもわかりにくいと思う。少なくとも、これは「お客様に商品を販売する」サイトじゃない。言い換えれば、音楽を、素朴な意味で「わたしたちが誇りをもって販売するたいせつな商品」としていつくしんでおらず、単に先物や株と同じ儲けのための取引材料としか見ていないように思われる。
それでもＪＡＳＲＡＣ自身が権利者である一部の曲なら、（サービス業とは思われない販売態度ながら）購入は可能なようです。が、それ以外となると、「有料です。勝手に使うと訴えますよ。必ず購入してください。ただし、ここでは販売していません。どこで売っているか我々は知りません」ってな感じ。2001年の9月にウェブで椎名へきるの「やさしいひとになりましょう」を流したくて版元のソニーにまで問いあわせたのですが、版権者自身も権利関係が分からず混乱していて、ふつうに利用しようと思っても、事実上不可能なようです。そんなふうに当事者にすら把握しがたい権利関係のがんじがらめで中間版権者が音楽を殺しつづけるのは、音楽自身にとっても、原作者のミュージシャンにとっても、もちろん聴衆にとっても、いたたまれないこと。おかねが惜しいのでなくて、音楽が惜しい。音楽をフリーにしたい、と考えるとき、必ずしもおかねの話じゃないです。無料という意味のフリーじゃなくて、音楽となんら関係ない中間版権者からの「自由」の意味です。もちろん値段もフリーや格安に越したことは無いですが、原作者のアーティストが創作・発表活動を続けるのにおかねが必要ならおかねは必要でしょう。そして、それを効率的に実現するには、本来、上の意味でフリーであるべきなのです――音楽ファンでもミュージシャンでもない無関係な中間版権者にカネが流れないようにすれば、安く良質で、シンプルで多様で
今まで川がなかったところに小川（ストリーム）ができたとき。河原で河原の石ころを売ろうとするから、そこに理屈をつけようとするから、一般の感覚では理解できないような自己矛盾が生じるのでは、ないでしょうか。って、つげ義春のマンガじゃないっすよ（笑）
そして本当の理想を言えば、音楽は音楽家からさえもフリーであるべきなのです。子どもが親の所有物たる財産では無いように。
ユニコード・ファンのみなさん、こんにちは。これまで古代ギリシャ文字、ルーン文字、古代イタリア文字……といろいろやってきましたが、今回はハングルと発音記号（IPA: 国際音標文字）でブラウザの表示比べをやってみましょう。
今回は実用的な動機にもとづいています。韓国のかたが「花の魔法使いマリーベル」の主題歌「きっと出来るね！」（MIDI）のハングル版の歌詞を書き取って送ってくださいました。――「きっと出来るね！」は中嶋美智代ベスト『Believe in you』に収録されていて、マリーベルの主題歌では「早起きをした朝 鳥たちの声を 聞いたのよ」以下の部分が使われています。お聞きになりたいかたはCDを買うか、持ってる友だちに借りてください。そして歌を歌いたかった中嶋美智代をおそった運命を忘れることはできません。――
ふだんオンライン翻訳のちからで実用上、問題なく韓国のかたがたとやりとりしてますが、じつはハングルをほとんど読めません。この機会にハングルの読み方を覚えることにしました。さしあたっての教材は、マリーベルの歌のビデオ版とテレビ版。ビデオ版のほうは、上に書いた「早起きをした朝♪」の直訳に近い内容のようです。
ハングルは母音の記号と子音の記号を組み合わせて、できています。例えば、メリベル（Meribel）の me の字 
は、左に四角があって、右に郵便番号の記号が横になったみたいのがありますが、左の四角 
が子音の m で、右の郵便番号記号みたいなの 
が母音の e です。
同様に、「おのれ」という漢字みたいな記号 
が r を表し、縦棒一本 
が i なので、それをくみあわせると 
ri になります。
音節文字としてのハングルは数百だか数千だかの文字数がありますが、要するに、子音を表す部品と母音を表す部品を覚えておけば、その組みあわせで文字は読めるわけです。それぞれの部品は10か20くらいで、それも規則的にできてるので、ちょっと頑張って慣れればすらすら読めるようになりそうです（もちろん文字が読めるだけで韓国語の単語の意味が分かるわけじゃありませんよ）。
そんなわけで、ハングルを解読するための早見表を自作してみました。
この表は画像で挿入していますが、じつはユニコードのキャラクターベースで作ったのをキャプチャーしたものです。言い換えれば、ハングルフォントとIPA（国際発音記号）フォントが利用可能のブラウザであれば、上の表を画像としてではなく、通常の文字として表示可能です。
試してみましょう。
上の表はユニコード・エディタで文字実体を書きましたが、ここでは扱いやすいように文字参照で書いてみます（もし実体で書くと、レンダリングに失敗したブラウザでは、どのコードポイントのレンダリングに失敗したのかさえ分からなくなってしまうからです）。次のソースがスケルトンの例です。（発音記号全般の詳しい検証じゃありません。）
<table frame="box" rules="cols" summary="1行めにJamo、2行めに対応する音素を並べた表"> <caption>ハングルのJamoの例</caption> <tr> <th>ㄱ</th> <th>ㄷ</th> <th>ㅂ</th> <th>ㅈ</th> <th>ㄴ</th> <th>ㄹ</th> <th>ㅁ</th> <th>ㅅ</th> <th>ㅇ</th> <th>ㅎ</th> </tr> <tr> <td>k, g</td> <td>t, d</td> <td>p, b</td> <td>ʧ, ʤ</td> <td>n</td> <td>l, r</td> <td>m</td> <td>s</td> <td>∅, ŋ</td> <td>h</td> </tr> </table>
あなたのブラウザでは、このソースをどのようにレンダリングするでしょうか？ すぐ下がその結果です。
| ㄱ | ㄷ | ㅂ | ㅈ | ㄴ | ㄹ | ㅁ | ㅅ | ㅇ | ㅎ |
|---|---|---|---|---|---|---|---|---|---|
| k, g | t, d | p, b | ʧ, ʤ | n | l, r | m | s | ∅, ŋ | h |
IE6の場合、環境によっては、システムに利用可能なフォントがあるのに表示できないことがあります。フォント・マッチングで「そのフォントのなかでひとつでもマッチできる文字があると第二候補以降のフォントのなかまで探しに行こうとしない」という、IEの「仕様」のためです（現在のIEでは、フォント名を――そして場合によっては言語属性も――明示しないと表示に失敗することがよくあります）。Mozilla は、もっとちゃんと機能します。手元の環境で IE6は ch に当たる発音記号（U+02A7）とその有声音の記号（U+02A4）などをレンダリングできませんでした。IE6の場合、フォント名を明示すれば完璧なレンダリングが可能ですが、相手のシステムにある利用可能なフォントを予期できないので良くない仕様です。――そして今回の驚きですが、Netscape 4.79 がすべてのグリフを正しくレンダしました。通常ではフォントファミリーの指定さえできないネスケ４ですが、UTF-8で書くと（制限も多いものの）ネスケ４も、けっこういろいろできます。Opera 6.02 beta でもすべてのコードポイントがレンダされました（Operaは、もともと韓国語に強い）。
何語でも歌の歌詞というのは聞き取りにくいことが多いですが（ハングル版の冒頭, MP3, 43KB）、「アチメ・イ（ル）チ・キロナソ」のように聞こえると思います。フランス語みたいに Irchik の語尾の k が次の Ironaso にリエゾンするようです……英語でいえば、an+apple=アナッポみたいな。
上の例は画像ですが、すでに見たように、新しいブラウザなら文字参照を使ってキャラクターで書くことも可能です（ブラウザが多言語対応していても、肝心の利用可能なフォントがなければ表示できませんが）。しかし数値文字参照は、むしろ後方互換的。ユニコードエディタを使ってUTF-8などのユニコードでウェブページを制作すれば、これらの文字をすべて実体で編集可能です。２、３文字なら参照で書いても良いけれど、長い文を参照で書くのは実用的でありません。ㄱㄷ なんて書いたら自分でどこに何を書いてるか分かりにくいし、コピペするにも正しいペースト場所を探すのに一苦労。おまけにユニコードなら2～3バイトで書けるものを、ㄱみたいに1文字8バイトも使ってしまって効率が悪いです。
上の画像は Windows上で動くそうしたエディタのひとつ Ziro 。Unicode v.2 の範囲のすべての文字ばかりか、システムにフォントさえあれば、ユニコード3.0以降で追加された（例えば）ルーン文字でもまったく同等に編集可能です。Mozilla 付属のコンポーザにも、ほぼ同じ機能があります。このほか、xyzzy でも、一般的に使うような範囲の多くの文字を混在させられます。日本語と韓国語の混在にかぎれば、Kajero もすばらしいです。
ユニコードの基本多言語面で、ハングルは、あちこちに散らばって存在します。韓国語の表記でふつうに用いられるのは、音節文字としての Hangul Syllables で、U+AC00 から U+D7A3 まで約11000文字。これらの音節文字は、すべて、上で触れた少数の文字構成要素がいろいろにくみあわさってできてます。こちらの構成要素は、漢字の「へん」や「つくり」のように、文字の話をするときには必要だけれども、日常のふつうの文章で使うものじゃないようです。Hangul Jamo と呼ばれてユニコードでは、U+1100台の256コードポイントが割り当てられてます。 Jamo の一部は「在来コードページとの後方互換性のため」、U+3130 ～ U+318F にも重複して収録されてます（Hangul Compatibility Jamo）。Windows 2000 の Unicode で Jamo を使うと、実際には、こちらの Hangul Compatibility Jamo のコードポイントが利用されます。さらにまた、日本語の半角カナが入っている Halfwidth and Fullwidth Forms（U+FF00以降）には、“半角Jamo”も入ってます。現在では、そういう使い方はほとんどしないだろうけど、ハングルはJamoの組み合わせで構成されるので、“半角Jamo”を並べることで、いちおうハングルを表現できたわけです。
2002-03-12 というわけで、Mozilla 0.9.9 が正式リリース。来月には、いよいよ Mozilla 1.0 ……予定の「標準準拠」は（あるいは「製品品質」も）1.0では無理そうですが、この意欲とエネルギーは本当に凄いもんです。難しいことを試すと簡単にフリーズするものの、0.9.1頃に比べたら格段に安定したし……。Opera、Mozillaどっちが先でもいいのですが、まともなブラウザがなくて困ってる（ネスケ４はいまいちだし）Linuxユーザのストレスを解消するような決定打が出てほしいものです。1.0で間に合わなければ、1.01、1.02……進んでいけば良いだけのこと。もし仮にMozillaが標準準拠をまっとうすれば、それに刺激を受けて、対抗上、MSIEももっと良くなって、多くのWindowsユーザにも間接的にメリットがあるでしょう。Mozillaのファンでありつづける極意は、過剰な期待を持たずに現実的に考えることだろうと思っています。
Mozilla 0.9.9 for Windows
207KBイメージのサムネイル
2002-03-14 窓の杜に2002年3月13日づけで「「Mozilla」v0.9.9のインストール時に発生する致命的な不具合に注意」という記事が出てますが、実際には致命的でもなんでもありません。単にインストール時の一時ファイルが削除されないで残るだけで、ほっておいても無害ですし、気にくわなければ、次のようにして簡単に修復というか削除できます。
C:¥Documents and Settings¥All Users>dir /x
2002/03/02 22:32 <DIR> B90D~1 ... .
C:¥Documents and Settings¥All Users>rmdir b90d~1
2002-05-03追記: ちっともfixされず、rc2になっても直ってないので、ワンクリックで修正できるような.batを作りました。追記おわり
2002-05-12追記: 上の問題は、現在のバージョンでは、もはや新規発生しません。（追記おわり）
最近の Mozilla のインターフェイスより。リンクのプロパティ表示がずっとおかしかったのも直ってました。
title属性の値がポップアップテキストのみならず、ウィンドウでポップアップ
2002-04-01 おわび……上のメモで窓の杜へのリンクが間違っていました。正しいURLは
http://www.forest.impress.co.jp/article/2002/03/13/mozillabug.html
です。じつは原文でも初めからちゃんとそのようにタイプしてあったのですが、タイプしてるものと、ブラウザに表示されるものが異なっていました。データを読み込んで動的にHTMLに変換するサーバアプリに「 入力中の年月日がスラッシュ区切り yyyy/mm/dd またはピリオド区切りになってるとき、出力では yyyy-mm-dd というハイフン区切りに統一する」という動作をさせてるため、URL内の /2002/03/13/ までもが /2002-03-13/ に置換され、結果として間違ったURLになってしまっていました。
掲示板1の#636でリンクが間違っているという指摘を受けていたのですが、そのときは「ブラウザからコピペしたリンクが間違ってるわけないし、XML原文を確認しても間違ってなかったので、おおかた窓の杜が直リンを制限したのだろう」と窓の杜のせいにしてすませてしまいました。そして「直リンを制限するとは、窓の杜は、けしからん」などと筋違いなことまで考えてました。すべてぬれぎぬであり、窓の杜は悪くなく、単にリンクが間違ってただけです。ごめんなさい。
窓の杜の記事が不適切であることを含めて、メモの内容自体には、とくに訂正ありません。単に記事中のリンクが間違ってただけです。こんなどーでもいい現象を理由に「インストーラーは使用できず、ZIPファイルを使うしかないようだ」というのは変だし、もしゴミファイルが問題だとしても、Mozillaのベータ版を入れるようなユーザは（少なくともやり方を聞けば）DOS窓から dir /x の rmdir くらい打てるに決まってるから問題にならないでしょう。まぁ、問題は問題としても、通常の感覚で「致命的」といったらOSが起動しなくなるとか、大事なファイルが壊れるとか、個人情報が流出するとか、あるいはOSの再起動が必要になるような問題で、それすらもベータ版を使うなら当然、覚悟のうえ。黙ってれば分からないような、インストーラーが消し忘れた0バイトの一時ファイルなんかは、たいした問題とも思えません。実際、手元ではめんどーなので消さずに残してます……
といっても、これは窓の杜のこの記事が変だというだけの話で、窓の杜というサイトそのものが良いとか悪いとかの話では、ありませんので念のため。また、こんな皮相のこととは無関係に、Mozilla の実質的動作に不具合が多いのも周知の事実。
