[TOP][電波…とどいた? TOP]

電波…とどいた? 199901上旬/中旬/下旬

[←前のページ]
[次のページ→]

1999年1月21日の電波状況

ふう

疲れた。一応予備審査用の資料は提出した。でも OHP 用のを完成させてなかったり。

まりちりんがる

ほらがい/文字コード問題を考えるに、こないだの ICMPT'98 のレポート がでてるのを確認。ふむふむ。うーん、System 1、そこまでできているのならやっぱり公開してほしいなぁ。公開されたら Lapis Lazuli の現表示系全部破棄してそれで書き直してもいいのに。

とこちゃん

うみゅ、盛り上がってますねぇ。

個人的には、 塩崎さんもかいてた 「BSDのメディアミックス戦略」って考え方は、私の感覚とはちょっと違うなぁとおもうのでした。

こーいうものってのは、私の感覚では、宣伝のためにつくるようなものではありません(結果として宣伝にはなるかもしれないけど)。一部のかたよった人たちが、熱情のおもむくままに勝手きままに「でっちあげる」ものです。本筋じゃない。裏道、裏道、変化球。

つーことで、某所の掲示板とやらで 「www.jp.freebsd.org とかからリンク」みたいなことを言われている方がおられたようですが、私ならちょっと「そりゃなんかちがう」かなぁ。本末転倒な気分。

Leafとかのように、「同人活動」をおもいっきり奨励して会社のオフィシャルから同人サークルにリンクはりまくり〜というのもそりゃあるのですが、あれはそもそも集まってる人がはじめから全部片寄ってます。

まあ、PC-UNIX をがしがし使ってる時点で十分片寄ってるっつー説もありますけどね。(観察したところ、実際そうだと思うし(笑))

とかいろいろ書いてみて、過大な期待に釘をさしておくのでした(^^; ちょっと考え固いかな。水さしちゃってるかもね。

この「とこちゃん」で、「どういうものをつくろうとしているのか」という計画は早いうちにどこかに出したほうが良い予感です。杞憂かな。

それはさておき

本日のとこちゃんらくがき (jpg:83k)。「本日の」ということは、毎日つづくかというとそういうわけでもないこともないというのは気のせいだろう。

もひとつ とこちゃん関連ネタ(なのか?)。うちの後輩の本吉君作。IE必須。DynamicHTML ネタ。予想通りというかなんというか、M-Device ヒットらしい(笑)。

無題

ひさびさダメ劇場。でも自分にしてないからダメじゃないかも。ミニSSですな。

某神社にて。

浩: よう! 葵ちゃん。今日も精がでるね
葵: あ、先輩! こんにちは(^^)
浩: 寒いのに毎日練習してるってのはすごいよな〜
葵: (でも、先輩が毎日つきあってくれるからがんばれるんです (ぼそ)
浩: ん? 何かいった?
葵: あっ、あの、別に(^^;
浩: あ、そうそう、葵ちゃん、おととい誕生日だったよね? たしか
葵: は、はい。覚えててくれたんですか?
浩: いやぁ、おもいっきり忘れてたよ(^^; 昨日おもいだしたんだけど、水曜は葵ちゃん道場のほうだったから、いいそびれちゃってね。誕生日おめでとう
葵: ありがとうございます(^^)
浩: でさ、誕生日プレゼント、忘れてたからなーんも準備できてないんだ。で、何でも好きなもの買ってあげるから、土曜日どっかあそびにいかない?
葵: ええっ! でも、そんな、悪いです…
浩: いいからいいから。たまには練習でなくてデートもいいだろ?
葵: で、でーとっ(+o+)……は、はい(=^^=)…
浩: じゃ、そういうことで。さて、それじゃ、練習はじめよっか
葵: はいっ!
続く(謎)

さて、土曜日になにがおこるのか? うちの日記を細かく読んでいる人にはだいたい想像がつくことでせう(笑)


1999年1月22日の電波状況

ふとおもった

なんかノリが、プリティーサミーみたいだよね(謎)

予備審

うむ、なんとかのりきったらしい。予想通りの指摘だったり。まあどうにかなる…な。たぶん

ぐる

サマータイムって、日本の「明け六つ暮れ六つ」とおんなじ発想だと思います。「人間が時間にしばられるのではなく、人にあわせて時間があるのだ」ということなのでしょう。欧州は夏の「昼」が長いというのも要因の一つではないかなとなんとなく想像。

@ むー 本吉君の ADV TEST グレードアップしている。Dynamic HTML ってすごいのね。

とこちゃん

例のメディアミックス関連の話。 (とこちゃんうぉっち1/21がまとまっててナイス)

参加者なみなさまは言うまでもなく、やっぱちゃんとわかってられますね。やっぱ。なんかみょーに話が大きく広がってる感がして違和感感じたのであれを書いたのでした。

だいたい 旧X-TTのページで「 瑠璃子さんの談話」なんてのせてるヤツが言うのもなんだかなだったり(^^; 一応(あの時点での)X-TT は私の産物ですけど、「BSD」ともなるとそうではないでしょうというのが頭にあったのでした。

@ 何が言いたいのか?ってことですが、あまりメッセージ性とかいうのは無かったりするんですね。「まじめにバカをする」ってステキというか、 過程を楽しむっていうか。こういう行動はすこぶる「ハッカー的」だと思ってます。

@ むむ、私の「オリジナルが見れるのが幸せ」とのこと。なんかうれしいです。そんな誉めると調子にのりますよ。こいつは(笑)

@ 私自身は「版権物」はおもいっきり楽しんで描いてます。なんというか、こう、「描こう!」と思わせるものがあって、それを自分なりに表現してるつもりなのです。そもそも「とこちゃん」もなあくさんの文を読んで、ぴぴっとくるものがあって、それを出してみたわけで、私としてはさほど差はありません。

@ しかし、私の絵描きとしての能力は…どうなんでしょね。いくらでも私より絵が上手で丁寧な方はおられるわけで。私には「絵、音楽、文書、プログラム etc 何でもできるようになりたい」な願望が少々ありまして、それがまあ、今の私を形作ってるのですが、いまいち飽きっぽくて継続に乏しいので「器用貧乏」なのでした(^^;

@ とこちゃんの年齢ですが、10〜15歳ぐらいまでかなと想定してました。「とこちゃん5歳」とか描くのは、私の個人的な趣味です(爆)。どうやら、そういうキャラクターの「幼少のみぎり」っつーのを見たり描いたりするのがかなり好きらしいです(^^;; なお「成長している状態がちゃんとある」ってのが(比較的)前提です。誤解なきよう(何を?)。


1999年1月23日の電波状況

昨日

なんか牧野君のおわかれ会みたいなのかねて、岡崎まで焼き肉食放題にいくっつーことでついていったら、店が改装中(T_T)。しかたないのでびっくりドンキーで飯。岡崎にいった意味が無い(T_T)。まあ、内藤君のおごりだったから良しとしやう。

今日

うむ、おきたらもう夕方だった。つかれがたまっていたのかにゃ

今日はなんの日?

こないだの続き :D

浩: おーい
葵: あ、先輩!
浩: ごめんごめん、またせちゃったかな
葵: そんなことないですよ。私が早く来すぎただけですし
浩: それじゃ、行こうか
葵: はい(^^)
……
綾: (うーん、あの二人、どこにいったのかしら…。あら?)
葵: あっ、綾香さん、こんにちは
浩: よう
綾: なんだ、神社にいないとおもったら、今日は二人でデートだったの?
葵: で、でーとというか、あの、えっと、先輩が私に誕生日プレゼントをってことで、お買い物にいくんです
綾: そ、そうなんだ、ふーん、誕生日プレゼントかぁ……(いいなぁ)
綾: (じー)
浩: な、なんだよ?
葵: あっ、そういえば綾香さんの誕生日って、今日だったんじゃ…
綾: え、あ、そういえばそうだったかもね
浩: へー、二人の誕生日、近いんだな
葵: そうなんです。以前聞いたとき近かったから覚えてたんです
浩: そうなんだ。…ん、(ニヤリ)なんだ、綾香、おまえも誕生日プレゼント欲しいのか?
綾: そ、そんなことは…
浩: 遠慮するなって、今日のオレはココロも財布もけっこう暖かいからな。あ゛、でもお前の場合、もっと豪華なものがもらえそうだなぁ。ちょっとそれに張り合うのは無謀かな(苦笑)
綾: そ、そんなことない!
浩: お、まあ、それじゃぁ何か買ってきて、明日にでも…
葵: あ、それじゃあ綾香さんもこれからいっしょにいきませんか?
綾: え、でも…
葵: 私はかまいませんよ(^^) みんなでお買い物しましょう :D
浩: うーん、しょうがねぇなぁ、よし、葵ちゃんもそういっていることだし、ついてきてもいいぞ
綾: それじゃあ…お邪魔させてもらうわ。そうと決まれば早くいきましょ♪ (ぴとっ)
浩: えっ(汗)
葵: あっ… (゜o゜)
綾: なにやってるの葵、まだ左手はあいてるでしょ♪
葵: !!……………(おずおず)(ぴとっ)(ぎゅ〜っ)
浩: ……そ、それじゃ行こうか(大汗)

謎のらくがき(jpg:58k)

…こういうことを思いつく私はダメな人でしょうか? そこ、さすが浮(以下略)


1999年1月24日の電波状況

昨夜

牧野君が遊びにきた。でもって KEY 1〜15 総観賞とか。さすがにつかれた(^^; 私はこないだ全部みたばっかだったりするので、見ながら落書きしてたりとか。

今日

朝までみてて昼までちょっとねる。昼は内藤君がおごってくれるっつーのでついていく。ごちそうさま。

とこちゃん

つーことでラフ画放出。


1999年1月25日の電波状況

ぐる

あ、ども〜 Leaf IRC のほうでは長らくお会いしてないような…。 エンブレムのデザインですが、適当です(^^; きっちりデザインしたいところですね。「BSD」のロゴの下に、OpenBSDのバナーにでてる謎の物体のようなデザインのマークをいれようかと思ってました。

となると、Red hat 系なみんなは、アイテムカード「体操着」(参:LFTCG 電撃大王 1999/2 特集)がつかえたりするんだろうか(謎)。当然赤で(笑)。あかりは作中ではないんだけど、アニメ用資料とかポスターとかででてたしね。

いえいえ。私も好きで描いてますから。そろそろとこちゃん以外も描かないとですね。で、 制服の件ですが、「制服もある学校」というのはどうでせう。セーラー服、ブレザー、私服から選択可能(笑)。気分に応じてどれきてきても良し!

ふふり。 パジャマはおもいっきりねらってみました:)

ああ、 よしだともこさんまで ^^; いったいどこまでひろがっているのだろう? GIMP ml でも「期待してます」とか言われたし(汗)

かいもの

おお、うてな、そういう展開にしましたか。夜子と苺ちゃんあたりと健をからめるのかしらんとか最初思ってたんですけどはずれたようで。そろそろまとめですね。

KaNa は絵の雰囲気にひかれて買ったのでした。まだ話は導入部。

DHTML

ちょっと MS社の大量の資料群CSS2を少しまじめに読んでみる。むぅ、floating object の扱いは こうしないといけないのかぁ。通常のレイアウトとは別の流れにしないといけないのね。相当つくり直さないといけないぞっと。IE はしっかりこの通りのアルゴリズムでレイアウトかけてますな。もじら? ダメダメっすよ。

Positioning の設計の青写真ともからめてけっこう細部を考え直す必要がありそう。こういうものつくってると、DHTML と DOM が必然的な流れで登場してきたのがよくわかりますね。 MS社は、少なくともこの分野、WEB関連技術に関しては、積極的に「Openな規格」の制定に関わることによって、業界をリードしていく戦略をとっており、またそれに成功していると思う。はたして、もじら5 はいつでてくるのであろうか? 遅れれば遅れるほど不利になるぞっと。

私のころは、PCには内蔵で BASIC がはいっていて即、利用可能で、それから入門したものですが、今の時代だと、はじめからネットワークに即つながるような環境で、コマンドラインとは無縁の世界なわけで、この場合、HTML → DHTML (Java/JScript) → CGI (Perl など) と進んでいくのがなんとなく良いような気がするのでした。JavaScript はインタプリタだし、即時に画面に反映されるし、表現力けっこう高いし、クライアントサイドで動作できるしなかなかナイスなり。

GIMP

GTK と GLIB がちょっと新しくなっていたのでいれなおし。ついでに、 GTK のバグの報告が ML のほうででてたので手パッチ。あら? 変化がないぞっと……あう、ダイナミックライブラリのメジャー番号あがってるのね。再リンク…あう、けっこう変わっているところがあるようだ。再コンパイル… 完了。保存とか読み込みとかでセグメンテーションフォルトでおちてたのが無くなった。ようやくまともにつかえる(^^; ためしぬり(jpg:49k)意味無し。何がどう BSD なんだか(^^;

ぐる

DOS4 はたしか FAT の構造がかわっったりとか互換性の点でいろいろ不幸なことがあったわりにはあまりメリットがなかったりので NEC は結局ださなかったと記憶してます。

そういや

かきわすれ。なんか、Unix User の 2月号の IW98 のレポート記事にわたしの発表の模様の写真がでてるらしいっす。あと、4月号に、発表の Real データが入るらしいっす。おお、全国デビューだ(ぉぃ)


1999年1月27日の電波状況

CSS1 の test suite か…。うちのるりるりで挑戦してみるも、とりあえず止まる(笑)。ダメじゃん。挙動からして、まず BASE の処理のあたりでとちくるってるものと思われます。

謎ブラウザですが、当分、「使おう」なんて思わないのが吉です(^^; そもそも、いまのところ、ソースを読んで起動方法が理解できる人しか想定してません。あと Lapis は HTML4.0 strict ではないです。けっこう緩く処理します。ただ、その「緩い」部分で想定してないものがくると、とちくるうことがあるのは確認ずみです(^^;

今後ですが、CSS2 および DOM 対応のために内部データ構造が再びいじくりまわされるでしょう。ドキュメントデータ は DOM にあわせてメンバーとメソッドを再構築します。現在の表示パースの情報はブロック構造の親子構造の単純なツリーなのですが、これだと CSS2 Positioning がまともに処理できないことがわかってますので、ツリーをn本かかえてそれぞれ別々に再計算できるようにします。あと、Floating の処理を勘違いしていたので、これも直さないといけません。さらにさらに、table も実装しないといけないのね。

本当は、パーサの SGML(XML)化も行ったほうが良いのですが、私の能力がおっついてないのでもひとつ先の話。

ぐる

私も74年度です。ちなみに4月うまれ。だいたい私の前後1、2年ぐらいまでが、「8bitパソコン最終世代」ではないかと思ってます。

私、 既にあまり偉くないです(^^; 最近の XFree86 関連とか、1.2系列とかなにもしてないし。やっぱ今一番偉い人は、塩崎さんな予感。

とこちゃん

えと、うちの日記の読者の方からメールがきたので転載。

申し訳ありませんが、「匿名希望のある人からのコメント」ってことにして
いただきたいのですが、とこちゃん関係のネタです。もう既に出ているかも
しれないのですが....

謎の姉妹「ヴイエイト/ヴイナイン」(ベルラボの V7/V8)
さらに謎の天使「プランナイン」(Plan9)
さまよえる (オランダだから) こびとさん「ミニックス」(MINIX)
「でもちゃん」と仲のいいこびとさん「マーク」(Mach)
ある帝国の捨て石キャラ「ゼニックス」(XENIX)
ベル型のヘルメットの怪人「ダークベルメット卿」
# 元ネタは、「スターウォーズ」のパロディ「スペースボール」の、
# 「ヴェーダー卿」あらため「ダークヘルメット卿」
# 参考 : http://www.enjoy.ne.jp/~misuzu/gennki.htm

なんてのを思い付いたんですが、日記的なものを特につくってないので、
送ってみることにしました。

えっと、やっぱこういうのは匿名でなくて直接参加が楽しいですよ〜とか言ってみるテスト:D こないだ一つ「匿名」でのせたんですけど、あれはしっかり「K様」って書いたからわかる人にはわかったことでしょう。 (これはいそがしかったのでメールでだしたとのことでした。)

新JIS漢字

fj.kanji がひそかに熱いっす。

とこちゃん

むぅ、なんか描くたびに頭身違うし…。ところで変身したら成長したりするのでしょーか? あくまで「案」ですので、「オレはハイソックスが好みだな」とか「いや、片靴下ぢゅーよー(謎)」とか「スパッツで決まりだね」とか「だれがなんと言おうとミニスカート」とかいった意見を言うと反映されるかもしれませぬ。

もひとつ。

こちらをうけて の図。ポイントは涙。

HTMLにおけるエンコーディング指定

話題がひろがっているのらということで、うちの過去日記から関連しそうな話題をひろってきてみたりする。

こんなところかな。けっこうあったな。ちなみに、私は HTTP ヘッダの Content-type: で指定してあります。 html 関連は全ファイルを iso-2022-jp で統一してあるので、 .htaccess にてAddType で指定。

AddType "text/html;charset=iso-2022-jp" .html
AddType "text/html;charset=iso-2022-jp" .shtml

細かく制御したい場合は、 mod_cern_meta つかってメタファイルを準備するか、 こがセソセイのパッチあてて、 AddCharsetを使うとかして拡張子制御すれば良いでしょう。

@ ローカルファイルシステムに HTML を保存するのはやめて、目的のデータを取得日時と元URLを含めて保存しておけるような特殊なオレ好みコンテンツ保存用 WWWサーバがあったらおもしろいかな。構造的にはキャッシュをもった proxy サーバで、その情報のとりだしかた (DB に保存されているものを参照/現在のものを参照)というのをコントロールする機構もってるもの。

通常の参照はブラウザから proxy として指定。コントロールクライアントのほうで、URL 入力すると、特定の URL の情報の「ある日時」を指定して保存してあるものの一覧が示されて、それの中から目的のものを選択すると、それが proxy を通して見えるようになって、ブラウザがそれにアクセスして表示。現在の状態を保存かけたいときは、そのコントロールクライアントから、情報をたぐる深さとかを指定すると、それをまとめてもってきた上でパックして保存。

だれかつくって(笑)

雑記

sugich さんとこ読んでどうしてもゲッターの変形合体の実現がみてみたくなったので、Hobby Japan を立ち読みにいく。ぐはぁ、こりゃすごいぞ。みんなにも見せるために買ってくる(^^; 宇井君にはうけた模様。

@ あと、こないだ KEY みた影響で、「てのひらの宇宙」が聞きたくなったので、はいってる CD をさがしたり。「岩男潤子コンサート kimochi in 東京国際フォーラム」にはいってるなっつーことで査収。こうしてどんどんはまっていくのだろう。たぶん。

@ もひとつ。Looker の東鳩アニメ記事たちよみ。むぅ、あかりぃ、なんか可愛いぞ:D。犬ちっく風味がばっちりかもしだされてますな。あかりは日記をつけているそうな(笑)。なんか部屋にくまいっぱいあるし(^^;

@ 某Leaf IRC にて、私の名前が日経バイトにでてるよ〜といってたので、研究室におちてあるのを読んでみる。特集の「マイクロソフト以外の選択肢」第三部「オープンソース時代」とかいうなかで、日本発のオープンソースソフトのものの一つとしてnamazu と並んで「渡邊剛氏らが開発したX-TrueType Server」とかでてた。それだけ(^^; その直前の部分で、こないだの LC98 でのおごちゃんの、「日本発のソフトで Linux コミュニティからのものが KON とか RUBY とかぐらいしかない(かなり概略)」みたいな談話がふれられてるんだけど、私の記憶が正しければ、そのとき「XMulti」も名前があがったはずなのだが…(まあ、XMultiつくった人はLinux な人じゃないんだけど(笑))、黙殺されたらしい。ちっ(ぉぃ)

文字コード

みゅぅ、iso-2022 至上主義って、うらがえすと Unicode 至上主義に近いものがなくもないのでアレだと思います。通信用のコードとして iso-2022系の方法は最適かと思いますが、単に「iso-2022」とした場合、それがどこまでの範囲のものをさすのか全くもってわかりません。 iso-2022 はなんらかの制限事項を加えて使用する文字の範囲を明確にきめて利用するのがベストであり、その場合に「どういう制限を与えたのか?」という、エンコーディング方式の指定は結局必須です。 iso-2022-jp, iso-2022-jp-2, iso-2022-int-*, Extended Unix Code JP, etc, etc. 「iso-2022で登録されてるものフルサポートしろ」って言われたら私泣きますよ。

なんか用語混乱しているようですが、 Content-Type の charset 指定は文字集合指定じゃないです。念のため。 HTML4.0 で「Document Character Set」として規定されているものはあくまで ISO10646です。 Content-Type における「charset」は encoding の指定です。

MIME の Content-Type における encoding(charset)指定は、あらゆるコードの統一は事実上不可能なことと、通信上の「自動判定」に限界があることを念頭において考えられたごく全うかつ無難なものだと思いますよん。

そもそも SGML というのは、「固定長」なプレーンなコードが大前提なシステムであり、また、処理する範囲のコードのわりあてをことこまかく規定しておかないと処理ができません。そういうシステムです。 EUC 使うときは正確に行うためには Packed なもの使いますよね。 (多バイトが通るようにしている処理系もありますが、それはあくまで ad hoc なものです) で、まあ、この条件を一応満たして、そしてかつもっとも大量の文字をふくんでいる規格は、iso10646 のみです。これが選択されたのは必然といえば必然でしょう。

あ、ちなみに iso2022 にのっけて UCS で通信する方法はしっかり存在しますよんそのためのエスケープシーケンスが定義されており、復帰方法も定められています。正確なとこは規格参照のこと。

なんか私が何をいいたいのか全然まとまってない気もする。「排他はだめよん。排他は」と、「Content-Type における charset指定は必須です」かにゃ。


1999年1月28日の電波状況

ぐる

私は弓削商船高専出身です。学校に船あるのよん。 74年組からはなれますが、高専な人というと、 あさだセソセイ もたしかそうでしたね。

@ むむ、「 オレや雅史の恥ずかしい過去が記録に」っつーとこまでは想定しましたが、そこまで具体的にはおもいつかなかったぞな。 Hosちゃん、才能あるよ。くすくす。とりあえず、机の引き出しで発見できなかったので、タンスの引き出しをあけてみたら下着がいっぱいはいってたりするのはお約束だね<ばきぃ

@ ついでにたぐった先から PALETTE のサントラ注文したり。ネットでのおかいもの、Solaris 7 の次はこれか(^^; WA のシングルもついでに発注。このあたりだとどうも発見できなくて…

@ なになに、 岩ちゃんベストが3/3φ(..) シングルもあるんですね。さがそうっと(^^)。昨日のBGMは一日中コンサートのアルバムだったのでした。岩男潤子さんの音楽聞き始めたのは浩子さんが曲を提供したってのがきっかけなのですが、ちょこちょこ聞いたりしているうちに、お気に入り指数ががぜん向上してるのでした。コンサートもぜひいってみたいですね。最近浩子さんのMLで岩男潤子さんのコンサートにいってみたというネタがいくつかありました。ノリに圧倒されてたようです(^^; 岩ちゃん版の「海の時間」が聞いてみたい今日このごろなのでした。

とこちゃん

そらりすきゃんぺーん実施中♪ヽ(´ー`)ノ。 Solaris ってけっこう好きだったり。なんといってもやっぱ「標準」。一種の理想ではある。古くからある BSD と SystemV それぞれの魔法の体系を一度整理しなおした、新体系「POSIX」を完全習得してるんだにゃ。

とりあえず おさげぢゅーよーってことで。

ちょっとはなやかに。トライデントじゃなくて謎のスティックにしてみた

WWW関連よもやま

おお、 私がほしいもの すごく近いですね〜 Packrat。ただ、私の場合、「ほしいページだけ記録してほしい」なので、その操作のためのインターフェースがほしいです。一般の参照はキャッシュだけで OK です。指定した部分だけデータベース化してほしい。あと、従来のブラウザからごくごく簡単につかいたいですから、インターフェースがもっと簡便なほうがうれしいかな。たとえば、URL の直後に ? だけつけて要求すると、そのページに関する登録情報一覧がさくっと表示されるとか。あと、その一覧のところに登録動作や登録情報検索とかを行うためのフォームがくっついてるといいかな。

あ、あと、1ページだけの参照ではなく、連続した参照を行いたい場合があると思うので、proxyが状態を保持するようになっているほうが使い勝手良いかも。これはたくさんの人が使うとすると問題あるけど、「個人利用」ならそれでいいかなってことで。Cookie を使うとかかえってくるページのあらゆるアンカーを「拡張URL」にしてしまうという手もあるかな。こういうのはやっぱ「専用クライアント」があると、拡張 HTTP なり他の拡張プロトコルなりが使えて、状態保持やらインターフェースをクライアントがもてるのでいろいろ便利なんでしょうね。

DHTML

本吉君の「 「IE の DynamicHTML でゲームが作れるか?」 がさらにさらにグレードアップ。はっきりいってすごいです。 IEを使用しておられる方は必見です。ちなみに私は絵をちょっと提供しただけっす(^^;

UTF-8

そういう観点では問題は生じません。 UTF-8 は、(もし FreeBSD の環境がありましたら man utf2 で参照できます。utf2 と utf-8 は同じものです) 31bit のコードを octet 列に変換する エンコーディング方式で、ASCII の領域 (0x00 - 0x7f) が完全にそのまま保持され、また他のいかなる文字もこれと重なるコードになることがありません。この点で EUC と同等です。だからこそ内部コードとして採用されるのでしょう。なお、iso10646-1(unicode) における日本語の文字はすべて 3octet になります。

書いちゃえ。次のようになります。

[0x0000 - 0x007f] [00000000.0bbbbbbb] -> 0bbbbbbb
[0x0080 - 0x03ff] [00000bbb.bbbbbbbb] -> 110bbbbb, 10bbbbbb
[0x0400 - 0xffff] [bbbbbbbb.bbbbbbbb] -> 1110bbbb, 10bbbbbb, 10bbbbbb
[00000000.000bbbbb.bbbbbbbb.bbbbbbbb] ->
                               11110bbb, 10bbbbbb, 10bbbbbb, 10bbbbbb
[000000bb.bbbbbbbb.bbbbbbbb.bbbbbbbb] ->
                     111110bb, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb
[0bbbbbbb.bbbbbbbb.bbbbbbbb.bbbbbbbb] ->
           1111110b, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb

もうひとつ、UTF-8 の特徴として、octet 列を後ろからさかのぼる場合に、文字の切目があたままでいかなくてもすぐ判明するというのがあります。これは EUC では決して得ることができない利点です。

HTML と 文字コードとブラウザと

うーむ、私も記憶および、 Mosaicc-L10N 2.4 のコードみて(これいじょう古いものを発見できなかった…)言っているのですが、Mosaic は いわゆる X/Motif の「国際化」は表示部分では使いません。表示系はすべて低レベルな関数をつかって組んであります。 Motif はインターフェースおよびリソースの処理用としての利用にとどまります。国際化の表示系を利用していたのなら L10N のパッチ不要でとりあえず一つの言語なら表示できたはずですが、実際はそうでないからこそかなりの改造がおこなわれたのです。

@ そもそも、こういうさまざまなエンコーディングを扱う可能性のあるものには、 locale モデルによる機構は「使えない」のです。だからこそ Netscape も IE も Mosaic と同様の構造になっているのです。これは OS の問題ではありません。「Locale の機構そのものが要求をみたさない」という点を問題にするのなら、まあ、そりゃ OS の問題かもしれませんが、それはあらゆる OS にいえることであり、やはりこれはブラウザの実装の問題です。

@ Mosaic の Shift JIS や GB(これを忘れてはいけない)などへの対応は相当早い段階から行われていたと記憶しています。 delgate がもっとも活躍した局面とは、Win の 初期の Netscape が Shift JIS のページならさくっと表示できたので、それへの変換を行うためと、文字→図形変換機能をつかえば、Unix の Netscape でもページが見れたので、それのため、という点だったのではないでしょうか。

@ ShiftJIS がサポートされたのはもちろん Windows の存在があったからでしょうが、同様に EUC がサポートされたのは、Unix で広く利用されていたからです。両者に「諸悪」に関して差はないでしょう。EUC はたしかに iso-2022 の一部ですが、エスケープシーケンスを利用しないため、EUC 限定にしたコードは全くの別物になりえます。そして実際別ものでした。EUC 用に書かれたものは iso-2022 の高度なものを処理するためには使えません。 Unicode (UTF) に対応したブラウザが登場したのは本当にごくごく最近のことであり、この議論での「諸悪」の候補にはあたらないと思います。「Unicode にしたら当時の Netscape で簡単に表示できた」は記憶違いじゃないでしょうか?

@ セソセイのほうですが、曽田さんからメールがあったかと思いますが、「 ISO 2022 ベースの encoding は日本以外ではほとんど使われていない」は、正確ではないですね。 iso8859-? も EUC も、全部 iso2022 ベースの encoding ですから。従来のコード体系は、インドのコード体系、Shift_JIS、GB など一部(とはいえ、人口ベースではこれを利用している人は非常に膨大)などを除いてほとんどすべて iso-2022 ベースでしょう。

@ もっとも、「エスケープシーケンスによる切り替えを利用した」という条件を頭につけるとこれは非常に少なくなるわけで、セソセイの主張がひっくりかえるわけではないです。日本でも結局のところ、メールとニュース以外では UNIX では ほとんど EUC-JP つかっていたわけですしね。このタイプの iso-2022 でサポートされていたのは iso-2022-jp と iso-2022-kr ぐらいかな。Mule 以外での iso-2022-jp-2 のサポートがいろいろとおこなわれていたならば、少しは状況がかわったかもしれませんね。

@ なんで Unicode が使われるのか? 世界で一番多いPC で動く OS で採用されているから、というのはもちろん条件の一つですが、結局のところは、「コードを書く人」がそれを採用するからなのです。 Unicode は特定の用途においてはむしろ非常に便利であることをお忘れなく。「日本語 + 欧米圏 の文字を同時に併用したい」、といった目的ならば、「互換性がない」「表示系の設計が絶対美しくならない」「目的の文字が無い」といったことに目をつぶれば、むしろ便利なのです。

@ ちょっとそれたのでもどして、 なんで iso-2022 系メインにせずに、 Content-type で charset を指定するようにしたのか? ということへの答えは、結局のところ、「既にそうでないものがいろいろと普及していたから」これだけのことでしょう。 ISO2022 ブラウザは作れなかったのではなくて、おそらく、「手間のわりに作る必要性を感じなかった。」、SJIS と EUC をいれたのは「ニーズがあった。」やっぱこれだけのことではないあかと。

@ あ、SGML は絶対なんらかの形で Plane な符合化文字集合が必要ですよ。あと、文字とコードが一対一対応である必要があります。 DTD 宣言中で、「コード」に対してひとつひとつ役割をあたえる必要がありますからね。そうだからこそ、「ISO 2022 もうまく規定すれば、そういうような内部エンコーディングを作ることができると思いますけど。」そう、つくらないとダメなのです。そしてそれは作られなかった。「内部コード」として利用する分には、こういう Plane なコードはアプリが任意にさだめることができるのですが、SGML というのは基本的に「公開」と「共有」が前提ですから、まあ、難しいところですね。

@ 現状で重要なことは、「Unicode だけでは処理できないものがある」ことを認識し、そういうものをカバーするためのものが、はいりこむ余地を残しておくようにシステム設計を行うようにしよう、というところではないでしょうか。その観点から、私は GlibC の locale を基本的に否定するのでした。まあ、これいいだすと、他にもいろいろ文句つけないといけないんだけどね。

ぐだぐだ書いたからあまりまとまりないや…めんどいので読み直しもなし。


1999年1月29日の電波状況

とこちゃん

BGM つき予告できたのね。えーといくつか。

再録の際など、上記項目検討していただけるとうれしいです。

@ ソラリスちゃん、 OpenSource の力をとりもどすのか(事実誤認) どうせなら、libc 部分公開して GNU libc (の locale 部分)を駆逐してほしいな(ぉぃ

ぐる

うちの高専の制服ですが、男子は3年生までは全学科共通で詰め襟の濃紺の学生服。ただし、袖のボタンの配置が普通の 2×縦 ではなく、3×横に配置されています。さらに、商船学科のみ、「制帽」が存在します。 4年次から制服がブレザースタイルにかわるのですが、通常時は私服です。式などのときだけ着るのでした。全部採寸してつくるのにもったいない。さらに、4年次からの制服は、商船学科と他の学科とで異なります。他の学科はシングルなのですが、商船学科はダブルで、また、オプションで肩とか袖とかにくっつけるものがあるようで、制帽もあわせて完全装備すると、「水兵さんみたいでかっこいい」になるのでした :D

@ ずばりその「あそびにいこうよ!」だったようです:) 私もまあ、ゆるゆる系のほうが好みですかね。「あそびにいこうよ!」はかなりお気にいりなので、踊るのもいいかも(^^) 「…みたい(KEY風)」

@ 浩子さんのコンサート、私が行ったことある範囲では、一回「鳥は鳥に」を合唱したことがあります。伝え聞くところでは「テングサの歌」は会場からかけ声が入るのがお約束だとか、あと「パセリパセリ」で、本物のパセリが会場からとんできたことがあるとか、かつては「総立ち」もあったとか。イベントで、観客が舞台の上でにあがらされて、AQ さん振り付けで浩子さんの伴奏で歌うっつーのはあったとか。

基本的には浩子さんのコンサートは「ゆったりと寝に聴きに行く」ですね。「カイの迷宮」(もうすぐですね。いいなぁ)は「観に行く」だったけど:D

WWW

けんとさんとこ経由で、 International Layout in CSSの Working Draft へ。こないだの ruby も含まれてますね。これってはやっぱ IE6 に入れることが念頭にあるのかしらん(see Editor/Contributors)。「次次世代」ブラウザ競争はひそやかに開始されているのね。

とりあえずおもいついた問題点

英語ができる WWW の偉いセソセイがた、ここ読んでおられましたらぜひつっこみよろしく(ぉぃ) そのときついでに、CSS に「Script(用字)」の概念をつっこんでくださるようおねがいします。わたしゃスクリプト別にフォント変更したいです。というか、「スクリプト」の概念を投入して、font-stretch と組み合わせれば「全角」「半角」に相当するものがもっとうまく定義できますよね。ずばり font-stretch で 「hankaku」って指示できるようにしちゃうとかね。それが正解だと思う。

あ、いま読んでて気付いた。「固定ピッチ」と「プロポーショナル」の区別の指定をふくんでる(text-justify-trim)。ニヤリ。あう、でも、「This Applies to full-width characters only」って表現がかなりひっかかるぞっと(強調部は私)。

うむ、やっぱそこはかとなく「MS」(苦笑) でも「Half/Full-width」な表現以外は許可(←偉そう)。スクリプトに応じてレイアウト処理が変化しなければならないことは純然たる事実だから。

@ さて、うちの娘にもこういうのに関連した描画機構はほしいわけですが、どうしましょ。とりあえずそこそこ合わせてつくってみるか。ちなみに System1 関連のほうは質問メールだしてみるつもりでまだだしてません(^^; 今日あたり書いてみます>誰とはなく

@ しかし、 推奨ブラウザですか(^^; ありがたいことですが、まだまだまともにつかえるようになるには時間がかかりそうです。どうも世間の流れってはやくって、情報おいかけるだけで大変です。なお、Agent 名が変わることはないでしょう。あ、もとネタって、電波届くほうなんですけど(^^; それはいちおー認識されてますよね? ちりちり。「バカばっか」バージョンもつくってもいいですけど :D

@ さらに追記「Comments in languages other than English, in particular Japanese, are also welcome. 」って書いてるじゃん。よかった。自分で書きます。はい。もすこし整理してからにしよう。みんなもにたようなこと書いておくるしか!

ファイルとコード

ファイル中の文字コードとアプリの内部コードの関係の問題。解決方法その1 は、「ファイルも UTF-8 に統一」。その2 は locale モデルに従う方法。すなわち、LC_CTYPE によってファイルのコードが決定されるというもの。現行 UNIX は基本的にこれです。 Locale を正しくサポートした Cコンパイラならば、C のソースコード中にうめこまれたワイド文字列はコンパイル時の locale によって処理されます。 Xtoolkit のリソースデータベースや、libc の メッセージ処理などがこれですね。おそらく gtk もこのあたりを踏襲するつもりなのではないかと思われます。

その3 は、おっしゃってる通り「ファイルごとにエンコード指定する」です。 私もちょくちょく話題にあげましたし、塩崎さんも最近いっておられましたが、「ファイルごとにメタ情報がもてるファイルシステム」を採用すれば、これが実現可能です。Mac がファイルの種別を決定するためにこういうことをおこなってますが、それにエンコード情報までふくめてしまうわけですね。

通信とコード

変じゃないと思いますよ。その「通信のための共通コード」として考案されたのが「ISO-2022」であるというところがミソです。で、それがあるにもかかわらず、それと互換性なく登場したのが UTF-8 (だけじゃないけど)なわけで、「統一が無理」だから MIME でのエンコード指定が登場したのでしょう。 ISO-2022 でも invoke とかの指定をはしょると相互通信はできませんしね。

追記:「統一は無理」なのですが、「ASCII」については統一されてるとみていいでしょう。ASCII とのコード互換が無く、MIME でのcharset(エンコード) 指定を行うのがこまったちゃんになってしまう、JIS X 0208 とか UCS とかを直接通信に利用することがまず無いのはこのためです。UTF-8 は ASCII と互換性ありますからね。もひとつ。7bit 系の iso-2022 系の体系が、「改行時は ascii にもどす」と規定かけるのもこれに関連するでしょう。

@ 文書のコードのほうですが、HTML文書は SGML文書なわけで、本質的には、「利用するコード」は各自が個々にきめるものです。DTD宣言さえすればという条件がつきますけど。で、共通の DTD を指定するから「統一コード」なのです。オレDTD 書くのなら「SGML」なら オレコードつかって良いです :D

「HTML文書を人間が(直接)書くのはまちがっている」ってのは、まあ、「コードを気にしないといけない」という側面もあるとは思いますけど、それ以前に、「タグづけなんて人間のすることじゃない」のが大きいとは思います。


1999年1月30日の電波状況

ふと

らくがき。

なんか年齢が設定(10歳)より低く見える気もしますが、仕様です。

だれかがおれの頭の中に電波を送ってくるんだ〜

はちさんとこからたぐった先の 疑問。解説するのもちょい野暮な気もしますが一応(^^;;

「電波系」ですが、サブジェクト↑に書いたような人、その行動、関連現象とかその手のことを指すことばです。特徴としては、細かい字でところせましとびっしりかきこまれた謎の文書とかでしょうか。受信した内容を書きとってるわけですね。電波を送ってくる人は神様だとか、宇宙人だとか、自分に悪意をもっている人だとかいろいろあるようです。この日記もおなじようなものだったりして(謎)

太田出版から「 電波系」という本が村崎百郎/根本敬 共著、木村重樹 編ででてますので、そのあたりが参考になるかもしれません。とっても電波な本です。もうすこし初心者レベル(ってなんだ)ですと、「新興宗教オモイデ教」(大槻ケンヂ・角川書店/文庫)あたりがお奨めでしょう。 Leafの Leaf Visual Novel Series Vol.1 『雫』は、このオモイデ教のオマージュだとよく言われてますね。キーワードは「毒電波」ちりちりちり。

私の日記中でこういうことに関連する言葉とかがでてきたときは、まずまちがいなくこの『雫』関連です。くすくす。いつも電波とどいてるよ。そうそう、To Heart も「君にとどけ、テレパシー」だから電波系ですね (大いなる事実誤認)

追記。日記者な人たちは単に携帯電話やPHSなどのことをさして「電波」と言っていることが多いかと思います。私もふくめて。

とこちゃん

しゅがいさんの心配 私がちょい前に書いたことと近いものがありますね。 私がこれを書いた理由もやはり、「話がおおきくなりすぎている」感があった からです。本質的に相当「私的(少人数の範囲)」なものなのに、過分に「公的」ととらえられてしまっている雰囲気を感じたのでした。

こういうのが好きな人には格好の話のネタなわけで、 とこちゃんうぉっち を中心にして、とこちゃんわーるどに「参加した」という感覚が得られ、それは非常に良いことだと思いますし、このあともぜひ続いてほしいですが、この話がはじまった当初の目的になっている部分は決して見失ってほしくないです。

@ ということで塩崎さんに要請。とこちゃん関連で現在存在する具体的なプロジェクト、「とこちゃん本(仮称)」( 仮想番組のでっちあげ、およびそれに関する設定本の作成、Comiket 56 での領布) をとこちゃんのページのほうに明確にのせるようにおねがいします。「アニメそのもの」の作成計画は全くもって存在しないことに注意。この領布を支援する基地になるのが、「 はうン しすてムズ」で、「とこちゃん本(仮称)」プロジェクトの発起人はなあくさんです。具体的な参加者はまだ完全には固まってないですが、hauN に近い日記者の人たちによるものだと認識しています。「内輪ネタ」おおいに結構だと思います。

@ なお、私のプロジェクト内での立場ですが、キャラクタ関連の「外部委託デザイナ」だと認識していて、その旨はすでになあくさん他、しすてムズのみなさまには伝えてあります。私は「はうン」のメンバーではありませんから。そう自分で言っている「外部」な人がのようなことを言うのはちょっと筋違いな気もします。すみません。

@ おまけ。私が自分を「外部の人」と位置づける理由ですが、私は既にこういう関連では、「CCLUB別働隊」、「苺電波部」の一員で、他にこれ以上「所属」を増やしたくないというのがあるからだったりします。まあ個人的な気分の問題です。ついでに、Leaf 関連ではこれらとは全く無関係に「個人」でうごいてます。次もなんかつくるのでどっか委託させてね:D > だれとはなく。私信: TシャツおよびCD もうちょい待って(汗) > TFさん。私信2: 苺も次こそなんかつくろうね

コード変換

コード遊びですか。おもしろいですね。では 各種コードなど変換ツールとの有名どころ紹介とか。こういうのは覚えておくと便利です。


1999年1月31日の電波状況

宇井君とかけひ君といっしょに Joyfull に夜食くいにいったまではよかったのだが、眠くなってしまった…沈没する前に今日逃避するままにまかせて描いた絵でもあげておこう。 昨日のらくがきをしあげてみました。しあげて描いたのはひさしぶりか。仕上げるとどうなるのか比較してみるのも一興かと。

しかし、昨日も書きましたが、私が描くと、年齢と頭身が下がる…。まあ、らくがきの域はいちおう越えたかな。 PILOT の製図ペンでペン入れしたあと、スキャンして、gimp 1.1.0 でぬりぬり。すこしでもメモリ消費をおさえるため、Cut & New Layer を駆使して小さなサイズのレイヤにしてごりごり。ちなみに、元サイズは 900×1200 pixel でレイヤは 14枚利用してあります。印刷物を考えると、300dpi B5 として 2150×3036 のサイズで描きたいところですが、うちのマシンだとどうにもつらいです。ちなみにでじこちゃん (本名 デ・ジ・キャラット)っていいます。謎のルートからの謎の(ってCMなんだけど) 映像みてヒットして突発的に描いたのは秘密だ。

fj

fj.unix の fj.comp.unix 移動に関する CFS(Call For Signature) が始まっています。期間は 2/17 まで。 移動の署名よびかけ、それに対する 反対署名よびかけ

CFS では、最終決定は次のようになっています (NGMP Ver6 3.6.4)

募集期間終了後、署名管理者は3.6.3節「投票結果の公表」に準じて収集した署名内容を公表しなければならない。公表が著しく遅延された場合、委員会はその署名の案を無効として考慮対象から除外することができる。

50票以上かつ最も多い署名を集めた案が採用される。同一署名数の案が複数ある場合は管理人が選択する。この選択に関する異議は認めない。どの案も50票以上の署名を集めなかった場合は提案が却下される。

ということで、どちらかを選んで署名(メールによる) するか、もしくは、傍観するかということになります。私はおそらく票が50あつまらないとみて傍観、の予定。消極的移動反対です。

話はうってかわって、fj.os.bsd.misc、ついにとこちゃんの話題が(汗)。あそこででるとはちょっと思ってなかった。私の場合、下手すると fj の AUP にふれちゃう気がするので、軽く反応して、そこまで。コミケなプロジェクトからはずれてる人だと問題ないかと思います。

DHTML

本吉君の DHTML なゲームに反応が ちら ほら。ほんとよくできてますよね。ベンチ将軍はちょっとアレかも(笑)

少なくとも現在のところ、Dynamic HTML の素姓は明らかに IE のほうが優れている(性能の点でも、「規格」という点でも)ので、これから勉強されようという方は IE で勉強することをおすすめしておきます。 Netscape Communicator はこのさい無視しちゃっていいです(マヂ) NC5 が土俵にあがってきたらその時また考えれば良いでしょう。

このシステムの構造の解説はホントは本吉君におねがいしたいところですが、基本はだいたい次の点でしょう。

ぐる

ううっ、 ひどいやセソセイ。でも正しいかも。しかし、 「だんご3兄弟」をチェックされてるとは。さすがセソセイ、お目が高い。あまりのベタベタさに私にはちょっと衝撃だったですよ。あれ?「みんなの歌」の枠じゃなかったですか?

まだまだ続くコードの話

曽田さんからのメールの紹介をちょっと書く予定。せっかくいただいた情報ですからね。うちの日記、なんかコードの話ばっかしてるのですが、このあたりに興味もってくれる人が増えることを願います。

とこちゃん

とこちゃんの広がりに関してでてる意見とかへの返事をちょこっと書く予定。私が無駄に心配してるだけなのかもね。

あとキャラデザインについてちょろいと質問とか案募集とか含めて書くつもり。

[←前のページ]
[次のページ→]