掲示板スクリプトデータフォーマット規定を作ろう
■ このスレッドは過去ログ倉庫に格納されています
この規定を定めることにより掲示板間のデータファイルの共有や
乗り換えが容易にできるようになります。
0423nobodyさん
02/12/10 00:10ID:???またずれ始めてるぞ。
あと、
もうわかったからあふぉな>>49叩きはやめろ。見ててマジでｳｾﾞｪから。
0424nobodyさん
02/12/10 00:22ID:???http://pc.2ch.net/test/read.cgi/php/1007014580/308
0425nobodyさん
02/12/10 06:01ID:FaxsMvKu0426nobodyさん
02/12/10 06:22ID:???042749
02/12/10 07:56ID:???>ありえそうな全パターンを列挙して規定とし、
>個々の掲示板にはそのサブセットを使うと。
>だるいね。
誰もそんなこと主張してないぜ。普通に優秀な奴らなら、想定される全パターンを盛り込む
規格を作るなんて楽勝（残念ながらこのスレの連中にはそれすら望むべくもないが。）
難しいのはそうして集まったパターンを経済的合理性に基づいて切り捨てていく作業だ。
W3Cの連中は基本的にこれができていないので
XML Schemaなんていうバカげたfatな規格ができてしまうんだな。
042849
02/12/10 08:04ID:???誤 残念ながらこのスレの連中には･･･
正 残念ながらこのスレに粘着してるXML厨の連中には･･･
0430nobodyさん
02/12/10 08:10ID:FaxsMvKu0431nobodyさん
02/12/10 10:46ID:???がいるけどさ、perlのモジュールなんて多くは単なるテキストなんだから、ホームに
コピーしてuse libすれよゴルァ、と思うんですがどうでっしゃろ。
0433nobodyさん
02/12/10 13:05ID:???「想定される」パターンは確かに誰でも盛り込めるけど、
その想定ができないパターンについてどうやって
拡張性をもたせるかも重要なんじゃないの？
0434nobodyさん
02/12/10 13:39ID:kTH/2hjoそういう話をこのスレの前のほうでもしてたんだけどね。>>119-
「切り捨てる」とかいって出来たものは誰も使わないだろう。
0435nobodyさん
02/12/10 17:13ID:???http://www.kaede.sakura.ne.jp/~nikeno/cmt/
>リンク
>掲示板スクリプトデータフォーマット規定を作ろう(2ちゃんねる)
>CMTなんて使ってられねーヨという方はこちらでどうぞ。
やっぱり電波の原因の某氏は(以下略
0436nobodyさん
02/12/10 20:30ID:RdWzoDHt４と５でCMTとXMLについて最初に言及したのは両方とも俺だけど
使ってらんねーよというわけではなくて（INCM使ってるし）
CMTよりベターなものを作ろうとしたらXMLだろうと思うだけです。
0437nobodyさん
02/12/10 21:26ID:???「掲示板スクリプトデータフォーマット」って具体的に何の事？
俺が読んだ限りでは、掲示板が保存するログデータのフォーマット(<>区切りとかCSVとか)の規定かと思ってるんだが、
そうではなくてCMTなんかのように、外部ソフトから呼び出された時に出力する(ことを主な目的とした)フォーマットの事なのか？
0438nobodyさん
02/12/10 23:07ID:???DBの場合、どうするのだろうか。
<>だと拡張するときに大変だって言うけど、
id<>name<>mail<>host<>comment<>upfile<>
1<>nobody<><>192.168.0.1<>I'm depression.<br>I'd like to die.<>hicky.gif:mona.gif<>
こういう感じに、１行目に形式（フィールド名）を定義して、後からデーターっていう感じじゃだめ？
0440nobodyさん
02/12/11 00:23ID:???漏れはそれでいいと思う。
もしくはスクリプトのログデータ読み取り部分を完全モジュール化して、
形式にあわせて各ベンダがモジュールを作成するとか。
0441nobodyさん
02/12/11 00:30ID:???csvベースならそれ以外には考えられないな。
１行目はもう少し複雑になって
最終的には正規表現に毛の生えたような表記方法になるだろうな。
0442nobodyさん
02/12/11 00:40ID:Gdu4L0PC0446nobodyさん
02/12/11 09:22ID:???それに外部から使うのに困る。
CSVなら>>439のようにハッシュを使うものではなく、普通のやつでいいんじゃないかな。
map使うと単なるsplitより(項目数によるが)10倍以上時間がかかる。
普通数十〜百程度の記事を表示するだけだから、あまり速度を気にする必要もないが。
カラムの意味定義は仕様書に任せるとして、結局別口でデータ再利用スクリプトを用意した方がいいんじゃないかな。
データのフォーマット換え程度なら誰でも作れるし。
「掲示板間のデータファイルの共有」に限った話ね。
0447nobodyさん
02/12/11 15:15ID:???データ自体の持ち方はそれぞれがcsvだろうがCMTだろうがXMLだろうが
好きなように持てばいいんだよ。
ただし、それとは別に決められた汎用的なフォーマットも残せ（吐き出せ）
ということだろ。（それにはXMLが最も適している）
ちなみに>>1が言いたいのはcsvフォーマットで残す場合の企画を統一
しないかということだとエスパーしてみる。
0448nobodyさん
02/12/11 15:33ID:???0449nobodyさん
02/12/11 15:55ID:???http://www.zdnet.co.jp/news/0212/11/ne00_tiemann.html
0450nobodyさん
02/12/11 16:02ID:???0451nobodyさん
02/12/11 16:24ID:???掲示板スクリプトデータフォーマットの規格を統一する前にこのスレの規格を統一してくれ。
0452nobodyさん
02/12/11 16:28ID:???csvフォーマットでデータを記録する場合の企画の統一
です。
0454437
02/12/11 17:56ID:???わざわざスマン。
で、今後は「掲示板がエクスポートするデータフォーマットを規定する」が統一見解ってことでOK？
俺はOKよ。
0455nobodyさん
02/12/11 21:34ID:???＆Ｑuot;とかやっとけばオッケーそう。
0456nobodyさん
02/12/11 21:52ID:GtOPPdmi本当は、掲示板が保存するデータのフォーマットを統一するのが
１の望むことだろうしみんなの理想なのだろうが、実際問題として難しい。
（Perl、PHP、Java、ASPなどでもっと手軽にxmlを扱うことができるように
なればいいのだけど・・・）
ならば、せめて統一フォーマットだけでも決めておいて、保存データとして
使うか、エクスポートのみの採用かはそれぞれの掲示板製作者にまかせると
するしかないのではないだろうか。
以上はXML形式にするという前提で話をしてるが、
時代の流れから行くとこれが一番良いでしょう。
0457456
02/12/11 22:00ID:GtOPPdmi＞csvでやるなら、レコード中のフィールドの順番を決めて
これには同意です。
ただし、個人的にはcsv規約に則ったものにしてほしい。
csv規約はに関しては↓とかを参考にしてほしい。
http://homepage2.nifty.com/sak/w_sak3/doc/sysbrd/vb_t12.htm
0458nobodyさん
02/12/11 22:50ID:???実際は、データの規定よりCGI制作者側からするとハードルが低くなって取り入れられる割合は増えるだろうな。
モジュール作って入れるだけでよさそうだし。
いや、データの規定でも、読み込み書き込みルーチン作れば済むって意見もありそうだから、やっぱ作者によるか。
とりあえずXMLで規定するのは了解です。
よくわかってないが、汎用性があるらしいから。
欲を言うと、掲示板巡回ソフトの類がもっと増えて欲しいな。開発競争ってのが無い気がする。
>>455
CSVは掲示板によって項目数がかなり増減するから、規定作る場合は面倒そう。
>>439みたいに見出しレコード使う手もあるけど、各データで項目の意味合いが完結してる方が簡潔だ。
まずガンガッテXML仕様書読むとするか・・・。でも英語はイヤんな感じ。
0459nobodyさん
02/12/11 23:33ID:???0460nobodyさん
02/12/12 00:29ID:???0461nobodyさん
02/12/12 06:58ID:njI4CLTT・XMLフォーマットは将来を見据えた理想、現時点で採用は難しい。
・csvフォーマットは現在最も普及している、採用が容易。
ということで、どちらを選ぶかは掲示板製作者の自由にしておく。
どちらもフォーマットを決めて置くことで相互のデータの互換性も
あると思うのですが。
0463nobodyさん
02/12/12 07:59ID:???>342
スクリプト側でのデータの持ち方はいまさら決めても
仕方ないだろ。
すでにあるスクリプトでで対応するのは考えられないし。
0466nobodyさん
02/12/12 14:19ID:FvLiMeis0469nobodyさん
02/12/12 15:04ID:LfYYQWKp0471nobodyさん
02/12/12 15:21ID:???name<>link<>msg
というデータ形式をいったん決めたとする。
そのあとにlinkをwebとmailに分離して定義したいと思った時、
linkの項目を削除して定義し直すと、
それ以前に作ったデータとの互換性が失われる。
データ項目はあとからどんどん付け足すことしかできない。
XMLなら柔軟にデータ項目の追加削除が可能。
0472nobodyさん
02/12/12 15:23ID:???0473nobodyさん
02/12/12 15:27ID:???0475nobodyさん
02/12/12 16:48ID:???例えばXMLだと送信者の情報をいれとこうと思うと、
すでに個人情報のマークアップの仕方を定めてる勧告があって、
それを使用することで、個人情報の中身には一切関わらなくても、
｢この要素の内容の"個人情報"は"送信者の個人情報"ですよ｣
って事がわかってれば、内容についてはノータッチでいける。
将来的にあたらしい種類の個人情報が登場してもノータッチ。
CSVで行の最初に・・って方法で、個人情報を入れたいと思うと(あくまで投稿者の任意だが)
id<>name<>mail<>host<>comment<>upfile<>住所<>電話番号<>郵便番号<>氏<>名<>・・・
みたいにきりが無い。
(CSV扱うプログラムにに他のschemaを読みに行く能力をつければ可能だが、
自分の知る範囲でそんなものはない。)
0477nobodyさん
02/12/12 17:12ID:???そんなのKENTが考えたやり方だろ。
それこそ汎用性に欠けるんだけど。
CSV＝Comma Separated Value、な？
0478nobodyさん
02/12/12 17:13ID:???汎用性って何ですか？
id<>name<>mail<>host<>comment<>upfile<>
うえのように１行目で、形式を定義するんだけど、僕が言いたいのは
その１行目のフィールド名を元に
$out{id}
$out{name}
$out{host}
$out{comment}
$out{upfile}
みたいな感じの入れ子を作って出力するってことなんだ。
こうすれば、他の形式のログを読みとるとき
id<>name<>mail<>url<><>pass<>host<>comment<>icon<>
となっていても、問題なく今までの掲示板でよめる。
大切なのはログの形式が、１行目のファイル形式のルールに従うこと。
こうすれば、ログを拡張しても、最低限読むときの下位互換は得られる。
問題は、形式の異なるログを更新したりするときに、一工夫いるところだけどね。
（古いバージョンの掲示板側で出力しないデータは空欄でいいのかとか、
使っている掲示板のデータだけ記録すればいいのか、など）
0480nobodyさん
02/12/12 17:35ID:qH8N5K0u掲示板フォーマットが、だろうと言ってみるTEST
0483nobodyさん
02/12/12 17:47ID:???, がデータに入る可能性がある、<>は<>に変換するからデータに入る可能性が無い。
だからだろ。
それが良いか悪いかは別にして、それくらい自分で思いつくぐらいには脳みそ使ってやらないと
しまいにゃ脳みそも腐ってしまいますよ。
> そんなのKENTが考えたやり方だろ。
KENT以前からありますよ。
0484nobodyさん
02/12/12 17:48ID:???>しまいにゃ脳みそも腐ってしまいますよ。
煽り不要。ギロンしようぜ。
0488nobodyさん
02/12/12 17:58ID:???プログラムで個人情報触る必要があるなら(そのような規格なら)、
個人情報を勧告した団体からでるだろ？
(データとして扱って普通に表示する分ならDOMに対応してれば十分だが、)
で、それを組み込めばSVGみたく、
乗せるのがXHTMLだろうが掲示板フォーマットだろうが、処理できるって事。
0489nobodyさん
02/12/12 17:58ID:???思考が停止してる人が議論に入ってきても自分だけが正しいって思い込んで
全然中身のある議論になんねーんだよ。
0491nobodyさん
02/12/12 18:06ID:???そういう団体が個人情報の最終利用形態まで全て包括的にライブラリとして
提供してくれるわけじゃないよな？
ってことはいずれにせよプログラムがその規格の中身を理解してないとだめじゃん。
0492nobodyさん
02/12/12 18:06ID:???名前、記事番号、返信元記事番号、投稿回数、タイトル、本文
の要素があるとする。
XMLだと
<news><name>なまえ</name><number>11</number><reference>10</reference>
<posttimes>3</posttimes><subject>たいとる</subject><text>ほんぶん</text></news>
みたいな感じにできるのかな？？
CSVでは一行目を見出しとして
name,number,reference,posttime,subject,text
なまえ,11,10,3,たいとる,ほんぶん
か。
ここで投稿回数がいらなくなったら、XMLなら要素を削ればいいだけだけど
CSVだと単に削っただけではダメ。全体を書き換える必要がある(もしくはゴミを残して無視)。
その後も掲示板の仕様が変わるたびに要素が増えたり減ったりして面倒。
XMLが推されるのはこんな理由かな。
でもエクスポートに関しては、面倒さではあんまり変わらないのかも。
汎用性については、XMLはすでに規格化されていて、パーサー使っていかようにも構文解釈できるってことかな。
この辺が俺の中でもかなり謎。
XMLの知識無いから見当はずれな事書いてるかも。
俺は(掲示板のエクスポートに関しては)CMTボンバイエだけど、
XMLだからといって毛嫌いしているわけにはいかんだろ。
それが有効ならば取り込んでいかないとね。
もちろん他に有用なものがあればそっちがいい。
俺はCMTで十分だと思ってる。今の掲示板を扱う外部アプリがあんまり無い現状ではね。
0494nobodyさん
02/12/12 18:11ID:???>CSVだと単に削っただけではダメ。全体を書き換える必要がある(もしくはゴミを残して無視)。
XMLでもCSVでもファイル全部書き直しだろ。
0495nobodyさん
02/12/12 18:13ID:???それに加えて区切りの見やすさからこれになったんじゃないかと推測。
>>477 変形CSVだけど、いちいち厳密なCSVでないなどと断る必要ないだろ。みんなわかってんだから。
別に , 区切りで , としても タブで 	 としても良いし、<>なのは単なるデファクトなだけでどうとでもなる。
HTMLで表示するのが前提だから、当然 < などの一文字ではタグの扱いができない(面倒になる)という問題は自明。
<br>に変換するのは、掲示板ログとしてならOKだと思う。その方が処理が少なくすむと言うメリットがちゃんとあるんだから。
0496nobodyさん
02/12/12 18:29ID:???掲示板ログの話になるけど、XMLなら無視すればいいだけなんじゃないかと思うわけだよ。
XMLは各記事毎に項目の意味づけがされてるわけだけど、CSVは一行目の見出しに意味づけがあるだけで、一行目と全体とが連動してるでしょ。
XMLなら同じログファイルに<posttimes>がある記事と無い記事が混在してても問題ないと思う。
CSVだと一行目のカラムを削ったら、全体も削らねばならない。もしくは見出しにゴミを残したままになる。
という考えです。
そもそもXMLの認識が間違ってるのだろうか。無責任でスマン。
>>479に関しては、ハッシュを使おうとCSV型の欠点は補えないでしょ。
仕様が変わるたびに見出しが長くなってしまう危険性がある。
ちなみに俺はCGI書くときデータはCSVだよ。
使うなというのではなく、より便利なものがあればそっちにしたいという考えです。
0497nobodyさん
02/12/12 18:35ID:???なるほどそういう意味か。理解が浅くてスマソ。
しかし思うにファイル(Read)→プログラム上のデータ構造→ファイル(Write)
という過程を考えるとどのみち整形されてしまうんではなかろうか。
0498nobodyさん
02/12/12 19:02ID:???結局そうですね。
正直俺も掲示板の処理が煩雑になって、結局メンテナンス性が悪くなるんじゃないかと危惧してる。
これでパターンマッチ使うようなら速度もずっと遅くなるし。(ここでは速度はあまり重視しない方が良さそう)
このスレではメンテナンス性の良いものを考えるべきだな。
というか、掲示板のデータ構造は各作者に任せて、エクスポートするデータフォーマットを考えることに絞った方がいい。
0500nobodyさん
02/12/12 19:14ID:???0501nobodyさん
02/12/12 19:43ID:???split /,/; で済む。たぶん他のどれより速い。
でも>>344みたいにハッシュにした方が断然使いやすいけどな。
なんだか目的もなくたゆたってる気分ナリ。
0503nobodyさん
02/12/12 20:35ID:???0504nobodyさん
02/12/12 20:37ID:???>ってことはいずれにせよプログラムがその規格の中身を理解してないとだめじゃん。
言い方がわかりにくかったか…
こっちでプログラムを管理しなくて済むってことの有効性は他にもあって、
例えば、
XHTMLにうめこまれた個人情報を解釈するプログラムと、
掲示板用のXMLにうめこまれた個人情報を解釈するプログラムがそれぞれ別々だとすると、
たった２つだけならいいけれど、
他にも個人情報を埋め込みたい文章はいっぱいあるわけだから、
それぞれが、個人情報を処理するコードを内部にもつとなると物凄い量になって、
バージョンがあがるごとに、それぞれのプログラムがアップデートしてそれに対応しなきゃならない。
その点、外でもってくれると、アップデートは気にしなくていい。
>そういう団体が個人情報の最終利用形態まで全て包括的にライブラリとして
>提供してくれるわけじゃないよな？
勧告が規定するものが"外部的なプログラムを使用して解析されなければ意味のないデータ"の場合、ほとんど出てるよ。
でも、例の"個人情報"という内容だけならば、XMLパーサーで十分。
0505nobodyさん
02/12/13 01:21ID:???csvで充分。
0507nobodyさん
02/12/13 03:39ID:???うむ。言いたいことは十分わかる。漏れも昔はそういう理想的な世界を考えていた。
しかし良く考えてみてくれ。
個人情報をHTML形式で清書するみたいなプログラムは確かにライブラリでＯＫかもしれん。
しかし例えばプログラム内で掲示板の書き込みを「年齢順」にソートする場合、
どうしたってプログラムで「年齢」という要素にタッチせざるを得ない。
つうことはそのプログラムが個人情報の規格に否応でも依存してしまうわけだ。
逆に言えば、そういう個々のプログラム内でタッチしないような「個人情報」なら、
年齢や住所などをベタにテキストで持っておいても（人間さえ解釈できればいいわけだから）
構わないとさえ考えられる（XMLで持つ利点といえば清書できるぐらいか？）
0508nobodyさん
02/12/13 04:20ID:???それともこの混沌の中から掲示板データフォーマットを搾り出すのか？
0509nobodyさん
02/12/13 05:10ID:???>>479あたりが落し処なんじゃないかと思う。
世の中のサーバ環境はまだXMLに寛容ではないし、掲示板プログラマに至っては尚更だ。
例えばスクリプト言語なりがネイティブにXMLを読み書きできるようになれば
また話は変わってくると思うのだが。
0510nobodyさん
02/12/13 09:07ID:???増やすときにこのスレみたいなのでいちいち議論というのもなぁ…
0512nobodyさん
02/12/13 14:04ID:???HBの鉛筆をベキッ！とへし折る事と同じようにッ
できて当然と思うことですじゃ！
大切なのは「認識」することですじゃ！
CSVを操るという事は できて当然と
思う精神力なんですぞッ！
0513nobodyさん
02/12/13 14:34ID:???0514nobodyさん
02/12/13 16:08ID:???>しかし例えばプログラム内で掲示板の書き込みを「年齢順」にソートする場合、
>どうしたってプログラムで「年齢」という要素にタッチせざるを得ない。
>つうことはそのプログラムが個人情報の規格に否応でも依存してしまうわけだ。
XSLって言うXMLの応用規格を使えば簡単にその事ができる。
"年齢"という要素名をパーサーが読み込んでXSLスタイルシートを適用するだけ、
>>145にある上の奴に
http://homepage3.nifty.com/sepura/bbsformat/test.xsl
が適用されると下のほうのサンプル(普通に見えるやつ)に見える。
（実は下のサンプルは７行ぐらいのテキストで成り立ってる。
で、XSL使うと例えば日付関係無しに日時だけで並び替えとかも簡単。）
で、他にもXSLスタイルシート使うと、例えばツリーがそのまま反映されたXMLを読み込んで、
親番号指定の"<>"区切りdatに変換する事も簡単。な筈。
それについては>>83-84
0515nobodyさん
02/12/13 16:09ID:???○＞で、XSL使うと例えば日付関係無しに時刻だけで並び替えとかも簡単。）
ｽﾏｿ
0516nobodyさん
02/12/13 16:26ID:???0517nobodyさん
02/12/13 18:07ID:???0519nobodyさん
02/12/13 18:25ID:???0520nobodyさん
02/12/13 18:32ID:???XMLのﾒﾘｯﾄっていうのはあくまで表示でなくて
あくまでデータ扱いの汎用性を維持することだろ？
それを行う事が表示にもつながるわけだ。
で、べつにデータの互換がしっくりできてれば表示はプログラムでレンダリングするなり、
XSLを適用できるプログラム使ってレンダリングするなり好きにして下さいってこった。
■ このスレッドは過去ログ倉庫に格納されています