コンソールの2chブラウザを作るスレッド - 1489736608

1：ひきぷろ ◆SVQfrniSJY：2017/03/17(金) 16:43:28 ID:???0: コンソールの2chブラウザを作ってみよー

wiki
https://www54.atwiki.jp/projecthikky/pages/104.html
2：ひきぷろ ◆SVQfrniSJY：2017/03/17(金) 20:44:39 ID:???0: 検索してみたら、

・2chブラウザは2015年からAPIアクセス必須
・APIアクセスするためには2chからAPIキーを発行してもらう必要がある
・APIキーはオープンソースには許可が出ない

ということなので、開発できなさそうかな。
とりあえず、公式のページからAPIの発行申請してみた
メール来たら結果を書き込んでみる
3：（-＿-）さん：2017/03/17(金) 23:19:41 ID:???0: ウェブスクレイピングでいけるんじゃね？
ユーザーエージェントを一般ブラウザ(IEとか)に偽装すりゃ何とかなるっしょ
4：（-＿-）さん：2017/03/17(金) 23:21:24 ID:???0: GitHubはmasterブランチを表に出すから
偽装リポジトリでリポジトリの説明やmasterブランチには関係ないアプリを作ってるかのように見せて
別ブランチで開発進めればバレなさそうだし
5：（-＿-）さん：2017/03/17(金) 23:22:06 ID:???0: Bitbucketに公開ブランチ作ってもネット検索に引っかからないみたいだからそっちで開発するってのもありかな？
6：（-＿-）さん：2017/03/17(金) 23:24:08 ID:???0: GitLab.comは非公開ブランチでもコラボレータの人数無制限だから
オープンソースにしなくても開発が可能（しかし非公開だと招待がいるけど)
7：ひきぷろ ◆SVQfrniSJY：2017/03/18(土) 06:57:57 ID:???0: 技術的な問題をクリアするという意味では、スクレイピングでいけそうだよね。
非公式にアクセスするツールはいくつか作られてるっぽい。

yama-natuki/2chproxy.pl
https://github.com/yama-natuki/2chproxy.pl

masami-dev/chaika-api: chaika (https://github.com/chaika/chaika) に非公式な 2ch API サポートを組み込むプロジェクト
https://github.com/masami-dev/chaika-api

できるできないでいうと、おそらく作ることはできそうだね。
教えてくれたみたいに、リポジトリの置き場を工夫するとか、プライベートリポジトリに設定すれば、
ひっそり進めることはできそう。

2chの考え方としては、おそらく2ch.sc排除のためのAPIだろうし、小規模で専用ブラウザを作ってても何も言われなさそうではある。
ただ、多少リスクはあるよね。コンソールの2chブラウザが大々的に流行る可能性は低いだろうけど、
流行ったら何かしら怒られる可能性はゼロではなさそう。

僕個人の意見としては、作っていくのはちょっとつらい感じがする。
興味ある人が居たら、進めてもらえたら楽しそうだけど
8：（-＿-）さん：2017/03/18(土) 18:54:54 ID:???0: 2ch運営の収入源は
・2chに表示される広告収入（現在専用ブラウザにも広告表示をさせてる）
・浪人システムによる収入（専用ブラウザの広告非表示やその他色々特典）
・メロンポイント購入による収入（ＢＥユーザ対象）

こんな感じか
API導入は収入源確保の策なんじゃないだろうか
(scのコピー止まってないしsc対策にはなってないぽいし)
9：（-＿-）さん：2017/03/18(土) 18:58:25 ID:???0: https://developer.2ch.net/

ここのページにはスクレイピング型の専用ブラウザの公開を禁止してる
個人で開発して公開しないのなら問題はなさそうだけど
「公開」の定義次第だよね
10：（-＿-）さん：2017/03/18(土) 19:01:44 ID:???0: > •ウェブスクレイピングを用いた専用ブラウザの開発、公開は禁止されます。

これは開発も禁止してるのか
11：（-＿-）さん：2017/03/18(土) 19:18:00 ID:???0: 『公開』に関しては2chの収益を阻害しかねないから業務妨害（刑事？）？（でも世の中にアドブロックとか広告表示ブロックのプラグインとか出回ってるしどうなんだろう？）

『開発』に関しては民事？公開してない限り特定はできないし
法律で明確に禁止されてるのはウイルス作成罪（刑事）？
2chの不特定多数に公開されてるデータにアクセスするわけだからスクレイピングは不正アクセス禁止法の対象にはならないし(許可ないAPI利用なら不正アクセスだが)
そもそも不正アクセス禁止法は開発そのものを禁止してるわけじゃないし（実際に不正アクセスするあるいは誰かが不正アクセスできるようしたらアウトって法律だし）

スクレイピングの問題としてはあとは著作権法の問題があるが開発を禁止するものの類じゃない
http://qiita.com/nezuq/items/3cc9772118ad112c18dc
http://qiita.com/nezuq/items/c5e827e1827e7cb29011

あとはクローリング・スクレイピングのアクセス頻度が多いと業務妨害(刑事）になるがこれは頻度少なければよいだけ
（1秒に1回アクセスは前例が出来てしまったためアウト https://media.accel-brain.com/librahack/　）
12：（-＿-）さん：2017/03/18(土) 19:24:19 ID:???0: 不正アクセス行為の禁止等に関する法律 - Wikipedia
https://ja.wikipedia.org/wiki/%E4%B8%8D%E6%AD%A3%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E8%A1%8C%E7%82%BA%E3%81%AE%E7%A6%81%E6%AD%A2%E7%AD%89%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E6%B3%95%E5%BE%8B#ACCS.E8.A3.81.E5.88.A4

ACCS裁判ってやつ糞すぎなんだけど何これ・・・スクレイピングがアウトになる前例ケースやん・・・
13：（-＿-）さん：2017/03/19(日) 05:11:07 ID:???0: PC版2chはShiftJISだから
https://godoc.org/golang.org/x/text/encoding/japanese
このパッケージがいるね

(スマホ版2chはUTF8、APIのほうは知らない)
14：（-＿-）さん：2017/03/19(日) 05:21:52 ID:???0: https://godoc.org/golang.org/x/net/html/charset
これのDetermineEncodingでダウンロードしたhtmlファイルのエンコーディングを特定できるみたいだね
15：（-＿-）さん：2017/03/19(日) 05:22:45 ID:???0: https://godoc.org/golang.org/x/net/html
このパッケージは
HTML5限定っぽさそうだけどHTMLタグをパースできる
16：（-＿-）さん：2017/03/19(日) 05:32:17 ID:???0: https://golang.org/pkg/net/http/

ネット接続はデフォルトのパッケージにあるnet/http使えばよさそうだね
17：ひきぷろ ◆SVQfrniSJY：2017/03/19(日) 06:46:50 ID:???0: おお、リスク分析をきちんとする感じ良いね！
書いてくれてる内容を読んだら、たしかに2chのAPI導入は、収入源確保のための発想だと思った。

法律の話はあんまり分からないけど、判例主義って考え方もあるし、
過去にどんな判決が出たのかを調べたら、同様のケースは予想できそうだよね。

役立ちそうなライブラリも、しっかり調べてくれてて、
進めていったら面白そうな感じはするね。
18：ひきねこ ◆ez9QVuDvy2：2017/03/20(月) 06:28:01 ID:???0: おっ？(*´∀｀)ブラウザ作るの？
19：（-＿-）さん：2017/03/20(月) 22:15:33 ID:???0: termboxの2chブラウザな
20：（-＿-）さん：2017/03/21(火) 00:08:15 ID:???0: 板情報を保持する型の設計

type Board struct {
Name string // 板名ヒッキーとか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
}
21：（-＿-）さん：2017/03/21(火) 00:12:47 ID:???0: >>20
スレッドの一覧も情報として持たせたほうがいいのか

type Board struct {
Name string // 板名ヒッキーとか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []Thread // スレッド一覧、nilのときは一覧を未取得
}
22：（-＿-）さん：2017/03/21(火) 00:16:28 ID:???0: スレッド情報を保持する型の設計

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得
}
23：（-＿-）さん：2017/03/21(火) 00:22:00 ID:???0: >>21-22
最終取得日時もあったほうがいいのかも、アクセス頻度制御のために

type Board struct {
Name string // 板名ヒッキーとか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []Thread // スレッド一覧、nilのときは一覧を未取得
LastUpdate time.Time // 最終取得日時
}

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得
LastUpdate time.Time // 最終取得日
}
24：（-＿-）さん：2017/03/21(火) 00:25:35 ID:???0: レス情報を保持する型

type Response struct {
Name string // レスの名前欄(トリップやワッチョイどうしよう)
Mail string // レスのメール欄 (普通はsageとかageとか)
Date time.Time // レスの書き込み時刻
ID string // レスのID
Host string // IPアドレスやHost名が出る板とかあるし
Body string // レスの本文
}
25：（-＿-）さん：2017/03/21(火) 00:34:24 ID:???0: 仕様変更に柔軟にするには型内部のデータを公開するよりアクセサメソッドを定義したほうがよいのかな
26：（-＿-）さん：2017/03/21(火) 00:38:41 ID:???0: >>23
これのままだとスレ保持数とレス保持数は取得済みの数値しか管理できないから取得可能な数値も保持すべきか

type Board struct {
Name string // 板名ヒッキーとか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []Thread // スレッド一覧、nilのときは一覧を未取得
LastUpdate time.Time // 最終取得日時
LatestCount int // 最新のスレッド数(len(ThreadList)との差分が取得可能な数)
}

type Thread struct {
Title string // スレタイ、ヒッキーのプログラミングするスレ 9 とか
URL string // スレのURL、http://hanabi.2ch.net/test/read.cgi/hikky/1489179773/ とか
Res []Response // スレの全レス、nilなら未取得
LastUpdate time.Time // 最終取得日
LatestCount int // 最新のレス数 ( len(Res)との差分が取得可能なレス数）
}
27：（-＿-）さん：2017/03/21(火) 00:46:39 ID:???0: スレ一覧はage/sageで順番が変わるし保持の仕方変えたほうがいいか

type ThreadID int64

type Board struct {
Name string // 板名ヒッキーとか
URL string // 板URL http://hanabi.2ch.net/hikky/ とか、net/urlにURL型あるけどstring型で保持でもいいかも
ThreadList []ThreadID // スレッド一覧(ID)、nilのときは一覧を未取得
ThreadTable map[ThreadID]Thread // 各スレッドの情報はThreadIDに紐付けたマップで保持
LastUpdate time.Time // 最終取得日時
LatestCount int // 最新のスレッド数(len(ThreadList)との差分が取得可能な数)
}
28：（-＿-）さん：2017/03/21(火) 00:58:12 ID:???0: スレがスレ一覧から除外されてるかの判定もいるか、過去ログ化判定？

例えば板情報にスレ一覧の取得回数を保持しておき
スレ一覧に存在したスレ情報にそのスレ一覧の取得回数を書き込んでおき
板情報のスレ一覧取得回数と一致する数値を持つスレだけを生存スレで他を過去化って判定するのとか
29：（-＿-）さん：2017/03/21(火) 01:01:28 ID:???0: 板情報のThreadList []ThreadID は
取得したスレ一覧というより表示順(レス数順とか勢い順とか)を保持したほうが良さそうかな
30：（-＿-）さん：2017/03/21(火) 01:11:43 ID:???0: 毎回ダウンロードして全データを常にメモリってわけでなく当然パソコン内にダウンロードしたデータを保存するわけで
スレッド一覧やレスを未取得なのか未ロードなのかの区別が必要か
ブラウザ起動のたびに保存してる全データをロードするのは普通しないだろうから
取得済みのレス数とかも保持したほうがよさそう