2001年03月30日(金) << 前の日記 | 次の日記 >>
これまでの03月30日 編集

■1 逆リンクにGo![http://www.1783.org/diary/?200103c&to=200103302#200103302][hns]次の記事 >> このエントリーをはてなブックマークに追加

導入ありがとうございます。
現在の課題は,同じ個所からのリンクでも読者によってURIがまちまちなので, なると(@)がたくさん表示されることです。
この問題は,帰ってきた「新リンク方式」が実現されたときに解決される予定です。

新リンク方式:

解決しようとする問題は,
  1. Refererでは同じ個所からのリンクが様々な形式で表示されるため未読を探しにくい(識別したい)
  2. 逆リンクを張られた時にどのセクションから張られたのか分からない(リンク元を知りたい)
このために,refテクノロジでは,
  1. 相手方にリンクを張るときに'ref=識別子'の形式によって,こちらのセクション情報を引き渡す
  2. 上記1の'ref=識別子'形式を理解できる日記は,自分自身のセクション(or段落)リンクに,'ref=here'なるキーワードを含める
  3. 'ref=識別子'を生成できる日記では,LINKを張るときに,'ref=here'を'ref=識別子'に置換する
ということを行います。
問題になるのは識別子の決め方です。問題(1)を解決するためには, 識別子は一意であれば何でも構いません。 (2)を解決するためには,refテクノロジを導入する日記間での合意が必要になると思われます。
考えられる識別子として,
  1. hnsでいうところの#nameの内容を使う(hnsではこれは一意になります)。'http://日記パス/?識別子#識別子'でアクセスできることを保証する
  2. URIフルパス表記とする
(2)のフルパスをRefererの情報で補完することによって圧縮する案は,本質的には(2)と等価でしょう。
(1)を採用した場合,例えばhnsでは'http://日記URL/?引数#name'の引数として'200103301S1'等が 受け取れるように改造する必要があります。 また,静的に'200103.html'等を生成している日記では対応が困難だと思われます。
(2)のフルパス表記及びその応用では,恐らくURLエンコーディングをしないといけないので, 生成側・逆リンク解析側ともに負担が増えますし,引数が長くなるのがちょっとイヤです *1 。 引数を縮める方法としては,Refererの最後のスラッシュ以下をエンコーディングするのが有効だと思われます。 例えば,'ref=?20010330#20010330S1'あるいは'ref=200103.html#20010330'(共に実際に引き渡すときはエンコーディングの必要がある)となります。

結局:

'here=ref'を埋め込んだ人は, 自分がどのセクションからリンクされたか知りたい[http://club.h14m.org/kenji/diary/?200103c&to=200103303#200103303] 人なので,置換された後のref=識別子が分かりにくくても長くても,それがあなたの望んだものだから,URIを丸ごとエンコーディングして渡すのが良いような気がしてきました。 また,中途半端に圧縮すると互換性の問題を生じる恐れがあります。
上の記事から辿れる リンク補足機能[http://www.etl.go.jp/~kfujiwar/message/messagehelp.html#link3] もURI丸ごとエンコーディング方式ですし,hnsのlink_logの実装もそれを期待している様です。

refテクノロジ対応日記システムの分類:

こちらにもメモを残します。
  • A. LINKにref=hereを見つけると、そのセクションの一意な識別子を返す
  • B. Aの識別子からその記事のURIが特定できる
  • C. 「ref=識別子」を食べても大丈夫
  • D. 「ref=識別子」を利用した逆リンク解析ができる
  • E. 自分向けリンクに「ref=here」が埋め込まれている
A,Bは、相手の日記に分析結果を提供するための機能。 C,D,Eは、自分が分析をするために必要な機能です。 Eを満たしているものは、C,Dは満たしている筈(ということを期待している)。
Aを満たすけれども、Bを満たさないシステムはあるかも知れない。 C,D,Eを満たすけれども、Aを満たさない残念なシステムもあるかも知れない。 A,Bを満たすけれど、C,D,Eには興味が無いシステムもあるかも知れない。

ref引数を圧縮するなら:

HTTP_REFERERからの相対パス表記を*can*にすれば良いですが、 実際にはこれを保証するのは難しいかも知れない。
ref引数の置換を行う場合、日記に記述したリンクの'ref=here'を、 'ref=識別子'に置換します。
識別子は日記内でユニークでなければなりません。 識別子によってリンク元を明示したい場合、識別子はURIである必要があります。 識別子をURIとする場合、URIは絶対パスあるいは考えられるHTTP_REFERERからの相対パスによって表現することができます。
*1: 圧縮すれば短くはなりますが,見た目として美しくないという問題は残ります。 'ref=%3f20010330%2320010330S1'等。

■ 関連記事

■2ぐるぐるします[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

今日は 日記バード[http://www.nantoka.com/~kei/nb/] からのスタートです。

n年日記[http://www.yomogi.sakura.ne.jp/~hiro/diary/?200103c&to=200103291#200103291]:

n年続けようという意欲のためのデフォルト表示ということで。

Sound Engineeringのページ[http://ottotto.com/sound/index.html]:

ねぎ式[http://clotho.KU3G.org/diary/?20010329#200103291] より。
その昔,放送部あたりで活動してた頃を思い出すけれども,はるかにハイレベル。

あなたの超能力測定します[http://members.tripod.co.jp/shakasenz/esp/esp_top.htm]:

INTERNET Watch[http://www.watch.impress.co.jp/internet/www/wtoday/index.htm] より。
透視能力も予知能力もなかったけれど,石を割るのには成功したらしい。

ProjectX 〜 KAMEプロジェクト[http://homepage1.nifty.com/susho/diary/2001/03.html#30]:

必見ですね。

東京ペンクラブ メイド研究会[http://www.geocities.co.jp/WallStreet-Stock/3500/]:

いや、chmoe o+maidとかのビットはたっていないんですが、これはすごいと思ったです。
「おことば」の履歴[http://village.infoweb.ne.jp/~fxba0022/okotoba/0103okotoba.html#20010330] より。 MAID CAFE[http://www.mangazoo.com/news/news.php3?id=561] は行ってみても良いかな。秋葉原というのが狙っていますね。 長崎にもそもそも制服がメイド服な喫茶店があったと思いましたが、 特にその時は意識しなかったですね。

■ 関連記事

■3 Perlメモ[http://www.din.or.jp/~ohzaki/perl.htm][CLIP]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

URIの正規表現,エンコーディング(エスケープ)について。
RFC2396[http://www.csl.sony.co.jp/cgi-bin/hyperrfc?2396] によれば,':'も'/'もエスケープしないといけないんですね。

■ 関連記事

■4 企業ネットワークへの攻撃者は内部にいる可能性が高い[http://www.watch.impress.co.jp/internet/www/article/2001/0330/kpmg.htm][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

内部の教育不足を含めたら,情報漏洩系のセキュリティ問題の大多数は内部に原因ありでしょう。
セキュリティ対策は費用対効果で考えないといけないのですが, コストバランスを考えるときに,内部犯行のコストを考えてみるのは参考になります。
例えば,あるサーバをネットワークからの侵入者(例えば企業スパイ)から守るためにどれくらいコストを掛けるかという問題は, ネットワークを通じて侵入するコストが,内部のスタッフを買収するコストより大きくなれば十分(あるいはそれ以上は無意味)という考え方です。
もちろんリスク回避となるとまた状況は違ってきますが,セキュリティに掛けるべき費用を考える上で, 内部スタッフの教育やモラルのコストに目を向けることは大切だと思います。

■ 関連記事

以上、1 日分です。

指定日の日記を表示

前月 2001年03月 翌月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project