とっぷぺーじ
ねこめしにっき
2003/03/中旬
2003/04/上旬
ノドの奥にできやがった喉頭蓋嚢胞とかいう物体の除去手術はとりあえず回避されますた。異物感とか食い物を飲み込むときの引っかかり感がいつのまにか和らいできてて、実際鼻からファイバー突っ込んで見てみたところ縮小してるらすぃし、悪性の物体でもないらすぃので。
手術は怖いっつーより、いや全身麻酔しなきゃいかん手術らしかったからたぶん怖くないんだろけど（笑）、なにもやることがない入院生活のほうがとっても怖かったというー。たとえ 3 日程度の入院だとしても。ネットできんのはキツー。
さとみかんはアクセスログというかアクセス統計をまるで取ってないので、言及リンク等されててもそのリファラには気づけませんのでヨロシクです。もちろん najo サーバの Apache は access_log をせっせと貯め込んでるけども、それは najo のいちユーザであるぼくが見て使うものじゃないってなワケでして。そういうことです。
これもさとみかん総合インフォメに書いておかなきゃだなぁー。
ちらちら徘徊していたら、更新情報を正しく取得する云々の話がありましたので、「正しい更新日時を拾わせるためには」を読み返して、ちょっとやってみようと思いました。
（略）データの取得結果を一番判りやすくするために、過去の日時を入れるので、そのうちさとみかんのリストの最下層にうちの日記がぶっ飛ぶと思います。 ぶっ飛んでたら成功ということで。
[ 更新取得方法 - おかし日記 より ]
いったん正常に更新日時を取得できたサイトは、次回以降のチェック時に、それよりも過去の日付とかのおかしな日時が返って来る場合、最後に正常取得できた日時がずっと使われます。（前回のチェック結果がファイルにキャッシュされてる）
ゆえにキャッシュファイル (hogehoge.lirs / さとみかんにおけるキャッシュファイル名は大人の事情によりヒミツです（笑）) をアンテナ管理者が手動で消さないかぎり、リストの最下層に
ぶっ飛ぶ
ことは無いはずです。たぶん。
今までやってたことで多少の推測ですが、実データ取得から取り出した時間と、ヘッダに書かれている時間とは基本的にGMTとJSTとの違いがあるので、今まで実データから更新情報を取っていたものをヘッダ出力させた場合に更新が取得されていない所を見ると、「時間の比較処理」が「時間方式の統一処理」以前に働いている様な気がしました、順番としては単位を合わせてから比較を動かすのがいいのかなと思います、なつみかんの仕様なのかな・・。
[ 更新取得方法その４ - おかし日記 より ]
えっと、なつみかんは Perl なんで必然的に（？）ソース大公開中なわけで、そういったブラックボックステストをしなくても、ソースをおっかければ実際のトコロがわかったりしませんか？いやぼくもちゃんと追っかけた事は無いんだけども（笑）。
このあたりかなぁ。（あてずっぽ）
ほとんど決定してたよーなモノだったはずの東京での就職話（と引っ越し＆一人暮らし化）が、大人の事情によりコツゼンと消えちまいまちた。悔しいようなホッとするような、複雑なきぶんきぶん…。
そしてせまりくるノドの手術。あーだこーだやってるうちにじき 31 歳になっちゃう。鬱だ…。
「Java ウプデータンにしてやられた (4)」の続き。 OSX に Java1.4.1 ウプデータンを入れたら Xalan-Java が動かなくなっちゃったの件、完結編。わらい。
Library/Java/Extensionsに放り込んでみたりCLASSPATHを設定したり色んな事を試した後にドキュメントを読むとXalanのFAQにJDK1.4ではまともに動かんとあっさり書いてあるし。初心者程FAQは読まないの典型だ。
やっぱり古いXalanのせいらしい。どうすればまともに動くかと言うと、一番簡単なのはjavaコマンドのオプション、-Xbootclasspath/p:（コロンで区切ったjarへのパス）を使う方法。これで無事Mac OS X 10.2+JRE/JDK1.4.1でXalan-Java2.5が動いた。
[ sonorous howl, terrestrial rhapsody より ]
前見たときはその FAQ はまだ無かった気がするのだけど、見落としてただけなんかなチクショー。
- For the SUN JDK 1.4, use the Endorsed Standards Override Mechanism. Place the xalan.jar, xercesImpl.jar, and xml-apis.jar in the <java-home>\lib\endorsed directory, where <java-home> is where the runtime software is installed.
とのことで、コマンドラインオプションで jar のパスを指定する泥臭い方法もいいけど、 <java-home>/lib/endorsed ディレクトリに必要な jar を置いてみる方法も試してみた。MacOSX の場合は、<java-home> は端的にいえば /Library/Java/Home 。でもこれはシンボリックリンクのシンボリックリンクのシンボリックリンクで（謎）、 <java-home>/lib/endorsed の実体は (Java1.4.1 ウプデータン後の現在は) 以下の場所。
% cd /Library/Java/Home/lib/endorsed ; pwd /System/Library/Frameworks/JavaVM.framework/Versions/1.4.1/Home/lib/endorsed
ここへ、お決まりの xalan.jar, xercesImpl.jar, xml-apis.jar と、ぼくが使ってる拡張機能用の bsf.jar, js.jar をコピー。 そしたらヤットコ動いたです。ハァハァ…。
/System 以下の場所は sudo しないとモノを置けないから、というか OSX の流儀的には手動で /System 以下をいぢるのはあんましすべきでない事だし、たいがいの場面はしなくても済むように出来ているのだけど…仕方ないなぁーもー。なんとかしてよアポー。
- The following methods do not work:
- Using the CLASSPATH environment variable or using -classpath to place the new classes in the classpath.
とか堂々と書いてあるしー。CLASSPATH でいくら jar のありかを指定してもムダ、 CLASSPATH に置くべき jar の何が足りないのかを苦悩した事自体がムダだったと。んだよまったく…。ともかく ecco さんに多謝なのですー。てなわけで OS X 10.2.4 + JRE/JDK 1.4.1 + Xalan-Java 2.5D1 で初更新。
「Java ウプデータンにしてやられた (3)」の続き。 OSX に Java1.4.1 ウプデータンを入れたら Xalan-Java が動かなくなっちゃったの件。
そう言えばJava 2 SDK 1.4.1ってJAXP標準搭載じゃなかったっけ？ と思い、1.3と1.4のドキュメントと見比べてみたらやっぱり含まれていた。ひょっとして1.4.1になってXalanが動かなくなったのってこれと関係しているのだろうか？
取り敢えず検索してJavaを紐解くための重点キーワード : JAXPを見つけた。でもXalanの事始めチュートリアルにはパスに含めるだけって書いてあるから、JAXPからXalanを使うのでなければ関係ないんじゃないかと思うんだけど……あれ？ JRE1.2〜1.4の場合はtools.jarを含めろとか書いてあるのは一体何なのだろうか？ 1.3.1の時はそんな事しなくても動いたらしいのに。
[ sonorous howl, terrestrial rhapsody より ]
以下の部分ですよね。
If you are using JDK or JRE 1.2.2, 1.3.x or 1.4.x, include tools.jar on the classpath.
これ、動かなくなってから読み直して初めてこう書いてあるのに気が付いて（笑）、気になってたんですが、 tools.jar ってのがナニモノなのか、とゆーか、どこにあるのかも何に含まれてるのかも思いっきり不明でして、ンな事言われてもどうしようも無ぇよ、って無視したという。
しかし、1.4.1 ウプデータンを入れつつも結局 1.3.1 のほうを使うようにしている現在でも、 tools.jar とやらを CLASSPATH に含める事無く Xalan は動作してるです。ていうか動作してくれなきゃ更新ができないー。
… Java ワケワカリマセン。泣き。
「Java ウプデータンにしてやられた (5)」に続く。
「なんで OSX には時報機能が無いんだっ (1)」のつづき。時報を鳴らすだけの、 GUI で簡単に設定できる、他にムダな機能は一切無い質実剛健ナイスアイテム登場ー。なんか誤解を生みそうな言い回しだけど、まさしく欲しかったモノ。
[ Rj's SkaaRj Page_134 経由 ]
Cocoaがわからない私には「システム環境設定」用のモノは作れませぬゆえ、Carbon(Mach-O)でアプリケーション形式にて
、との事ですけど、たしかに prefPane 形式だともうカンペキラブラブチューなんですが（笑）それはそれとして。起動時にホットキーを押しとくことで設定ダイアログを出せるとか、そこに Quit ボタンもあるとか、だといいなぁ…。いいなぁ…。
あ。もしかしてPuTTYに文字列をペーストする方法ってあるのかな...。
[ リンクとか備忘録とか日記とか より ]
とりあえず右クリックでペーストされないですか？
[ Hatena::agenda 経由 ]
ウチのサイトのデフォルトスタイルの配色は、上記の No.21 の組み合わせに近いわけですが。うーん。いや、このスタイルを作った当初の文字色は、もっと彩度も明度も高い「完全な赤」だっだけど、自分でさえ目にキツかったもんだから、ちょっとずつ明度も彩度も下げていって、今に至っているという。でも読みづらい配色には違いないんだよなぁ…。
あ、単なるキチガイ配色を除いたよく見かける配色で、ぼくの目にいちばん苦手なのは No.15 。黒地に白文字。かなり苦手。読めないとかでは無いんだけど、アタマがクラクラしてくる。なんでだろ。てゆか黒地に白文字って、それこそベーマガがブイブイ言わせていた頃の、コンピタ原始時代を思い起こさせるのよねん。思わず cload して run とか打ちたくなっちゃうとゆーか。当時はそれがフツーで、黒地に白文字の画面を見続けててもクラクラしなかったのに。
んで、大学生になって X Window System なウニマシンを使わせてもらえるよーになったり、印刷屋や Kinko's でマクをいぢるようになったりした頃、「おお、現代のコンピュータというものはこんなに高解像度で、しかも画面全体が明るい色で覆われてても平気なんだ！」とか妙な感動を覚えたわけで、「これよりも昔にはもう戻りたくないなー」とか、わけのわからん感情がそこで生まれたとかいう説も。
逆に Windows 以前を知らないワカモノにとっては、黒地に白背景で、しかも等幅フォントなんか使っちゃうと、なんだかサイバーな雰囲気がしてカッコイイんだろうなぁー。とか妄想する日々。
[ Mapleholic 経由 ]
思えば小学校の頃、本屋で立ち読みしたすがやみつるのマイコン入門が始まりだった。自分でゲームが作れるというのを知って驚き、付録の PC−6001 のキーボード実寸写真でタイピングの練習をしたり、近所の電気やさんの X1 に掲載プログラムを打ち込んだりして心躍らせたり。そのあとの誕生日に PC-6001mkII を買ってもらい、最初に買ったパソコン雑誌がベーマガだった。そして毎月毎月、BASIC プログラムを打ち込んだり自分でも書いてみたりして遊ぶようになったわけで。数学の授業で習うより先に変数という概念を知ってたりして。
今考えてみれば何やってんだって感じだけど、たかがペンゴのパクリゲームをプレイするためだけに、カセットテープのプログラムロードの 10 分間をボーっと待ちわびたりしてた。当時はもうファミコンとかあったから、ウチに遊びに来た友達から、なんでゲームをするのに 10 分も待つんだ？とか言われるのが辛かったんだよね。なにせ 600 ボーだから。子供ながらに「データレコーダーは ROM カセットと違って書き換えができるから経済的なんだ!」と思ったね。
アレゲだ…。っていうかただの懐古趣味ジジィだ…。自分キモー。
ヒカルの碁も最終回だったとわ！！ノーマークだったっ！
いろんな使い捨ての萌えアニメが乱造されてる昨今の地上波 TV アニメシーンだけど、この一年半、毎週いちばん楽しみにしてたのは、まごうことなくヒカ碁だったりしてた。絵的な動きが地味地味になるハズの碁を、ていうか盤面の展開を分かる人のほうが珍しいハズの碁を、映像と音楽とタイミング運びの妙によってあそこまでドキドキできるモノへ描いた、あの演出や構成の圧倒的な力は、最近ほとんどお目に掛かったことが無かっただけに。
あ、原作は床屋に置いてあったジャンプで一・二度読んだ程度。モトモトからすげぇしっかりした作品であるってのはいろんな人から聞いてるけど、それはそれとして。絵が動いて音も出て、時間の流れが受け手全員にとって一定であるアニメは、まんが用の演出構成技法をそのまんま引き写しただけじゃだめなワケで、ヒカ碁スタッフはそのへんをよく知ってた。しかも最強レベルに。
それなのにー。それなのにー。後番組は何も特筆すべき物の無い NARUTO の放映枠移動ですか。トホホ。こっちは秋の放映開始からとりあえず1ヶ月吟味した結果、既に見限ってある。
原作で続きを見たいトコロなんだけど、元来マンガよりもアニメのほうが（表現様式として）好きなぼく的には、あそこまでのカタルシス感を得られるかビミョー。
（RSS の）ItemタイトルやDescriptionはサイト作成者が恣意的に作る。それが手動作成であれ自動作成であれ。ということは、内容の要約が妥当である必要がある。そうでなければ、仮に閲覧者の見たいものとサイト作成者の本文の内容が合致しても見に行かないという不運が発生する。
- ねこめしにっき：title、descriptionの分量、各itemの日時すべて判りやすいお手本のような表示。
[ 適宜覚書 より ]
ウチの場合は、 item 要素の個数は 15 個、title 要素の内容は 100 バイト以内、description 要素は 500 バイト以内になるようにしてるです。
簡単なRDF Site Summary (RSS)の説明
に書かれてる、RSS 0.9との互換性のため
の推奨値に何となく従ってみてる。
RSS 1.0ではitem要素の数は1つ以上で上限はありませんが、RSS 0.9との互換性のために15までにしておくことが推奨されています。文字数に関する推奨も、後方互換性のためです（これらの制約は近い将来取り除かれる方向で検討されており、あまり気にする必要はありません）。
[ 簡単なRDF Site Summary (RSS)の説明 より ]
しかし、規定値からハミ出た部分を機械的に切り落として捨ててるだけだったりしてるので、要約としての妥当性はイマイチ。
この方式を採ってる以上、日常のにっき書きの際はいつも、何についての話を今からするのかという要点をまず即座に書くのを意識してないといけなくなる。というか、そう意識することでにっきがいくぶん読みやすく（読み飛ばしをしやすく）なるという好影響もあったりするやも。…あるといいな…と淡く期待。
OSX にはシステムに自然語要約エンジンというか、要約サービスがあったりする (/System/Library/Services/SummaryService.service) ので、それをどうにか利用する方法もありカモ。あでも問題は要約の精度かなー。試しにこのにっき項目のこの段落までの部分を、150 文字程度へ要約させてみた結果を以下に。
RSS の description の要約の妥当性（RSS の）ItemタイトルやDescriptionはサイト作成者が恣意的に作る。... ウチの場合は、 item 要素の個数は 15 個、title 要素の内容は 100 バイト以内、description 要素は 500 バイト以内になるようにしてるです。
うーむ。今回の場合はなかなかの精度。やるなぁ。ただ、要約サイズはおおざっぱにしか変化しなくて、希望の文字数キッカリに納まるようにはできないから、そこは何とかすると。問題は、処理の自動化のために AppleScript 他の手段で要約サービスへ要約作業を依頼する方法だなぁ。うぐぅ。
ところでさとみかんを運営されている『ありみかさとみ』さんは姫ちゃんのリボンのエリカ様絵描きとしてで有名です。せっかくなんでエリカ様を描いてみようかと（以下略）
[ 歯車館 talk より ]
うおー萌える！！！！さっそく保存しますた。ニヤリッ。あ、ぼくが描くエリカ様の衣装は、原作版とアニメ版のチャンポンっぽい感じだったりして、あんまし参考にならんと思うです。ちうか服描くのが相変わらず苦手だったりもしてるし…。
…ちうか、エリカ様絵描きとしてで有名
って、そうなのかなぁ。このサイトの展示イラストに多いからそういう印象なのかな。エリカ様エリカ様とずっと言ってきてるワリに、姫ちゃんの同人誌は一度も出したことがないという、姫ちゃん好きな人からしたら裏切り者状態だったりしてるけど…。これが同人活動における最大の心残り。
逆にセイントテールの頃が同人活動も同人誌の発行部数も（たぶん）知名度も最盛期だったりしたわけで、セイントテール好き系作家としてもう少し認識されてても良いはずなんだけど、サイトに絵が一枚も無いからか、そーゆー認識はほとんどされてなかったりとか。なんだかなぁ。
ところで見出しやナビリンクの年数が 2002 年になってるようなので、一応お知らせしときます。
近頃話題になってるらしいt.A.T.u.（タトゥー）。なんでもプロモがやばいらしい。（略）
このビデオに対して、英国のＢＢＣは「少女好きの中年男性をターゲットにしたもの」だとして、放映を見合わせる方針を示したとかいう話ですがイギリスのロリ好きさんたちはあーゆーのが好みですか。そもそも高校生ってのはロリ好きさん的にはストライクゾーン外なのではないのですか。よく知らんけど。
[ corkboard 芝居にまつわるエトセトラ より ]
うーん。日本人男子の目には、欧米人女子って年齢よりトシ喰ってるように見えるんスよねぇ。逆に言うと、欧米人男子から見た日本人女子は、たとえ成人でも幼く見えるらしく。欧米人向けの海外アダルトサイトの Asian カテゴリっつーのは、そういうロリな嗜好の欧米人男子を満たすためにあるんじゃないか？と日頃から。
んで、 t.A.T.u. の彼女らにしても、ぼくの目には完成された成人女子にしか見えないわけでー。これはロリだって言い切られると全力で否定しときたい次第ー。だっておっぱいもフトモモも毛も完成されとるやんか。そんなもんはロリータ少女じゃないだろがっっっっ。
そういえば、どこぞのチャイルドポルノ撲滅推進な国際団体が日本を視察した際、いわゆるブルセラなアダルト雑誌をコンビニでめざとく見つけ、「ニ、ニ、ニホンではチャイルドポルノが街角で公然と売られてるのかッッッ！！」と驚愕したとか何とか、という話を小耳に挟んだ事が。でもあれですやね。ブルセラ雑誌って結局、年齢をサバ読んだ成人女性にセーラー服とか体操服着せてる事も多いわけで。でもくだんの外国人には文字通りのチャイルドポルノに見えたんだろな。わらい。それも関係したのか知らないけどともかく、 18 歳以下はみな児童、つまり分別も判断力も自己決定権も何もない無知で無垢なる子供、ゆえに神聖不可侵、とかいうわけのわからん定義の法律が成立してたりすると。
ともかく、海外ドラマとか観た感触によると、欧米では中高生年齢をセクシャルな嗜好の対象にすることへのタブー感の強さは、女子中高生がオヤジ雑誌の巻頭グラビアでフツーに水着姿を晒してるここ日本とは比較にならんらしーと思ったり。つまり女子高生である t.A.T.u. が、音楽性よりも文字通りの性的イロモノなパフォーマンスをウリにしてる事とか、それに欲情すること自体がアッチの世界では猛烈なタブー破りなんだろな、とか。
スパイラルおしまい。煮え切らねーストーリー展開のまま煮え切らねー終わり方。
ちうかこの作品のキモはやっぱ、メンタルがヨワヨワで自分に自信を持てず、それを隠すためにニヒリストを装って、その場を取り繕うためのリクツコネコネだけは余念が無いという、どうしようもなく女の腐ったようなダメ男子を、優しく見守り励ますお姉さんキャラですやね。
こーゆーお姉さん系女子は、時にダメ男子を焚きつけたりもするけど、実際、イマドキ女子はイマドキ男子よりメンタルが強靱なわけで、焚きつけが強すぎる時もあったりして、ダメ男子は発憤するどころか、逆に再起不能になったりするのが定番パターンなわけで。
ダメ男子への期待を抱きつつ、しかしそこまで強烈な焚きつけはせず、いつまでも信じて待ち、包み込もうとするお姉さん・ひよのちんが萌え萌えだと思った。ダメ男子にはあまりにも都合よすぎるお姉さんだから萌え萌えに感じるのか。こーゆー都合のいい優しいお姉さんが欲しかったと常々思っているダメ長男なぼくでして。なさけねー話ですな。
相変わらず Camino には、フォームへの日本語入力中の delete キー押下時に、不意にひとつ前のページへ移動する事があるとゆーウザいバグが健在なわけですが。あまりにウザいってんで、ここ日本では delete キーでページをひとつ戻る機能自体を抹殺するのが流行中。
Apple Mac OS X専用Webブラウザ Camino™ trunkバージョンを Mac OS X 10.2.4上でbuildした物です。フォームでの日本語入力中、Deleteキー押下でバック(前ページに戻る)する不具合を暫定的に対処しています。つまり最新 Nightly ベースの改造版。
よっし氏の0.7日本語版に加え、nightlyを上げてくれる人も現れたんでこちらは改造版にしました。ダウンロードウィンドウの項目が自動的に消えるのと、環境設定にimageを復活させる改造を行っています。つまりこっちは Camino 0.7 リリース版ベースの改造版。
[ CocoaなMozilla「chimera」改め「Camino」! 9th 経由 ]
ape モジュールによる delete-back 殺しがお手軽だろうけども、なにせオフィシャルの Nightly は自動ビルドが連日失敗してるっぽいとゆー。上記の Nightly ベースの改造版は 20030323 ベースなのだけど、公式の Nightly で最後に自動ビルド成功してたっぽいのは 20030320 というー。 Gecko1.4a ベースへの移行で苦悶してる現行の Nightly を使うなら、不具合が毎日どんどん潰されてるゆえに常に最新版を使いたいトコロ。
なんか DTI 内部のネトワク経路が不調くさい。どこのサイトを見るにも応答が返ってくるのがひたすら遅いとゆーか、自分のサイトや DTI 自身のトップページでさえ応答がすげぇ鈍いー。 HTTP だけでなくて FTP や POP や SMTP に NNTP 、ともかく全部が鈍いー。つまりネトワクインフラそのものが不調くさ。
フレッツ ADSL はサービスが始まってすぐの頃の加入だったワケで、 DTI はその頃まだ使えなく、とりあえず WAKWAK に加入したとゆー経緯で、実は WAKWAK のアカウントも持ってたり。そっちで繋げてみると、どこもかしこもスパスパ応答してドバドバとページが表示されるという。もち自分のサイトも DTI のトップページも。WAKWAK で繋げても DNS は DTI の物を使う設定のままだから（笑）、DTI の DNS 鯖がトロくなってるんでも無いかんじ。
www.remus.dti.ne.jp に向かって traceroute してみると、たしかに DTI ネトワク内で多少の引っかかりはあるっぽい感じではあるけど、めちゃくちゃヒドイってわけでもなく。ナニコレ。ちうか DTI よ、品質をウリにしてたのはもうはるか昔の話デスカ。トホホ。
2003/03/16 付にっき「Xalan-Java の Out of Memory 問題 (1)」の続き。 XSLT 変換において、 document() 関数が何度も使われちゃうような時に、 Xalan-Java が Out of Memory 例外を出して変換処理が止まっちゃう事が時々あるの件について、メールで KOSUGI Tomo さんからご助言をいただいたのですー。
Sun の JVM 実装をお使いでしたら，ヒープサイズを変更するためのオプションがあります．
$ java -X | grep 'heap size' -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap sizeなので，例えば 100MB に増やしたい場合は
$ java -Xmx100m org.apache.xalan.xslt.Process ...などと指定すると幸せになれるかもしれません．
今回は
document()関数が XML 文書をメモリに溜めまくるのが問題のようなので，ヒープサイズを大きく取れば落ちなくなる可能性が高いと思います (断定はできませんが)．
なるほど！そういう設定ができるのであれば、メモリが溢れて止まることはとりあえず防げるわけですね。今現在、過去にっき一覧ページあたりがすでに Out Of Memory 例外で止まりやすい状況となってるのですがー、上記のようにとりあえず 100MB くれてやったら止まらなくなりました。感謝感謝。
しかしなー、こう湯水のようにメモリ使われるとキツイなぁ。 OSX システム自体の仮想メモリのページインアウトで虹色円盤グルグルモードに入りやすくなっちゃうんだろし。…ならないのかな？よくわかりません。
（略）Mac使いのデザイナーさんは、ファイルをStuffIT Expanderで圧縮して送ってくれるのだった。んでこっちはWindowsなのでAladdin Expanderで解凍する訳なんだけど、どういう訳だかこれがうまく解凍できないの。（略）StuffIT自体よく知らないんだけど、MacLHAで言うところのMacバイナリオプションがくっついたりしてるんだろうか。バイナリエディタで見ても特に変な128バイトが頭にくっついてるようにも見えないんだけどな。
[ 不浄に日記 より ]
StuffIt7 から導入された新形式 sitx かな？とかチラリと思ったんだけど、それなら拡張子もフツーは .sitx が付くだろから、違うかなあと。あ、それか、受け取ったファイルが StuffIt5 の時に導入された SIT5 圧縮だったりしてて、お使いの Aladdin Expander
(Windows 版 StuffIt Expander) がそれに対応してない？…とも思ったけど対応してる
って書いてあるし。うーん。謎。
あ、圧縮された元ファイルのファイル名が日本語含みだとダメとか、あったりするのかな。知らないけど。
StuffIt 圧縮はそれ自体、Mac ファイル特有の部分 (ファイルタイプ・クリエータコード等のFinder 情報やリソースフォーク) を保持したまま圧縮できるモノです。純粋な sit ファイルはリソースフォーク長がゼロ、圧縮データはすべてデータフォークへ格納されます。よって、 sit ファイルのバイナリデータにはいわゆる「マックバイナリの 128 バイト」は無いハズ。
ただ sit 圧縮ファイル自身は、 Mac 上で Mac の流儀に従って華麗に扱われる様にと、ファイルタイプ・クリエータコード他のフラグが付加された状態で通常は出てきます。その sit ファイルを Mac 以外の環境へ持っていく際、 sit ファイル自身が持つその「Mac ファイル特有部分」をさらに保持しようとするならば、 MacBinary エンコードや BinHex エンコードが必要になる、という次第です。そゆのは通常 .sit.bin とか .sit.hqx とかの拡張子が付けられます。
たまに、正体が .sit.bin や .sit.hqx なのに拡張子が .sit とだけなってたりする事も（StuffIt アーカイバの設定もしくはユーザの好み等の理由で）ありますがー、その場合バイナリエディタで見れば変な128バイトが頭にくっついてる
とか、 BinHex のヘッダが付いてたりするのですぐ分かるかと。
というか、 .sit.bin や .sit.hqx のファイルも、拡張子が何であれ、 Aladdin Expander は自動的に認識して適切な処理をするハズだと思うんですがが…。
あ、蛇足っておきますると、StuffIt Expander は StuffIt 圧縮ファイルを手軽に解凍するだけの解凍専門アプリの名前なのでして、StuffIT Expanderで圧縮
ちう言い回しはビミョにハズレです。
ねこめしにっきヘッドライン
Mail to Alimika Satomi
Site search
About copyrights