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

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

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

1999年2月21日の電波状況

昨日

あかり誕生日絵をあげたあと、帰って一時遮断。それからLeaf IRC 豊橋地区の面々 (私、せりおさん、みゆちゃん、あと東京からきた猫又さん) とでミニオフミ。とりあえずうちにやってきた猫又さんと語ったり、おやつを買いにいったり。夕方あと二人と合流。 Cat's なんたらとかいう店で夕飯。なかなかうまかった。で、猫又さんが巨大パフェに挑戦。攻略ならず(笑)。それからガストにてコーヒーのみながらいろいろ雑談。謎の業界話とかをいろいろ聞いたりする(^^;

ぐる

完結おめでと〜。はちさんも言っておられましたが、日常描写いいかんじだったと思います。結局あかりママ登場シーンはカットされたですね(謎)。やや残念。ま、それはまた別の方面ということで…

@ ふふり。 あかり誕生日絵への反応が 。絵自体はちょい手抜きというか、簡単にすませたのですが、文書をちょっと積極的にせめてみました :D。どうやらヒットしたようでよかったです(^^)。次は初音ちゃん(妹属性キャラ) で27日なのら。

@ メンコミいきます〜。主目的は、中部にいる間に一度はかの「マウンテン」にいってみたいということでつれていってもらうのですが、ついでになのです。さっくり遭遇したりして…


1999年2月22日の電波状況

locale and I18N

Locale と I18N に関した話。たくさんあるのら。順番にいこう。

locale において正しく I18N なものはあるのか?、ということですが、答えは「ある」です。C言語の locale(以下単に locale) は実用上不十分な点が多いのは事実ですが、 I18N の要件(= プログラムと地域情報とを分離し、同一バイナリで別の地域情報で動作させることができる)は一応満たします。「charset 情報」といった概念自体が不要な範囲でのみ動作するものが locale の仕様です。それが必要になる状態というのは locale の限界をさっくり越えていますから、すでにそれを利用することは不可能です。なお、ファイル名のコードの処理はこの「不可能」の範囲にはいると思います。「複数のエンコードをあつかう」も範囲を越えるので iconv が登場してくるのです。

@ iso2022フルセットの保持ですが、 iso2022 で、94,96,94×94,96×96 の範囲で状態を保持するだけなら、 22bit あれば OK です。終端文字に 7bit, コードの保持に 14bit, 94 と 96 の区別に 1bit。3文字のものまで含めるなら あと 7bit 必要になります。

@ その某所とやらの話、もすこし詳しくお聞かせください。 OpenBSD の日本語ML (wakakusa-ML) のほうでも同様の話題がちらっとでており、本格的に全BSD をまきこんで ML かなにかたちあげて動きはめたほうが良いのかとおもっています。なお、いまのところ私の作業は全く進んでおりません。ファイル名の処理の時のコードについてはまた後述。おっしゃる通り、locale と iconv は独立です。 locale 内部では「特定localeでの」MB⇔WC といったコンバートが、また iconv では「localeとは無関係な」MB⇔MB が必要なわけですが、まあ「コードコンバート」ということでそれぞれのライブラリの低レベル処理で共通のライブラリを利用することは可能でしょう。

@ むぅ、 I18N に新しい「観点」を与えてしまってはダメでしょう。

Internationalization(I18N)

言語、単位、日付の表記、エンコーディング方式、メッセージなど、さまざまな特定地域に依存する情報をひとまとまりのパッケージにし、それらを任意に切替えて使用できる仕組みを提供すること。この仕組みは地域非依存になる。具体的には、このパッケージの切り替えは、同一の実行バイナリにおいて再コンパイルすることなしに行うことができる。

これが基本です。Unicode を採用しても、ISO2022 の charset 情報を wchar につけたとしてもそれは I18N ではありません。なぜなら、I18N においてはその情報は決して参照されることはないからです。「Codeset independent」が I18N におけるもっとも重要なポイントです。I18N なプログラムはコードの構造に依存した処理を行うことができません。なぜなら、ある locale における コードの構造は一切不明であり、locale は切り替えられる可能性があるからです。C locale において wchar_t に規定された構造は次の点のみ。

文字に関する処理を行う場合に、このこと以外に依存する処理は、「標準」として提供しているAPIを利用したものでないかぎり、禁止です。行った時点でそれは I18N なプログラムとして動作することを保証できなくなります。

@ さて、ファイルシステムのファイル名というのは、もともと C locale の範囲で処理しきれるものではありません。これは locale とは完全に無関係に利用されうるものであり、何らかの「統一コード」を規定する必要がでてきます。これはかつては「ASCII」でした。今は単純に「8bit のコード」になっているといえるでしょう(ただし一部の文字は予約)。これだけでファイル名としての用途は十分満たすわけなのですが、これに対して、「自国の文字を利用したい」といった要求がでてきます。その要求をみたすには、いくつか方法があるでしょう。一つは、「ファイル名におけるバイト列を利用している locale におけるマルチバイト文字列とみなす」という方法です。内部処理的にはもともと locale とは無関係なのですが、まあ、それを「表示」する場合にのみ「現localeのエンコーディング」という情報を利用しているわけですね。ファイルシステムに対してクリティカルなコードを含んでいる locale ではこれは不可能なのですが、まあ、おおむね問題なく処理できる方法ではあります。

@ ところが、あたりまえのことですが、この方法では、locale(におけるエンコード) が異なる場合に「文字化け」が生じることになります。ではどうすれば良いのか? それを防ぐ方法は1つ。エンコードを明示的にファイルに対して指定してしまうことです。

  1. 「ファイル名」のエンコード情報を設定/取得できるようにし、 アプリ側ではかならずそれを参照することにする。
  2. ファイル名で利用するコードを、システムの全 locale に無関係に 統一された、マルチスクリプトなコードにしてしまう

どちらも「コードを明確に指定する」という点では同じですが、後者はそれが1つになるわけですね。

Locale の枠組みを表示/入力にもちいる場合、現locale においてあつかえない文字はとりあえつかえませんから、それも「化ける」とはいえなくはないのですが… コードの意味が変質して区別できなくなるわけではないですからいいでしょう。 ファイルが削除できなくなる場合があるわけですが、その場合は locale を変更してから入力削除すれ、もしくはそもそも locale の枠組をインターフェースにもちいなければ良いのです。

前者はMIME的な発想で、システム全体を本当に低レベルまで「I18N化」するなら、これでいくべきなのですが、これは既存のソフトに対して根本的な改造を行うことを要請することになりそうです。で、そういう点から考えると、「統一コード」にするのが楽なのは楽でしょう。 (というか、ファイル名一つ処理するためだけに、一つ一つコード処理しないといけないって、イヤすぎ) その場合、問題になるのは、統一コードとして何を採用するか? ということになります。候補としては Unicode もしくは iso2022ベースのコードということになるでしょう。(なお、それぞれそのままだとファイル名として安全に利用できない場合があるのでなんらかの規定を行う必要があります)。

で、これをどちらにしたほうが良いのか? ということになると、私は ISO-2022 派なので、そちらベースのがいいなーと言うことになるのでした。ちなみに、この問題はファイル名のみでなく、「ドメイン名の多言語(MultiScript)化」といったことを考えた場合にも全く同じです。

で、locale フレームワークをファイル名に用いることには無理がある → ダメじゃん→ glibc 正しいのかも といった発想は木をみてなんたらですよ。無理があるのはあたりまえです。「キャラクタセットを任意に変更可能なこと」こそが I18N の真髄であり、そのための枠組みなんですから。「C locale はファイル名の指定といった部分には利用できない。そのような用途においては「統一コード」が必要になる」というのは事実でしょうが、これは「C locale においても統一コードをつかうべきである」には決してつながらないのです。 ISO C locale において、「キャラクタセットを変えない」実装は可能なのですが、「変えることができる」実装がある以上、アプリにとっては概念的もなにもありません。「キャラクタセットを仮定することはできない」という明確な事実が存在するだけです。

さてさて、長々と書いてきましたが、全体的には必要なことは次のような点だというのがのが私の意見です。

  1. システム全体の MultiScript 化 (ファイルシステムやコンソールなど)
  2. I18N フレームワーク
    • C Locale システムの実装 (現在の「標準」)
    • その Locale システムへの 「MultiScipt locale」の追加 (システムのコード体系にあわせたもの) 利用の便宜のため。
    • 新しい I18N 用の枠組みの設計

私は、システム低レベルは、今後、MultiScript 化されるべきであろうとは思っています。そのための統一コード体系として、私は iso2022 ベースのものをのぞみますが、Unicode も選択肢にはいってくることでしょう。 iso2022 に統一されていると話は早かったのですが、現状を鑑みると、システム全体の「統一コード」をユーザが選択できるというのもありかもしれません(少しI18N的)。ファイル名などはこのシステムコードでかえってくることになります。カーネル内部からは、ファイルシステムのコード統一のために各種コードコンバータがよばれまくることになります。あ、ユーザランドのために、現在のシステムコードが何に設定されているのかを通知するシステムコールが必要になりますね。ユーザランド側で、locale を利用する場合には、この名前と現locale名とを利用して iconv してからコードをあつかうことになります。

I18N はこのシステムの MultiScript 化とは別の枠組みで提供されるものであることに留意する必要があります。これはプログラム上の技法であり、完全にユーザランドで提供されるものです。私はこのレベルでは「統一コード」を却下します。ただ、既存の「C locale」は、複数の locale を同一プロセスで並列であつかえないため、新しいオブジェクト思考な locale システムを設計すべきだと思っています。追記: 「統一コードの却下」は、「locale システムのベースにそれが存在することを仮定することを却下」で、システム低レベルで採用したそのコードが locale の選択肢にでてくることや、専用のライブラリをつくることを否定するわけではないです。

昨日の話

箇条書きで処理。


1999年2月23日の電波状況

雑記

ううっ(T_T)。早すぎるよ…。谷山舞奈よ永遠なれ。

あ、 その喫茶店です。たのんだのも「ネバーギブアップ」でした。ピッチャーサイズ(^^;

書き忘れてたネタ。その豊橋IRCオフミで、ドメイン名の話してたのですが、猫又さん「senpai.to」を持ってたりするんですよね。「misaki.senpai.to/issyo」とか、バリエーションふくめていろいろ有りです(苦笑) で、そこから「imou.to」ってまだとられてないみたいだよという話に(^^; とるしか > 両兄貴。

locale

結局結論としては同じところにたどりついたようですね。

@ 「キャラクタセット独立」の解釈は、アプリ側はそこまで解釈しないとだめでしょう。実装側がなんらかの形で限定はかかるでしょうね。でも、UCS 統一するとそれ以外無いんです。 (まあ自由領域をつかうという手はあるでしょうが) EUC のように独自定義が許されているものがないといかんでしょう。やっぱ。

@ 私も以前は、「統一 wchar じゃいけないのかしらん」と思っていたのですが、その思考はそのまま unicode の思想であることに気付いたので考え方を変更したのです。統一コード化すると、他のコードの存在があやうくなるのがイヤなのです。今後 UCS/UTF のサポートは必須でしょう。統一コードが UCS だとそちらのサポートは楽になりますが、逆に ISO2022 系がいやんなことになります。逆もまたしかり。あと単純に「私いつもはEUC only で全く問題ないんだけど…」というのもあります。間にテーブルとかが妙にはさまるのは「とても気持悪い」のでした。そうそう、「マルチスクリプトフレームワーク」に依存する locale インスタンスってむしろ少ないと思います。だってほとんどの locale は 1byte のみの処理か EUC で処理できてしまうんですから。最近は EUC は iso2022 にいれずにやっぱ独立させたほうが良いよなと思ってます。

@ それはサテオキ、ひとつ事実の指摘を。 (わかっているんだよな…とは思うのですが一応…) X11R6 I18N Framework は wchar_t の構造はそもそも固定ではなく、その値はやはり locale ごとに違い、ユーザが任意に再設計できるのですが(正しい実装ですね)、これに関連した Generic のなかにある、wc 関連関数は普通よばれることはありません。 OS の wchar_t との統一をはかるために、OS 側の関数群がよばれるようになっています。use_stdc_env が True(デフォルト) のときには、wchar_t 関連は全て一旦 wctomb(3) による変換をほどこしてから処理されるようになり、Xの扱う wchar_t と OS の扱う wchar_t が一致します。 False の場合は、上述の Xlib 内蔵 wchar_t を利用し、wc から直接目的の型 (XCharSet や compound text など)に変換かけます。この場合、当然 OS の wchar_t とは一致しません。

@ X11R6 I18N FlameWork が利用する統一コードは、結局のところ、通信用のマルチバイト・マルチスクリプトコードである、 X Compound Text(XlcNCompoundText)と、それから表示用の内部コード(といっていいのかな…)である、 [XlcCharSet + バイトストリーム](XlcNCharSet)です。前者はおなじみですね。後者はフォントセット情報を保持する構造体 + バイトストリームであり、描画の直前までこれに変換されることはありません。

@ X11R6 I18N FlameWork のコードコンバータは、超汎用で、mb, wc, compound_text, xcharset の全てを一つの関数で全て処理するようになってるのでした。しかも locale から完全に独立して動作します。特定 locale におけるそれらのコンバータをアプリケーション側から任意に登録してつかうことになります。「UCS/UTF 用の新しいコンバータをつくって、それをアプリケーションから登録かけて、UCS/UTF な locale 用の FontSet 表示させる」ということは実は Xlib に手をいれることなく、無改造でさっくりできたりするのでした。 Xlib のバージョンに依存しますけどね。

そうそう、全BSD をまたぐ大きなプロジェクトにするのなら Lemmy's ってつけるのやめません? 理由はなんとなく。

あ、(ML 用の)資源提供してくれるとこ募集。どこかの BSD陣営 に寄生させてもらうというのもまあ良いとおもうんですけど、私としては全てから独立した名前と場所をもちたいです。…うち(DSL) でいいかなぁ。私、いなくなっちゃうから、あまり後に残していきたく無い気はするのでした。dsl.gr.jp のほうで ML サーバをさっさとあがってくれるとそこを間借りするのですが…うーむ。オレドメイン計画はさくさくすすめたほうが良さそうだにゃ。

BSD Locale ML

itojun さんから ML 開設してもいいよのメールが届く。あ、 HauN 方面からも。むむむ、どちらにお願い致しましょう。うーん、nvi-m17n とかそのあたりのシステムとのからみもあったりしそうだし、 itojun さんのほうにお願いしようかと思います。ありがとうございました。

アナウンスの範囲と文面とかはいまから考えて夜か明日ぐらいまでには日記にあげるので、指摘とかあればよろしく。

あ、「BSD 陣営への寄生」ですが、私の場合は、「どこかを選ぶ」のがちょとといやんなのでした。あくまで全BSDを対象にしたいので。

掃除

学校に持ち込んでいる私物を整理してみる。ぐは、車だしてもらわんともってかえれない量だ(爆)。書籍の類が段ボール4箱を越えるというのが大きいな。あとはコンピュータの周辺機器とか。

家まで運びたいので、だれか明日あたり、暇なとき車だしてくらはい(^^; 飯一回おごります > 研究室のめんめん

そらりすちゃん

勝手に設定追加してみるテスト…

ところで、私、 関西の人間ではないです(^^; ちなみに、25〜27 の間東京におります。ばるさんちに宿泊の予定。


1999年2月24日の電波状況

Locale関連

ML を結局どこでたちあげるかは水面下のほうにて。とりあえず、アナウンス案。私の思想が多分にはいっています。コメント求む。

ぐる

アップデート作業、バージョンをごっそりあげるときは、 etc 以下の重要ファイルを適宜待避させておいてから、(なるべくシングルユーザにして)、おもむろにあたらしいバージョンの tar box を xpf で / 以下に全部展開。そのあと etc 以下を変更点とかチェックしつつ再設定かけて、/dev で MEKEDEV して、カーネルはGENERICとりあえずいれて、再起動して、カーネル再構築かけておしまいかな。たまーにデバイス名とかかわったりするので注意。ちなみに OpenBSD です。tar ball による配布ぢゅーよー。全手動インストールは基本(笑) /usr/local 以下とかの、パッケージでいれたり自分でコンパイルしたりした古いコマンドは、特に気にせずつかいます。古いライブラリもそのままおいてありますからめったに問題になることはありません。

@ 一応 ML には登録かけましたが…特にアドバイスすることは無いように思います。私は自分の作りたいものを勝手につくってるだけですし。ああ、「二次創作」モノは本質的に著作権に抵触するものであることには留意してくださいね。うちのマルチはたまたまLeafの方針により安全度が高いだけです。ちなみににたような目的の「BAKA-ML」ってのもあったりするんですよね。最近全然なにも流してないけど(^^;

@ マウンテン、量的には「ナベスパ」とかでないかぎり、まあ、がんばれば、結構いけそうです。多いのはたしかですけど。問題はゲテモノなメニューのほうかと(^^;

@ あう、 メトロポリタンではなかったですか。残念。うーん、わからないですねぇ。「小さな木の実」は音楽の教科書にものってましたね。

Locale Project

曽田さんの意見をとりいれて 細部修正したもの。これで特に意見なければこれをそのままアナウンスとして流します。えーと、流す場所はどこどこがいいですかね。 NetBSD tech-pkg-ja, FreeBSD tech-jp, OpenBSD wakakusa, 他どこか必要なところはありますか? NetNews 方面はどうしましょう。 fj.os.bsd.* か。fj.kanji はちょっと恐い(笑)


1999年2月25日の電波状況

昨日の話

お買い物。プリンタ用の紙類の補充(フォトカラーペーパ、アイロンプリント用紙、転写フィルム) など、ブギ─ポップ「歪曲王」、岩男潤子シングル「空色の風」、それから、「True Love Story 2」(笑)

歪曲王、おもしろいんだけど、なんとなく普通な感じ。

ぐる

はちさんの反応って わかりやすくていいですね(ぉ

@ 好きです (きっぱり)(笑)。みゅ、真の姿が大きいほうですか…通常時はあれで完成形(成長期はそろそろ終わりなので安心。ってなんだ)で、変身後は、魔法の力でむりやり大きくなっているというのは無しでしょうか<ばきぃ

@ 気のせいです

@ しかし、そのプロットだと修一さん、ダメすぎ(笑)。いや、私は、だれも気付いてないんだけど、しっかり修一さんだけ気付いているというかっこいいやつを想定してたんですけど(^^;;

ソラリス:「この2つの通路が中央の部屋に通じているわ。」
修一  :「それじゃ陽子ちゃんは、右の通路のほうから。僕は左からつっこむから」
ソラリス:「わかったわ。気をつけてね。……あれ?」
修一  :「どうしたんだい? 陽子ちゃん?」
ソラリス:「ええーーーーーっ、な、なんで?!」

とか(^^;

@ いまどきの文字あつかうコマンドで 8bit スルー でないもののほうが珍しい気もしないでもない。 fortune の場合、英語の fortune がでてこなくなるってのはそれはそれで困るので、単純な locale による切り替えではダメですね。calendar(1) みたいな処理になるのかな。基本 + αの形。私は標準コマンド群は gettext つかうんでなくて NLS catalog のほうをつかってほしいな。面倒だけど。gettext はあくまでおまけってことで。 gettext は Sun製だとおもってるんですけどどうなんでしょ?

@ toドメインの登録は こちらで可能で、登録に US100ドルでこれに 2年間の管理費がふくまれるようです。それ以降は年間50ドルづつ。日本語のページもちゃっかりあるのはやっぱいいお客さんなんでしょうねぇ。

@ 本日の予定: 関東出撃、のはずだったんだけど、ちょい予定変更で明日以降になりまふ。

@ ホンモノの 志保ちゃん情報っつーとこがミソですね(謎) 私はどこで予約しておこう…。特典はポスターと店オリジナルものってのはわかってるから、特に魅力があるわけではないんだけど、売り切れの事態は避けたいのら。 3/25 って私、既に豊橋にいないから関東方面にうつってから予約したほうがいいんだよなぁ。

とりあえずぷれいしてみる

むぅ、変な子が二人いる(笑)。とりあえず浮気なプレイしてたから以下略らしい。なかなか楽しいです。会話のコツがまだもひとつよくわかんない。

ぐる

kterm の bold font の指定がおかしいといったことはないですか? 通常のフォントより bold font のほうが大きいフォントサイズ指定になっているとそういう現象が発生するはずです。起動時オプションやリソースを確認してみてください。


1999年2月26日の電波状況

locale

アナウンス用最終修正案…になるかな。適宜コメントぷりーず。流す ML 候補、NetBSD-jp とあとのぞみさん経由で linux-tech, debian-tech あたりも追加予定。 (純粋に開発用なので、基本的にユーザーズ ML は避けることにします)

本日の予定

昼ごろ関東出撃。ということで寝にかえる。でも TLS2 一回ぐらいはするかも(ぉ

あ、初音ちゃんを描いてない…時間ないぞ。あと澪もねー、ほんとは 24日イベントだったんだよねー。描きそこねちまったぜい。


1999年2月27日の電波状況

昨日の話

帰ってから下校2回目開始。とりあえず、幼なじみほうめんで進めてみることにする。バス通学にして音楽室を中心にうろうろ。む…なんか気付いてるのかな。ちまちまイベントをこなしつつ、万歳アタックや、自転車アタックや、屋上からの電波をさけつつ←事実誤認、順当にイベントをこなしたりする。…高林、もしかしてそうだったりするのか? 下校中、じーっとみつめて 2回ほどにげられたりしつつ、3回目にして七夕祭りにさそうことに成功 :D 花火をいっしょにみたところまでで、保存して一旦遮断。

@ 目がさめると既に 9:00 をまわっている。むう、寝過ぎた。おきてシャワーをあびて新幹線で東京へ。ばるさんちに到着したのは 2:00 前ごろ。軽くCoCo壱で飯くってから、ばるさんの案内で不動産屋さんへ。

@ 道すがら、なんかいきなり通りに椅子に座ったでかいくまのぬいぐるみがある。おもわず反応してしまうあたり、あかりに毒されているのかもしれない(笑)

@ なかなか安くていい物件は無い模様。とりあえずちょい高いけどけっこう良い場所があるということでみにいったり。そのそばに、なんか、くまのぬいぐるみとかグッズとかがところ狭しとならんだ店があるのを発見。今日はくまとの縁があるようだ(汗)。部屋はきれいで広くていいかんじ。とりあえず保留。

@ ばるさんちに帰ってきてだらだらもってきたブツを PC でしてみたりしてるうちに、けいくん到着。ふふり、昨夜の某IRCでの手はず通り、灰色の箱をもってきている(笑)。ということでこっちに移動してばるさんがプレイ。そうこうしてるうちに Hos さん到着。夕食食いにいったあと、PATLABER劇場版2 を鑑賞。その後けいくんは帰宅。某計画の話をするが、どっちかっつーとダメな会話のが多かった模様。実は食用であかりショックなくま牧場の真実とか、あかりと下校とか(謎)、あかりをうしろからふにふにとか(大謎)

@ ばるさんはプレイ再開。とりあえず浮気モード絶賛発動中らしい(笑) 私はそのうち遮断してた模様。

今日の話

朝。ばるさんのプレイの続き。いつのまにか瑠璃子さん互換(屋上 + 一文字しかあってないってば)一歩リードになっているらしい。で、通常エンドだった模様。あ、 やっぱ一枚おいていったほうがよかった? (笑)。

@ で、その後、不動産屋さんにいって、ちょい高いけど昨日の物件でお願いすることにする。池袋基地誕生らしい(ほとんど大塚だけど)。会社にも浮気部物理部室にも近くてバッチリだ。祭りのときはうちのめんめんの基地になるんだろうにゃ。とりあえず手続きとかの続きは月曜以降電話とFAX にて。ちなみに、会社にはまあ、徒歩でもいけないことはない距離でせう。自転車がまあ、無難なところでしょうか。電車もつかえるのだ。さて、バスはあるんだろうか(^^;

@ で、飯くって、そのまま変える予定だったのですが、某CDが出てることを思い出し、結局秋葉方面にでかける Hos さんとばるさんについていくことに(^^;;

にょにょにょ。バインダーと紙袋の波動にはなんとか耐えて、これだけ買ってから、二人とは別れて帰宅。

@ 新幹線でうつらうつらしつつ豊橋帰還。で帰宅。とりあえず下校続き(爆)。高林はやはりそうなのか。告白イベントに遭遇とか。一回ぐらいデートに誘いたいよなということで最後の日曜に誘ってみる。成功。デパートとプールでなやんだが、買い物にいっしょに行きたいという話を直前にしてたので、デパートにいくことにする。あと寄り道してみたりとかも。デート。欲しいもの…、ダメなのか。ちっ(謎)。くまなのを選ぼうとするあたり、やはり、あかり互換度は高いようだ(笑)。紙飛行機がとてもいいかんじ。ラスト。やっぱ知ってたのね。で、エンディングは True :D 。まだまだ絵は大量にあるようだ。奥が深い。

結論: 幼なじみぢゅーよー

戦闘もーどにょ〜♪

絶賛 BGM 中。

ぐる

HTML での声の指定については、CSS2 で、 Aural Style Sheetsという規定があったりします。もっとも、対応してるブラウザがあるのかどうかは知りませんが…。「声優の指定」は voice-family による指定ということになるんじゃないですかね。一応(笑)

@ えと、 「吉」ですが、 JIS X 0208 の 21区40点、GB の 28区10位、CNS の第一字面 474F、 BIG5 の A64E、UCS-2 の 5459 にあります。で、上が短い「吉」は、GB では 21区56位、CNS では第六字面 2428 にあります。JIS X 0208 ではこの2つの形状は「同じ文字」ということになってます。 UCS でも同様のようですね。 iso-2022-jp2(RFC1554) なら GB が利用できますから、区別することが可能ということになります。

@ ぐは、訂正(2/28)。上が短い方、GB は GB でも、GB 2312-80 ではなくて、 GB 7589-87(GB4) または GB/T 13131-91 の 21区56位、ということで、 iso-2022-jp-2 ではあつかえません。 ISO-2022-CN(RFC1922) を使う必要があります…って、なんか RFC みると終端文字が登録されてないから登録されたらそれつかうとか記述が(汗)。あうあう。えーと、えーと、台湾の CNS 11643-1986-6 のほうは登録されてるみたい(94x94の'L')なので、ISO-2022-CN-EXT(同RFC1922) から、もしくは EUC-TW からなら使えるようです。

ちなみに、安岡さんの 漢字袋 で検索しました。


1999年2月28日の電波状況

あかりママ

ぐはっ。 あかりママがでるのか(笑)>PS東鳩。とりあえず本を買いにいくのは明日にして、とあるルートで記事の映像を入手。おお、 わたしのでっちあげたママ(古い絵なのですごく下手だにゃ…) とかなりイメージ近いやん(苦笑)。前々回のコミケにて、 「あかりママ」のTシャツをつくって売った人ってのは、日本広しといえどたぶんさすがに私だけだと思うけど、先見の明があったってことだにゃ。わはははは。

私服のマルチと葵ちゃんかわいいのら。体操服あかりとそのおとなりにいる目鏡っ娘もチェックポイントだにゃ。

さてと、PS東鳩を買う理由がまた増えたっすね(^^;;

「きち」の話

あうあう、 昨日書いた話、まちがってました。上が短い方、GB は GB でも、GB 2312-80 ではなくて、 GB 7589-87(GB4) または GB/T 13131-91 の 21区56位、ということで、 ISO-2022-JP-2 ではあつかえません。 ISO-2022-CN(RFC1922) を使う必要があります…って、なんか RFC 良くみると終端文字が登録されてないから登録されてからつかうとか記述が(汗)。今現在、登録されてるのか? あうあう。えーと、えーと、台湾の CNS 11643-1986-6 のほうは登録されてるみたい(94x94の'L')なので、 ISO-2022-CN-EXT(同RFC1922) から使える模様。mule(19.28ベース) 内蔵のエンコーディング指定には無いようですが、うまいこと定義すればつかえるんじゃないかと思います。たぶん。あ、あと、EUC-TW でも使えますね > CNS の 6面。

汎コードコンバータ、lv には iso-2022-cn はありますね。 iso-2022-cn-ext はダメな模様。

Mule な環境な人ならさくっと使えるっしょ → GB。 Meadow あるから Win でも OK。あ、この場合、UTF はダメですよ。目的の文字は UCS にも無いんですから。

昨日はなんの日?

結局過ぎてしまったのら。一日おくれだけど一応(^^;;


「初音ちゃん、今日誕生日だったよね? おめでとう」

ありがとう耕一おにいちゃん(^^)

「プレゼントがわりといっちゃなんだけど、今日デートしようか?」

ええっ(=^^=)

「だめかな?」

ううん。すごくうれしいよ。耕一お兄ちゃん!

「じゃあ決まりだね。うーん、それじゃ、気分を出して、午後から外でまちあわせにしようか :D」


でもって、仕上げてる気力なかったので、らくがきなのね。

あ、おくればせながら、みみなさん、 お誕生日おめでとうございます(^^)

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