datをUTF8にするのはどうだろうスレッド

datをUTF8にするのはどうだろうスレッドです。

影響があるのは、AA周りすかねぇ。

↓ハゲスト

野
々
村

utf8にしちゃえば、read.jsが使えるので、
サーバリソースは軽くなるかなぁと。

ぅぉたらこだ

転送量とDAT容量は増加するかね。

やるならBOMつきにしてほしいなぁ。

　　 /⌒ヽ)
　　i三　∪
　○三　|
　　(/~∪
　　三三
　三三
三三三

今更変更かい

　　　　　　　_r-._,-,_
　　　　　 r‐'　＿_　~t_
　　　　　j'／"il li ~＼〈
　 　 　rf/l |_l_l| |l_l_ iﾞﾄ'､
　　 ／"ﾊl　U　　U　|lﾞi l　　　　
　　/ /　li.ゝ γﾆ ヽﾉ | l |　　 ふ〜ん
.　 l /　 il　f:`l .l i_| |　j　l |
　 |/　 ξ　ゞ_`,-ｨｲ ξ　l|
　 彡　 　 /:::::::::::〇, 　　ミ
　　ｿ 　　 i::::::::::::::l_l:l　　 ﾘ

今日はちとこれからおでかけにつき、記念カキコのみで。

何となく、いろんなところが影響ありな気がしますけど、
やる価値はあるかもですね。

ただ、これまでのSJISのdatを変換するのは実際的ではなさそうなので、
どうしても「混ざった」状態になると。
ということで大抵のスクリプト(削除など)は、
両方対応にしないと、だめなような。

大変だ！キャップが割れたぞ！！

で、ライブなdatだけでも一斉に変換するかどうか、
というのも考えどころなのかな、と。

UTF8なんてffftpの設定か
テラタームの初期設定くらいでしか見たことない

そんなにサーバリソースが重かったのか
知らなかった

utf8のdatファイルを.dataとかにするか、
qb7みたいに新しいサーバ名の.datを全部utf8にするか、、、

管理周りは粛々と対応すればなんとかなると思うのですが、
アスキーアートみたいに、出来なくなることとか、
デメリットはどういうのがあるのかなぁ。。と。

よくわからんけど
read.cgiをapacheモジュールにしたらいい
ついでにbbs.cgiも
mod_2ch

>>15
そんなことよりbeをどうにかしろやコラ

デメリットや手間のわりにメリットは少ないかと・・・
大抵のソフトウェアはdatはSJISだと決めてハードコーディングしてるだろうかなぁ・・・

UTF-8でAAが影響受ける？なんで？
フォントなら、CSSでsans-serifつけりゃいいと思ってるけど

半角カナとか。

>>4
現状でもある程度read.jsは使えてるし、UTF-8にしてもそんな軽くならないと思う

>>6
UTF-8にBOMは必要ないから反対

>>20
半角カタカナはUnicodeに存在して普通に使えるよ

上のもんは下のもんの気持ちは汲んでも
顔色を伺ったらあかん

って仮面の兄ちゃんがいってた

UTF-8の問題点は、サイズだな。
日本語の場合たいてい1文字で3バイト使うから、500KB制限を引き上げる必要があると思う。

ひろゆきがこんな事を思いつくとは思えない
ひろゆきにUTF-8を勧めた人間出て来い

＞半角カタカナはUnicodeに存在して普通に使えるよ
まじすか。

http://code.cside.com/3rdpage/jp/utf-8/Halfwidth_and_Fullwidth_Forms.html

これのことか
ユニコード上にある半角カタカナってーのは

半角カナはバイト数増えるけどつかえるよ。

UTF8でdatのサイズが大きくなったら、ますます重くなるのでは
サーバリソースも食う事になる

なるほどなるほど

サイズが問題ならUTF-16にする？ｗ

ん...... UTF-8 にしないと read.js が使えない環境ってどんなのだろう？
少なくとも，IE6 での問題は anydat.so で対策されてますが......

anydat.soみたいなサーバ処理がいらないものだけで、
回せないかなと。

IE6 を無視すれば Content-Type で charset=Shift_JIS を追加するとかでいいんで
mod_headers で事足りるわけですが......
IE7 への強制アップデートもあったらしいですし，今後 IE6 の比率が下がれば
それでいいのかも，とも......

２ちゃんねるの中というか日本ではIE7アレルギーが異常だから
欧米とかに比べると普及は遅れていると思うよ>>33

IE厨は腹を切って死ぬべきである

まぁ IE6 での問題は文字コードより，JavaScript が時々挙動不審になったり
ブラウザの動作が重くなったり，ということの方が大きいんですけどね．

# それで read.js をデフォルトにするのを断念した，という経緯も......

>>30
UTF-16にすると、1バイトで表現できている英数文字が2バイトに
なるであってる？
UTF-8は漢字が2バイトから3バイト必要になる
どちらにしても、datサイズが増える事に変わりがないような
そうすると、オンメモリで処理可能なdatの総量が何割か減ったり、
通信容量の増大を招いたりでいい事がないような

>>37
あってる

ただ、Shift_JISは日本語のコードにASCIIを含んでるから(つまり腐ってる)
UTF-8にすればShift_JISだったから必要な余計な処理が無くなって
負荷が減るとかコードの見通しが良くなるとかあるかもね。
Rock54まわりはいろいろ大変だったような。

ほいほい文字コード変えられたら
内部設定をテキストファイルで読み込ませる組み込みは大変なことになる
多言語対応なんてやってられねーんだよ
どこのlinux脳だ
ということに

まぁ read.js 以外のことを考えた場合，>>38 のような利点はありますけどね．
もっとも，その点に関しては EUC-JP でもいいんですけど．

UTF8になったらしばらくは変える必要無さそうだけどね。

EUCはなぁ。ちょっと変える利点が。

キャップの文字化けとか
目欄で「age」の直前に「鋭郭虐茎行市峻尽壮痴」でsageになってたとか
そんなの無くなる？

なくなるね。

トリップはどうなるんだろう。
送られるデータが変わるわけだからやっぱり変わるよな。

不正バイトシーケンスの問題は，どの文字コード使うにせよ
解決するならきちんとチェックするという以外ないような．

なんぞこれ
http://www.itmedia.co.jp/news/articles/0804/10/news079.html

持ってる運用情報のdatファイル1102個をiconvを使ってCP932からUTF-8に変換してみた。
正常に変換できたdatが1024個(偶然)。

CP932の場合　98.1MB (平均で98KB)
UTF-8の場合　121MB (平均で122KB) 　1.24倍

意外と大きくなってない。
この程度の増加なら、全然許容範囲だと思った。

>>46
出た異常についてｋｗｓｋ

>>47
iconv: 位置 138601 で不正な入力シーケンスがありました
携帯の絵文字が入ってたとかそんなとこかねえ

1.24倍の容量増をでかいと思うか、ちいさいと思うかは
メディアコストに対する認識の差だろうな

サーバリソースを軽くするのが目的で、24%増になるのは本末転倒じゃないだろうか

容量が増えると花子が困るな

２ちゃん用の文字コード作ればいいよ

ザウルスとか旧Palmとか古い機種の専ブラは大丈夫なんだろうか？

>>50
処理量を優先するかストレージを優先するかの優先度の問題でしか無い。

UTF-8にするんなら、いっそのことdatの仕様を思いっきり弄くり回すとか。
レイアウトとフォントはCSSにすればdat自体の容量は減る
互換性全くなしで、専ブラがひどいことになるがｗ

「これが、私が考えた掲示板だ。使い勝手についていろいろ言う人もいるかもしれない。
　それは対応する専用ブラウザを作るボランティアや利用者が、この仕様に合わせてもらうしかない」

この道ーはー
いつかーきたみーちー

最大の問題は過去のdatの扱い（一括変換するにしてもshift-jisのまま放置にしても）

将来を見据えた時代の流れでいいんじゃね？
Shift-JISが許されるのは20世紀までだよね

とりあえず新板で試すのがベターだろうな
で、専ブラ作者には馴れてもらうと
その流れで文字コードの判別にセンシティブになってもらうと

変換とか引越しって、絶対にトラブるんだよな

新板からとか、スレッド番号でスッパリ分けるとかするべきだろう。
あと、文字コード情報について正しくヘッダを送る。

既存のスレッド全部変換するのは、失敗のリスクとかが大きいと思う。
それから512KB制限も考え直すべきでしょう。

>>60
512MB制限…
　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／

新板立てなくとも金があるじゃない。

専ブラがdat拾うときもhttpで拾うわけだから、Content-typeのヘッダ見れば
理論上はいいのけ？追加メタ情報いらない？

なんか変更を見据えた話になってる？
多言語扱うわけじゃないし
変えるメリットが見当たらない

ここはひろゆきをなだめて止めさせるべきだろ

サーバリソースを使わないモデルにできれば、
人大杉が無くなるかなぁと。

IEのためにマイクロソフトにでも頼まれたのか

つか人大杉をなくしてread.htmlに転送して欲しい。

全部read.jsにしておまえらのブラウザで処理してくれー
つーことに？人大杉よりはいい罠

datの仕様も変えてくれりょ

>>63
過去ログを.datファイルで入手したときに分かりにくくなる。
BOM有りならutf-8、無しならshift-jisと判断できるのが一番簡単で確実。

>>69
具体的に何を変えて欲しいんよ？

人大杉解消が一義的な目的であれば，少なくとも read.js に関しては
ネックになるのはむしろ文字コード以外の部分ですね(>>36)．
anydat.so 自体は，ライブな dat を扱う際はデフォルトハンドラとほぼ同程度の
処理しかしないので，負荷的には anydat.so を使わない場合とほぼ変わらないかと．

ちなみに，人大杉状態の時に板トップの「read.cgi モード切替」が効かない問題に関しては，
技術的問題よりポリシーの問題（いつぞやの FOX さんの「見えないようにしているのは意図的なので
人大杉の時には read.html に振らないようにしてほしい」という趣旨の発言を受けたもの）なので，
これについてはしかるべき人にしかるべき方針を打ち出してもらえれば，効くようにすることは不可能ではないです．

AAにユニコード文字がほのまま使えるなら賛成

ってか互換性がどうなるんだろう

UTF8ってbe系の板で既にやってなかったっけ？

>>75
やってない。前Be系の板はBe関連のシステムがPHPで文字コードがEUC-JPだったから
それに合わせてたけど06年ぐらいにログ全部Shift_JISにコンバートして移行した

>>53
あー古い機械からは全部見れなくなるな…
昔の携帯もダメかもしれん

>>55
datは現状でいいんでね？

と、思ったが、日付とIDとbeとかが全部一つになってるのはちょっとな
xmlにしてくれたら助かるが、そうはいかんか

>>64
多言語扱えたほうが便利でしょ
曲のタイトルにアクセント記号つきのアルファベットとかあるし
ニュースで中国人の名前書くとき便利になるし
àáâäçñ

>>78
XMLは単純にレスを追記することが出来ないからねえ。
<>区切りはどうかと思うが。

外字とか画数の多い漢字は実体参照にしてutf-8で実体山椒のままにしておく必要のない
実体三章は素の文字に変えて、とりあえずutf-8にしてしまったらええ。
専ブラなんて気にすんな。utf-8にしてフラッシュでも何でもつこたらええ。

>>76
あ．．EUCだったな。
コンバートしたのは不覚にも全然知らなかった。
でも、それに対応するために多くの専ブラはEUC-JPに対応してるはずだから、
実装によっては今回の対応が必要ないものもあるのかも。

<2chdat>
　<res>
　　<name>名無しさん</name>
　　<msg>datは現状でいいんでね？と、思ったが、日付とIDとbeとかが全部一つになってるのはちょっとなxmlにしてくれたら助かるが、そうはいかんか</msg>
　<res>
　<res>
　　<name>名無しさん</name>
　　<msg>datは現状でいいんでね？と、思ったが、日付とIDとbeとかが全部一つになってるのはちょっとなxmlにしてくれたら助かるが、そうはいかんか</msg>
　<res>
</2chdat>
じゃなくて
　<res>
　　<name>名無しさん</name>
　　<msg>datは現状でいいんでね？と、思ったが、日付とIDとbeとかが全部一つになってるのはちょっとなxmlにしてくれたら助かるが、そうはいかんか</msg>
　<res>
　<res>
　　<name>名無しさん</name>
　　<msg>datは現状でいいんでね？と、思ったが、日付とIDとbeとかが全部一つになってるのはちょっとなxmlにしてくれたら助かるが、そうはいかんか</msg>
　<res>
と、単純追加出来る独自形式とか…ｗ

今でこそ<>区切りは掲示板のログの標準だけど
何かの標準規格で、それに2chが合わせただけなの？
それとも慣習？

昔はカンマ区切りだったな

>>83
ヌル区切りにすりゃ良くね?

区切りなら0x1C-0x1Fを使えばいいじゃない
せっかくASCIIが現役で生き残ってるんだから有効に使わないと

>>82
HTMLをデータとして持つ場合はHTMLで使わない文字列で区切らないと
区切り位置がバグる可能性があるでしょ
そう考えると最も単純に区切れる文字列は<>になる

テキストエディター　ってかキーボードから打ち込めない文字を使うのは嫌だな
まぁDATを直接編集する事なんてそうあるもんじゃないけど

TSVで良いと思うんだけどねえ

２ちゃんのdatに使われてる制御文字はLFだけだから
1byte文字で全く使われてない領域が32文字分あるんだよね
勿体無いというか無駄というか

過去ログだって
専ブラで取得したらログとして残る
いままでの専ブラで累積したログの変換にも
おまえら対応しろよ

>>90
はい　頑張ります

perl本体としては処理が軽くなるのかしら？
そしてperl5.10移行は未だ先なのかしら？

Rock54系は、別に変わりはないと思う。。。＠現状euc-jp→Shift_JISしている(´･ω･`)

多分一番のネックは携帯系かしら？

ほいだら、人大杉のときは、
read.htmlをデフォルトで動くようにしちゃってくださいー。

>>92
Rock54は全部UTF-8のまま扱えるから負荷がさがるんでねえか？

目的を明確にできないかな。
どういう板、どういうスレ、どういう場合に必要とか。

そういう話の進め方を意図してないのか
あるいは既に暗黙の了解があるのかも分からないけど。

スレタイはsjis。

つーかなんでひろゆきってなんで運営に関わる事2ch上で言うけど
当然しかるべき人にはメールで伝えて、2chに書き込むのは告知のためだよな？

日本語で

×つーかなんでひろゆきってなんで運営に関わる事2ch上で言うけど
○つーかひろゆきってなんで運営に関わる事2ch上で言うけど

最初は
つーかなんでひろゆきってなんで運営に関わる事2ch上で言うの？
って書いてたけど
「2chの事を2ch上で言うのに理由なんて無いだろ」って言われるのが目に見えてたからやめた

つーかひろゆきって運営に関わる事2ch上で言うけど
当然しかるべき人にはメールで伝えて、2chに書き込むのは告知のためだよな？

>>1
早く金払えよ犯罪者タラコ

>>4
read.jsをSJISに対応させた方が早かったりしないの？

>>92
perlのEncodeモジュールや、utf8フラグのあたりはなかなか難解。

理解できれば便利、でも理解できないと原因不明の文字化けに一生苦しむという諸刃の剣。

そんな俺は、スクリプトは全部utf8で書いてuse utf8;、でもってbinmodeで入出力の文字コードを指定、これラクチン。
とととところがどっこい、

入力sjis→変換→Perl内utf8→変換→出力sjis

という風に、無駄に変換がおこなわれてCPU時間食いまくりでｵﾜﾀ

>>101
元々SJISで処理してますが何か？
IE6の時だけ不具合があるからUTF-8で渡してる。

あそっか>>4が目的か。
事務屋と技術屋は出発点がまるで違うよな・・

俺はこれ以上異議を唱える根拠も対案も無いから逃げるけど・・・

>>103
IEのバグならMSに頼めば解決じゃないの？

告知というより、自分でやりたくないだけじゃｗ

>>105
いや、すでに不具合を解消したニューバージョンが出ているので。
いろいろな事情で6から7に移行しない人が多いのだよ。

ここで「2chをIEで見る時はIE7を推奨します。IE6は保証外です」って言ってみたらどうなるか興味あるな

なんだかんだで専用ブラウザ・外部ツールが一気に使えなくなって不便になるだけの悪寒
ほとんどのブラウザ・ツールが対応し終えた1年後にはIE7もかなり普及していたりして
何のための改変だったのかと思うことだろう

>>107
なら２ちゃんTOPに>>108で解決な気がする

>>72-73

>>93

ということで

datをUTF8にする？どうだろ？議論は継続？

旧型機器の専ブラが使えなくなるのはキビしいので、できればSJISのままで
お願いしたいな。

>>111
とりあえず人大杉時にread.html切り替えしてもいいってお触れが出たので
一段落でないかい

元々裏でコソコソやらずになんでもオープンにっていう主義じゃないか
rootさんにしても何かやる時は大抵、スレに書き込みとして残すし

本来なら、管理人って立場なんだから勝手にいろいろ弄くって
事後報告とか、関係者とメルなりなんなりで話しつけて
いろいろやっちゃってもいいんだろうけど、そうじゃないところがｲｲ

まあ、ひろゆきの場合はただ単に自分で全部考えるのがめんどくさいという線も捨てがたいがｗ

２ちゃんねるの場合、ひろゆきがこーゆうのやりたいって公開の場で言えば、
そのやりたいことを実現できる人間が集まってくるからじゃね？

というか、過去に勝手に弄って問題起こしたからでしょ。
事後報告だったよ、あれも。

まーオープンでっていうのもあるけどね。

スピナッチ。スピナッチ。

日本語でおｋ
ttp://newsplus.jp/~mcqueen/cgi-bin/mnewsplus/img/1165135528/396.jpg

http://qb5.2ch.net/test/read.cgi/operate/1200061619/909-913
ううむ

アッー！

専ブラすぐ対応できるのかなー
(過去ログ含む)

ほうこくれんらくそうだんかー

>>117 >>93 のを受けて人大杉時に read.html に振るようにしましたが，
tmp7 についてはどうしますかね？

>>25
ここまでバカだとは思わなかったよ。

どうせ変えるならP2P掲示板でも作ってみろ

tmp7って特殊な事情でもあるんですか？

あそこは吹き溜まりだからなぁ

>>126
2ch特化型サーバ・ロケーション構築作戦 Part27
http://qb5.2ch.net/test/read.cgi/operate/1200061619/909-

それより2ch総BE化して閲覧は出来るけど書き込みはBEにしたほうが良いって俺意見
無駄な書き込みが減る
削除管理がしやすい

旧専ブラは切り捨てですかそうですか

>>123
ボボン連発な訳だが‥関係あるのかな。
http://qb5.2ch.net/test/read.cgi/operate/1206573688/367-

>>126 個人的にはよくわからないですが，詳しい説明は FOX さんにおながいしますということで......

>>131 うむ......旧 banana は全廃になったので mod_rewrite の罠は解消したと思ったんですが，
science6 と academy6 にはまだ残ってたんですかね......
いったん .htaccess を元に戻します......

となると，mod_rewrite の設定は全鯖配布用 .htaccess じゃなくて，
現在人大杉の鯖で個別に行った方が良さそうですね．
今人大杉の鯖ってどれですかね？

janeは改造が大掛かりになっちゃうなぁ
Sjisに変換表示したら意味ないし

T-banana3206 (T-Banana64) science6/academy6/society6

２ちゃんねるの転送量
http://server.maido3.com/pie/

>>133
乙です、解決した模様。

さっさとUTF8にしろ。

　　　　ﾊ,,ﾊ
　　　（ ﾟωﾟ )
　　　i^∩∩^i　　お断りします
　　　ヽ_ﾉ ヽﾉ
　　　　/ .y　　）　
　　　 /ｰ(ー<　　　
　　 ./:::/ ヽ:::ヽ　
　　 i:::〈　　 ヽ::::)　
　　 ヽ:::)　　　ﾚ'

面倒くさいから見切り発車で導入だな

ﾐ(ﾟθﾟ)彡
http://moepic2.dip.jp/gazo/detail/files/detail27880.jpg

hobby10 と mamono に read.html に振る設定入れますた．
他に人大杉の鯖ありますたかね？

ひろゆき天皇の発言は絶対・・・か

tmp7は……要らんな

ひろゆきかわいいよひろゆき

ありがとうございます＠mamono

専ブラの対応としては、仮にUTF-8に変更するとして、
気になるのは移行方法かな？
過去ログも含めて全部一気にUTR-8に変更？
それとも、新たに立てたスレッドからUTF-8になるとか。

＞新たに立てたスレッドから
になると思いますよ
文字コードの判定はBOMつけるってのもあるけど
UTF-8としてはイレギュラーなんだよね
だから初めの一行を読み込んで判断すればいいと思う

つー事は最初はShift_JISのスレとUTF-8のスレが混在する訳か

>148
文字コードの判定が必要になるってのは良いのですが、
1000レスに到達していないスレッドまでUTF-8に変換した場合
ほとんどの専ブラはバイト数であぼーんの有無を判断しているハズなので
取得し直しになりますよね。
「新たに立てたスレッドから」であるなら、その心配はないですが
read.cgi的には二種類の振る舞いが必要になるわけですよね？
そう考えると全部一気に変換しちゃうのかなぁと想像ました。

単発質問ｽﾚという認識でよろしいですか？

かちゅ〜しゃは独自ログだから関係ないよね？

>>142
etc7

>>153 etc7 にも read.html に振る設定入れますた．

おお、おつです

>>1
乙。

>ひろゆき ★

>beポイント:1017889
>登録日:2004-11-16
>紹介文
>AA等のアイコンを作っていて、beのプロフィールで使ってもいいという人がいましたら、
>ご連絡くださいー。

俺beやってないから意味が分からなかったけど
ひろゆきのアイコンにAAを追加したいと判断したお

どんなAAキボン？

それいつの話だよ

どうせ専ブラもすべて書き換えになるのだから
.datの拡張子を変更したらいいんじゃないの？
古い専ブラが知らずに読んでクラッシュするってことも無くなるし。

datはUTFにしたらログ大きくなる

まさか
ここが原因じゃないよね？
まさかね

鴨試練

間違えて落としちゃううんえいかわいいよ

設定入れたのは一部の鯖だけだからこことは関係ないのでは

全鯖に設定入れてないので関係はしないと思う

ひろゆき「またやっちゃいました」

文字コードを変えるとしたら、
サーバ移転ごととかそんな感じすかね。

ｷｬｰ

きたわー

やっぱりやるのorz

やるのか・・・

いろいろ書き変えなきゃだから面倒なんだよなー

クライアント殺しですな

転送量もうｐ

>>167
まずはvipで実験とか無いの？

まずはvipで実験

UTF-8板を作ればいいじゃない

じゃあ、それでー

ったく、どこもかしこもAjaxだな・・・

勝手にどうぞ

>>167
削除のスクリプト
復帰のスクリプト
bbs.cgi
read.cgi
offlaw.cgi
f22
バーボン

すべて自分で直すのならやってもいいよ

トリップは変えないでね

>>180
datの文字コード変えても、F22とかバーボンには影響出ないんでないかい？

>>182
F22はキャップかどうかを区別してdat落ちされる機能があったような
バーボンは関係無かったかも

Firefoxに目覚めたりUnicodeに目覚めたりひろゆきも大変だな
今度は鯖を全部lighttpdにしろとか言い出したりして

>>184
OSをLinuxにしろというのが先な気ガス

>>184
現状に満足してなにもしないひろゆきなんてひろゆきじゃない

トリップはどうすんのー？

http://qb5.2ch.net/operate/kako/1101/11010/1101003269.html

172 ：ひろゆき＠どうやら管理人 ★ [] ：04/11/21 16:00:50 ID:???
トリップに全角を使うのは間違いですよ。うむうむ。

この際だからトリップも変えたらー
もう８完程度は数ヶ月で出るレベルだろ

「その理屈はおかしい」
　　　　 ,. -──- ､
　　　 ／　　 /⌒ i'⌒iヽ､
　　 /　　 ,.-'ゝ__,.･･_ノ-､ヽ
　　 i ‐'''ﾅ''ｰ--　●　=''''''ﾘ　 　 　　_,....:-‐‐‐-.､
　　l -‐i''''〜ﾆ-‐,.... !....、ｰ`ﾅ　 　 　 `r'=､-､､:::::::ヽr_
　　 !.　t´ r''"´､_,::、::::} ノ`　　　　 ,.i'・　,!_`,!::::::::::::ヽ
　　　ゝゝ､,,ﾆ=====ﾆ／r'⌒;　　　rｰ`ｰ'　,! ﾘ::::::::::::ﾉ
　　　 i`''''ｙ--- (,iﾃ‐,'i〜´ゝ''´　　　￣￣ヽ` :::::::::::ノ
　　　 |　　'、,............, i }'´　　　　　　　､ｰ_',,...`::::ｨ'
　●､_!,ヽ-r⌒i-､ノ-''‐､　　　　ゝ`ｰt---''ヽ'''''''|`ーt-'つ
　　　 (　　`ｰｲ　 ﾞi　　丿　　　;'-,' ,ノｰ''''{`' 　 　!ﾞヽﾉ　,ヽ,
　　　　`ー--' --'｀￣ 　 　 　 ｀ｰ't,´｀ヽ;;;､,,,,,,___,)　ヽ'-ﾞ'"
　　　　　　　　　　　　　　　　　　　(`ー':;;;;;;;;;;;;;;;ﾉ
　　　　　　　　　　　　　　　　　　　 ｀`''''''｀`'''''´

>>185
それはかなりの確率でないと思うよ

Unicodeは？

これは・・・

UTF-16じゃなくてUTF-8にしたのは理由があるの？
UTF-8の方が優れてるのか？

>>180
丁稚どんが、なかまに入りたそうにこちらを見ています。

utf-16だと正義の報告スレや芋掘りスレがすぐ500KB行くな

http://money6.2ch.net/
も特殊事情すか？

>>197
ただ単に忘れられているだけでしょ

うひょ

1回read.cgi全停止して負荷のテストしようよ。
労力をかけてread.jsを広める価値があるか見極めよう。

>>194
優れている。ASCII互換。

utf-8に移行したほうがいいよ。
eucとかsjisを使う時代じゃねえしな
ajaxでクライアントサイドでもっとおもしろいことをやってほしいな
質問。開発には名無しで参加できないの？

開発っていうのかな。これ。
どっちかと言うとメンテナンスに近いような。

Ajaxの作成なら面白ければ採用されるかもね。

何だか>>202からプロフェッショナルなニオイがします　ｸﾝｸﾝ

素人騙すのは簡単なんだな

プロフェッショナルな方なら優れた点だけじゃなくて
互換性や移行することで起こるデメリットもちゃんと考えてもらいたいものですね

>>200
同意。
転送サイズが増えることで、当然圧縮負荷が増えるわけだから
本当にメリットがあるのか判断すべきだよね。

目先のシステム負荷だけじゃなく
翻訳機能を付ける(スポンサーが増えるよ？)
とか、展望があるなら賛成だけはさせて貰います。

2ちゃんねるなんて意味不明の文字列が多いのに
翻訳したらどうなるのかな？

ひねくれてUTF-16にしようぜ

学問、政治系などはOK。
それなりに意味はあると思う。

どうしても「あやっくす」と読んでしまいます（照）>ajax

そうか文系は効果ありそうだね。
面白そうではあるけど。
海外ドメイン規制が行われている昨今、海外進出？
それとも在日ターゲットかしら、、、

BBS_UNICODE=changeのおかげでシリア語ブラクラ投稿や変な文字使ったAAが
投稿できなかった板も再びそれらで汚染されていくのかね

>>214
別にシリア文字は個別に表示できないようにすればいいだけ

UTF-8 にする、ということは、
いわゆるCJKじゃないやつも書けるわけで(何もチェックしないなら)、

とここまで書いて思ったのは、
SETTING.TXT でやるのが、専用ブラウザ的にも bbs.cgi 的にも
いいのかもしんないですね。

BBS_UNICODE=utf-8 とか。

>>216
普通にHTMLヘッダでcharset=UTF-8 じゃダメなの？

>>215
自分は専用ブラウザであぼーんするからいいけど
IEでread.html使っててひっかかるのが嫌な場合
フォント削除するしか対策法ないよね
2ch側ではじいてくれるならいいが

必要性って言うなら
わざわざ日本語の文字に限定する必要性もないし

>>217
いや、内部処理的にって話で。

今自分の環境が SJIS 環境なのか UTF-8 環境なのか、
cgi の内部でわかるといいっていう話です。

いろんな方法が考えられるんでしょうけど、
SETTING.TXT に入れるというのは、そのうちの一つということで。

2chの場合はメリットよりデメリットの方が多いのではないか？
専ブラ対応とか以前に黒山羊とか。日本の携帯はしばらく(短くても4〜5年？)はSJISメインだし。
SJISの仕様のいい加減さもそれに合わせた実装の厄介さも知ってるけど、今は動きにくいよ。
特に携帯がなぁ…。

そのへんどうなのよ？

全然関係ないんだがそういえば最近メリットってシャンプーみかけなくなったな

>>216>>221
Shift_JISのままにしておく板と
UTF-8にする板が混在するってことですか？

YahooがこないだEUC-JPからUTF-8に変わったんでしたっけ。
Wikipediaは最初からUTF-8か。

PCのほうはUTF-8でも今や割と大丈夫かなと。
何せ日本のPCの6割ぐらいは、スタートページがYahooらしいんで。

携帯サイトとかはどうなんだろう。
そのままUTF-8出して大丈夫なんだっけか。

>>224
そうなるかどうかよくわからないけど、
少なくともbbs.cgiとかは両方対応にしておきたい気がしますね。
直感だけですけど。

>>223
メリットの弱酸性は地肌に悪いらしいぞ
頭皮が心配な方は要注意

>>225
http://miniturbo.org/2006/12/29/034842
最近のは対応してるみたいですね

うーむ・・・確かに変更にはかなりの手間がかかることが予想されるが・・・
今後を見据えると、sjisもそのうち廃れるかなぁ

だが問題は、utf8に変えて5年ぐらいたった後にUnicodeの次の規格とかが現れはしないか、ということだ

そのまえに２ちゃんが・・・ｗ

>>229
UTF-8は単なる「エンコーディング方式」であって、
Unicodeの規格は常にバージョンアップしているんではないかなと。

つい先だっても、Unicode 5.1が出たばっかり。
確か1000文字以上追加されたんじゃなかったっけか。

>>229
>だが問題は、utf8に変えて5年ぐらいたった後にUnicodeの次の規格とかが現れはしないか、ということだ

現れない。万が一現れたところで絶対に普及しない。

>>225
私の自宅サーバはUTF-8仕様です。
携帯からもアクセスしてます。

あと直感的にUTF-8にする場合、
これに注意、ってかんじですかね。

http://www.wdic.org/w/WDIC/Unicode%20Directory%20Traversal

auの場合はGWでtext/から始まるMIMEは自動的にSJISに変換するよ

これはタラコの罠だぞ

>>229
Unicodeが改定されたところで
符号化方式であるUTF-8には関係ない

http://portable.blog.ocn.ne.jp/t/typecast/168237/172389/show_image/tate.jpg?src=http://suzukiq.blog.ocn.ne.jp/photos/uncategorized/tate.jpg

まずは文字集合と符号化方式の違いからお勉強しようか

datをxml化するのもひとつの手だと思う。たた>>86の指摘もあるので、やるんなら

<?xml version='1.0' encoding='UTF-8'?>
<2ch:dat>
<2ch:post time="">
　<2ch:name value="" id="" be="" />
<2ch:msg>ほげ</2ch:msg>
</2ch:post>
<2ch:post time="">
　<2ch:name value="" id="" be="" />
<2ch:msg>あげ</2ch:msg>
</2ch:post>
</2ch:dat>

みたいな形でしょうね・・・。

今はdatにレスを追加する時
動け動けウゴウゴ２ちゃんねる<>sage<>2008/04/14(月) 02:21:40 ID:uJeEyM4Q0<> まずは文字集合と符号化方式の違いからお勉強しようか <>
を単純に追加すれば良かったが、xmlならそうはいかないんだよね
単純に追加するのとxmlを再構築するのにどれくらい処理時間/処理能力に差があるのかしらん

XML化のメリット？

・beのようなdatに書く性格の機能追加対応が容易
・クライアント側にパースレンダリングを投げられるため、当該部分のストリーム転送だけで済むので負荷が減る
・ディスク追記のタイミングを非同期に出来る（ライブスレッドは基本オンメモリで）

XML文書にすると、<>区切りよりはるかにサイズがでかくなってしまうよ（´･ω･`）。
だけど、一度に読み込んでメモリ上にDOM展開できるから、いろんな抽出や
編集処理はし易くなるね。

XML採用の最大のデメリットはメモリとディスク容量の問題（UTF8化と含めて約3倍ぐらい）ですね。
とはいえ、UTF8化だけでも512KBリミッターが確実に問題になるので、そのへんをひろゆきがどうしたいか次第でしょうね。

ちなみにUTF8化は2chが抱える2つの問題の解消も図れます。

・read.js使用が容易になる
・UTF-8系がデフォであるトラックバックの文字化け解消

>>244 上の方で書いたことではあるんですが，少なくとも現状では
read.js 利用上 Shift JIS が問題になっているということはほとんどないですし，
逆に UTF-8 にすれば read.js の抱える問題が目に見えて改善されるということもないと思います
（read.js の抱える問題はむしろ別のところにある，と >>36）．

まぁ，read.js 云々とは別の観点（国際化とか）からは検討の価値はあるかも，
というところだとは思いますが．

新鯖追加のついでに外人用鯖、板でも作ったりする？ｗ
新規の外人なら専ﾌﾞﾗ使わないし。

GLの英語化とか必要だろうし、削除とか大変そうだけど。。

>>240
名前空間接頭辞の最初の文字に数字は使えません

>>244
トラックバックってもうないだろ・・・

ｔ

誤爆申し訳ない。
ところで誤爆ついでに質問なのだが、トリップなどは正常に今までどおり機能するの？
どこかでトリップが云々って聞いたんですがー

昔のbe板みたいに
トリップの互換性はなくなるねぇ

酉は酉屋さんで♪
tu-kaもう既に改定案はまとまっていたりしちゃったりしてたんだっけ？

>>252
まとまってないというか、人大杉解除＆鯖新設で急ぐ必要が無くなって
しまったので停滞中と言うか。

究極的に >>65が目的ならその内また必要性が湧いてくるのだろうけど。

旧be板みたいに別のサーバに別のbbs.cgiを入れて、
テスト鯖作ればいいんじゃないですか。
snow.2ch.netみたいな実験サーバ扱いで。

実験板で最低限の動作確認したら、
VIPなりν速なり狼なりを入れればいいんだし。
それで問題なければ、サーバリフレッシュ工事でどんどん移転していくと。

そういや find.2ch.net ってEUCだったっけ？

be.2ch.netもEUCだったような・・・？

/dat/1234567890.dat　←従来のdat
/utf/1234567890.utf　←UTF-8なdat
って感じでUTF-8なdatは別フォルダに置くのもありかもね

Unicode使うと海外とかからのロボット爆撃が激しくなるなんてことないよね…？
EUC-JPやUTF-8は海外でも分かりやすい規格だけど
Shift_JISって日本のみで使われてるんだよね…？

いっちょ鯖負荷テストの精鋭、VIPPERにテストをお願いしてみては

>>257
dat容量が単純に倍（orそれ以上）になるのはHDD容量的にきつくないか？

書き込みコストも倍(最大)だぜ

SJIS以外のコードにすると携帯の絵文字は全滅だよね
ってか、２ちゃんの書き込みなんて99%はSJISの文字
（正確を期すとJIS X 0201と0208の文字集合）
なんだから利用者的にはUTF-8になるメリットが少なくね？

動機が動機ですからそういう話ではないかと

そもそも２ｃｈはぴろゆきの個人の掲示板なので、利用者のメリットとかあんまどうでもいいのです。。。

>>260
書き込みがあるたびに、shift jisの.datとutf-8の.utfの両方を作るんじゃなくて、
.utfしか作らないんだけど、別フォルダにしておくと言いたかったのです。
subject.txtもutf-8版はsubject.utfにすれば、subject.txtや/datは
エンコードが変更しましたと書かれている924.datだけ置いてutfに誘導できるから。

ところで、提案者の示した目的が「負荷軽減」だけど、( >>4 )
負荷軽減はUTF-8化では無理、というかむしろマイナスという結論。
それを受けて提案者はどう考えてるのか。

>>265ぬるぽど・・・とすると例えば、新しい構成のdatは
/operate/utf/1207973589.dat
とかなってて普通にutf8版datが入ってて、mod_rewriteで
RewriteRule ^/operate/dat/([0-9]+)\.dat$ /operate/dat/pleaseuseutf8.dat
とかしておいて
/operate/dat/pleaseuseutf8.dat
にはsjisで
utf8使え<>utf8使え<>utf8使え<>utf8版を使えや(ﾟДﾟ)ｺﾞﾙｧ!!<>utf8版を使えや(ﾟДﾟ)ｺﾞﾙｧ!!
みたいなのが一行だけ入ってる、とｗ

>>1は
shift_jisとUTF-8の(具体的な)コスト比較をやってけれ！
って事なのかな？

２ちゃんねるブラウザ「JaneView」 Part54
http://pc11.2ch.net/test/read.cgi/win/1202424797/840
840 名前：View ◆AcQTmXmylo [sage] 投稿日：2008/04/15(火) 05:19:13 ID:zEhpNNaT
ｶﾞｸﾌﾞﾙ
長い目で見たらメリットはあるだろうけど、
ネイティブでやろうとするとDoeのレス表示の部分の修正だけでもえらいことに。

表示だけでなく書き込みやNGワードなどユニコードに対応したUIの必要性を考えると・・・
ユニコードのコンポーネントはTntWareがTMS Unicodeになってシェア化されてしまってたり。
RichEdit2.0を使うのもいろいろ問題有り。

JaneViewに関しては自分がTntWareの最終版を持ってるのでどうにでもなるけど、
OJはいよいよまずいかな。。。

>>262
絵文字はむしろ排除の方向で

サーバリソースのゆとりがあるなら、の話ですが、utf8＞sjis変換サービスってのもありかも。

sjisで要求→1234567890.utfしかない→read.cgiは別ホストで動いている変換サービスにutf-datを投げる
→変換サービスはdatをsjisに変換→変換サービスは要求したホストに直接datを返す。

去年の後半あたりから「非同期」が一種のキーワードになっています。
これはその考えを反映させたもの。

人大杉対策としてread.cgiはc.2ch.netなしくみで動かすというのもありかも。

現在のc.2ch.netのphpスクリプトを元に
ブラウザで表示したときの見た目がread.cgiと同等なものを作って
それをpc.2ch.netみたいな名前を付けたサーバで動かして
bbs.cgiが入っている鯖のread.cgiは全部止める変わりにそっち使ってという感じで。

キャッシュ機能とかも持たせれば効率いいソリューションになりそうだね

文字コードは根っこが深いからテストサーバー作って
コツコツとつついていくのが良いと思う。
utf8.2ch.net

pc.2ch.net は予約済(現在は過去ログ鯖)
非公式なら既に存在する

いきなり現行の板に適用したりしたら
たぶん専ブラの中の人が大変なことに…

単にIE6でアクセスされたら専ブラかIE7かFirefoxかSafariかOpera使えって返せば良い予感。文字コードだけが問題じゃないようだし。

MEサポートしろ

>>278
PC買い換えるかUbuntu使え

>>277
(・∀・)ｿﾚﾀﾞ!!

なんで西村はこんなことを思い付いたの？

林檎機開発環境だと負担軽減するのかなぁ♪

林檎はDarwinだからなぁ。LinuxもLinuxだし。FreeBSD向け開発にはFreeBSDが一番な気ガス。

>>281
日本以外のマルチバイトな文字に対応したいんだろうな。

ひろゆき)人大杉が出ると、閲覧できる人が減って広告収入に影響がでるから困る。

ひろゆき)鯖のセッティングのことはよくわからないけど、人大杉が出るってことはサーバーリソースを使いすぎってことだろう。

ひろゆき)サーバーリソースを使わないread.jsを標準にすればよくね？

SunOs)read.jsだとIE6で挙動不審だからデフォルトで採用できないっす。

ひろゆき)なるほど。(文字コードがUTF8なら問題解決ってことだな)

///////////////////スレ立て////////////////////////////////

ひろゆき)datをUTF8にするのはどうだろう。 >>1

技術屋さん達)ざわざわ。問題点はあーだこーだ。

ひろゆき)サーバリソースを使わないモデルにできれば、人大杉が無くなるよね。(真意)>>65

SunOs)read.jsを標準で使わない理由は文字コードの問題じゃないってばよ。>>36,72

SunOs)ちなみに人大杉の時にread.jsを効かなくしてるのは、鯖屋のFOXの指示ですわ。>>73

ひろゆき)じゃあ人大杉のときはread.jsを標準で使うようにしてください。(目的達成)>>93

SunOs)了解っす。>>123

技術屋さん達)ざわざわ。UTF8にしたらあんなことやこんなことを。

ひろゆき)文字コードを変えるとしたら、サーバ移転ごととかそんな感じすかね。(適当な思いつき)>>167

技術屋さん達)ざわざわ。あーだこーだ。

root)管理人がやれって言うならやるけどさ。技術屋の威信をかけて。>>216

専ブラ作者)思いつきで仕様変えるのかよ('A`)ﾏﾝﾄﾞｸｾ>>269

まとめ乙

苦労してまでUTF-8にするメリットが見つかりませんが・・・
ちなみにUnicodeならJIS2004も扱えたりするんですけど、専ブラも当然対応するんですよね？

ていうか専ブラの対応なんてそんなに大変じゃないだろ
なんて思う俺はOSX

しばらく実験用の鯖だけで動かしていれば
その間にユーザーがつつくから対応してくれるかもしれない。
更新が止まって久しいソフトは淘汰されそうな気がする。

スレ立て前の経緯を今知ったぞ

RLO（Right-to-Left Override）の問題は大丈夫っすか？
RLO埋め込んだアドレスでjpgファイルに見せかけたexeファイルをうｐするとか・・・
http://ura2ch/hogehoggpj.exe
↓
http://ura2ch/hogehogexe.jpg
とか

あったなぁそんなの

>>291
確かに。
>>234 と同様に Unicode の問題ですね。

>>291
それ、今でも文字参照で可能。ただ、既にブラウザ・OS側で対策されてるからあまり問題ない。
98? ME? んなサポート切られたOSなんて知らね。
2000? M$神はあなたを見放した。

ちなみに参考
http://pc11.2ch.net/test/read.cgi/software/1206928829/116

今の2chでも＆rlo;使えるしなあ
&rlo;あなるえ使;olr＆もでhc2の今

> &rlo;あなる

まで読んだ。

リンクの偽装に使えるのかしら。
いずれにしてもリンク先になにがあるかは2chが関知するところではないのだけど。

地デジでも採用されてる、ARIB 8単位符号(STD−B24)にしようよ。

JIS 8単位符号ベースだから、多国語対応もOK。
DRCSをつかってユーザ定義の絵文字を混ぜられる。
漢字は2 bytes、英数・平仮名・片仮名は1 byte。要エスケープシーケンス。
更にC0, C1制御符号を使って、書式も付けられる。

特殊記号作品スレ5
http://love6.2ch.net/test/read.cgi/aasaloon/1187147919/

シリアスに考えないで、研究目的で実験サーバ立てればいいじゃない

じゃあ頼んだぞ

>>22
妙に感動した27歳フリーターの夕暮れ

サーバはタダじゃない

utf化でどの程度、データーの容量増えるか実測してみた
tmp7のdownload板の全datファイルをダウソして実験

元のdat  -- 38MB
UTF8化dat --- 46MB (1.2倍)


次に、gzipでこれらを圧縮してみた
UTF8化してもほぼ同じ容量になる

圧縮後の元のdat -- 12MB
圧縮後のUTF8化dat -- 13MB (1.1倍)

メジャーなブラウザーは通信時データーをgzipで圧縮できるので
通信帯域的にはUTF8であろうがなかろうが同じ程度になると思う。


次に、datをUTF8化して、更に、XML化してみた
↓例えばこのスレのdatをXML化
ttp://www7.axfc.net/uploader/93/so/File_5414.xml.html
XML化しても圧縮するとやはり元のdatと同程度のサイズだった。

XML化後のdat -- 54MB (元のdatの1.4倍)
圧縮後のxml化dat -- 14MB (圧縮後のdatの1.2倍)


datをUTF8化して、ついでにXML化もしてはどうかな？

今read.cgiにアクセスしてくるようなビュワーを使わない「普通の」閲覧者にも
XML化datとスタイルシートを与えて閲覧者のブラウザー側で見栄えを処理してもらえば
perlとかをガリガリ動かすより負荷も減るかと思う。

閲覧者に広告をフィルタリングされやすくなっちゃうだろうけどｗ
逆に見てもらいたい広告を挿入しやすくもなると思う。

>>305
必要に迫られない面倒くさいことはやらない（基本）

UTF-8にしてXMLにしてgzip圧縮して
それって逆に負荷を増やしているんじゃないのか

XMLはコンテンツのみで
見栄えはXSLTでいいんじゃね

SJISからUTF-8にしたり
datをXMLに変換するのは負荷になるだろうね。
そこで最初からUTF-8、最初からXMLであれば話は別かと。

CPUの負荷と、回線の転送料の負荷と、ファイルの容量が混ざってないか

>>308
IE6のXSLTは酷いから使うのはお勧めしないよ。

そんなことより、顔文字を共通化して文字コードを割り振って、国際標準にしろよw

AA職人に欲しい記号をリストアップして貰おうか

逆半角スラッシュ？

今のままでいいよ

ユニコードってバックスラッシュと円記号って違うコード？
エンコードによって揺れる？

2ch DAT落ちスレ ミラー変換機の管理人さんが0chスクリプトを
UTF-8化したものを配布（http://mirror.s151.xrea.com/0ch_utf8/）していて、
サンプル（http://mirror.s151.xrea.com/2ch/0chu/utf8/）もあるので、
どんな感じになるのかはここで実験できるかもしれない。

>>315
違うに決まってんでしょ

>>316
サンプルの惨状にﾜﾛｽ

多言語なんて荒れるんじゃない？

>>318
荒れてるんじゃなくて、台湾版ニコニコ動画の掲示板のログを持ってきた
って管理人さんが書いてた。
考えてみたら、http://tw.bbs.nicovideo.jp/user/ の方を紹介すべきだったかな。
ニコニコ動画が運営しているUTF-8エンコードのサポート掲示板。

>>315
違うコードだけど、Windowsではどちらも￥に見える

>>321
たぶんそれはアプリに問題が

暗黙の了解でバックスラッシュは特殊な仕様になってる。
詳しくは調べてね

マイクロソフトの変換法では、日本の円記号はUnicodeのバックスラッシュ（U+005C）に変換される。
そして、日本語用のフォントではバックスラッシュ（U+005C）を円記号として表示してしまうのである。
賛否両論の対応ではあったが、旧来のソフトウェアを捨て去ることなくUnicodeを利用できる現実的な方法として広く使われている。

なにこれー

Windows のフォントにパッチを当てて、円記号を無理やりバックスラッシュにしたり
してた人も居たはず…

Beかなんかで、トリップの文字化けがあったよね。関係あるのかな。
ログだけじゃなく、全部ひっくるめて統一したい、とか？

エンコーディングにSJISを使うかUTF-8を使うか、ということより
最終的にどんなフォントが使われるかということだな、問題は。

フォントにな

すくなくともバックスラッシュを多用する板なんて限られてくるんだし（ム板とか）
そいつらがBSを表示できれば問題ない

AA職人もバックスラッシュは欲しがるんじゃないか？
ってもMS標準のUnicodeフォントで統一されるなら支障無いと思うけど

バックスラッシュは是非欲しい

＼　←？

>>332
\

>>328

以下スレチ
>>326
(旧 BE板と) BE プロフィール画面でのトリップ非互換問題は以下の通り。

・BE の内部処理が EUC-JP で、なおかつ本来トリップとしては不正な多バイトコード
　もしくはいわゆる半角カタカナを使用しているため。
・プロフィール画面の方では、各処理系で特殊用途として用いられる文字のエスケープ
　処理が板のトリップでの処理と違うため(「"、'、[、]、\」なんかが該当)。

すべての原因は何処かのスレで自身が発言してた、ひ（ｒが文字コード問題に弱いため。

http://etc7.2ch.net/test/read.cgi/be/1184835944/225
5：トリップが化けないようにして

いまいち文字コード周りに弱いおいらです。。。
DBの文字コードを変えるとさらに文字化けを誘発しそうなんですよね。。

>>328

UTF-8を理解していない人が
スレ参加とか。。アフォかと。。。

もはや釣堀ｗ

専ブラ作者には負担かけるわけだよねー
●で儲けさせてもらったくせにその仕打ちはどうかと

>>340
、、、。

＼(^O^)／ドンマーイ

世界はUTF-8

俺のサイトもSjisからUTF8にしようと思ったけど面倒だからやめた。
PHP使ってるから初めからほうしとけば良かった。

>>340
エンコ指定なんてふつう外出しにしてるだろ。大した手間じゃないよ。

讃岐は●非対応、いや未対応。
完全ボラだからなー。

>>340
>>269

340じゃなくて345だった

つまりJaneViewの設計が糞だってことか

えんこーでぃんぐだけじゃなくてゆーあいにひょうじしたりあぼーんでのしょりがふくざつになるのに
お前はアホか。

ID:E+evngot0
ここはあなたみたいな無知な方が来る所じゃありませんよ、と

内部処理がSjisの専ブラの方が多いだろ

WinアプリでWin95系をサポートしてるなら内部処理Unicodeにするのは困難

いまさら95/98/MEを使っている奴なんて…いないだろう？
いないよね？いないと言ってくれよ！

ここにいる！

つまりエンコの変更に対応できないようなソフトを作っておいて
自前のコントロールじゃないからどうとか開発環境の内部処理が
どうとかＯＳがどうとか言い訳がましいことを言うなと

>>353
でも不可能じゃ無いし、実際95でも使えるアプリでUnicode対応してるのも
ある。

ちょっと検索すれば判る程度の話だし。

不可能じゃなければ簡単なわけじゃない。

>>356
やったことがなくてわからない事までろくに知りもせずに言及するな。
>>345のような発言する時点で実際にどんな問題が出てくるか全く把握してないだろ。

ここは2chだし「まずやってみよう！」の精神でいいんじゃないかな？
問題が起きたら後から考えると。

やるんならｱﾌｨ速とかVIPとか小規模に実験してから全板にいれてくれ

2chブラウザ製造機によく使われてるDelphiがUTF(Unicode)に標準で対応してないんだ。
かちゅ、ギコナビ、ホットゾヌ、Jane系は騙し騙しの対応になるか、対応を諦めるかのいずれかになるな。

そもそもひろゆきがUTF8に変更する積極的な理由がなくなったんだから
このままでいいんじゃないのかね。

2ch鯖がSJISに特化した処理結果を返してるからといって
クライアントがSJISを前提にした設計にしちゃっていい理由には
ならんだろ？文字コードが変更されたとき、ユーザーの手間を
最小限に抑えて最低限の表示が出来るような設計にしておかなきゃ
糞だろ？

必レスのガイドラインスレに迷い込んだのかと思った。

専用ブラウザがどうのこうの言ってるけど
おいらのJDには関係ない
ついでにいうとNavi2chでも関係ない
つまりはどうでもいいってこった。

>>362
フリーソフトにどんだけスケーラビリティ求めてんだ。ww
頭悪いの？それとも常識がないの？

2chサーバ側の仕様なんて、これまでも結構変わっているわけで、
専ブラ作者もそれに追従してきている。
（gzip圧縮とか、EUCとか、バーボン回避のウエイト挿入とか）

今回の場合、暫定回避策を作るとすればliveb1.2ch.netみたいのを
ベースに変換Proxyを用意して、未対応の専ブラはそこを経由させる
ような対応もあるだろう。

もちろん「表示不能な文字が出る」「更新が遅延する」等の制限も
あるわけで、それを回避したい作者はUTF-8の本格対応をしてくる
だろう。

ま、実験サーバで様子見ながら進めるのが良いだろうね。

ていうかそもそもUTF-8にするメリットってあんの？
専ブラとかトリップとかデメリットははっきりしてるけど

UTF-8のメリットと言うよりも、SJISのデメリットの方が大きかったり。
SJISのままだとまともに検索処理できなかったりするしなあ。

findがEUCなのもこの辺が理由だろうし。

>>352
んなこたあない

>>368
そりゃ設計が甘いだけであって文字コードの問題じゃないだろ、jk。

こんなことグダグダ言ってる体質だから、お前ら童貞なんだよ

ﾃｨﾝｺねえよばーか

ほうほうｗそれで？




・・・・えっ？

同鯖なんだから、iframeでSJISのテキストひっぱってきて、
JSで整形すればいいジャマイカ
IE6どころかそれ以前でも問題ない

Ajaxにこる必要はないですよ、と。。。

UTF8にすんの？ハングルとか中国語で蹂躙されそうでこわいんですけど

>>375
バカなんだから、黙ってろバカウヨ

半島、大陸からはボボン行きにしちゃえばいいのだろうけど国内からの投稿はなあ

結局決まったのは「人大杉の時はread.js使ってね」だけか？

そんでひろゆき満足してそう

じゃあもう要らないね

↓スレスト

ひろゆきモンハンやろうぜ

そもそも言語とはなんぞやという問題が云々

いつかはやるべきだろうけど、「動いているモノはいじるな」でしょうか。
googlebot対策なんかやるのかな？

sports11もread.jsの設定お願いしますー。

ぴろりん発見

>>384 人大杉時に read.js に振る設定が FOX さんに override されて
「秘密の花園」に飛ばされてしまうのですが，とりあえずやっておきます．

# 再度 override されるようなら，↓あたりの話を FOX さんと詰める必要があるのではないかと......
# http://qb5.2ch.net/test/read.cgi/operate/1208685863/15-n

ぴろり菌発見ｗ

あぼーん

（´・ω・｀）このスレ終わっちゃったの？

>>389
「俺がUTF8化してやるぜ！ utf.2ch.netという名前を付けて鯖よこせ！ 」
みたいなことを言う人が現れなかったので終了しました。

うお乗り遅れた

っつっても俺がやってやるから鯖よこせと言えるだけのパワーは無いけど

実際UTF8化した場合、簡単な設定変更で表示可能なブラウザって
IE以外だと何がありますか？（IEならエンコードは自動認識だったかな）

ウェブブラウザのシェア統計に名前が出るブラウザなら特に設定の変更は無いです

navi2ch はすぐだな

>>392
っていうか、むしろその IE(6) で問題が大有りなんだが… IE7 なら割と平気。

>>394
emacs自体のユニコード処理が微妙だったり無かったり

今時、問題になるようなウェブブラウザはないかと。
（ウェブブラウザが見るのはhtmlだから、もし問題ならread.cgiが
SJISなhtmlを吐くようにすればいい）
対応が大変なのはdatを自分で読んでいる専ブラ。

専用ブラウザの場合、最悪IEコンポーネントを使っているなら
そのままUTF-8で吐き出せば表示されるかな？と思いますが
独自描画だとキツいでしょうねぇ。
内部でSJISにコンバートしてから表示ってことになるかな？

SUBJECT.TXTもUTF-8になるのなら、同じ感じですね。
スレッド一覧表示のところね。
上手く表示出来ない文字とか出るんでしょうねぇ。

SJISのままで行きましょうよ……。

もういいじゃないこのままで

ご時世を考えるとむしろ内部UTF-8な専ブラもあったりするんじゃないかと
思わないでもなかったり。

ところでトリップの話が出てますけど、トリップだけはSJISに変換して
計算すればいいんでない？
あと、トリップの強度を上げる話は、キーはSJIS8バイト以内なら現トリップ、
それよりキーが長ければ次世代トリップというように、互換性をもたせたまま
拡張する手もある。

今こそおいらロビーインターナショナルの復活の時

>>400
トリップの件… 多分この板の過去スレのどこかにソースがあるはずだけど(トリップ
統一スレだっけかな？)、２ちゃんねるの仕様としては、non-ASCII なキャラクタは
トリップコードしては不正なはず。

>>188に

管理人がそう言っていたとしても、
現実使ってる奴がいる以上需要はあるかと。

対応する理由が2ch側には無いのはわかってますけどね。

2NNはUTF-8なんだな

S-JISを通信の世界に出すなと言う20年以上昔の議論の結論が今頃出てきたなw わずかな期間のわずかなリソース節約の為にどれだけのパワーが削がれてきたのか、 そして、正しき状態に戻すためにどれだけのパワーを必要とされるのか、、、南無、、、

正しき状態とかもうね

欠陥の多い間に合わせの文字コードだからな。

>>406
20年以上前は80x40の端末しか存在しなかったから
改行して読みやすくするなどの
読み手のことなど全く考慮する必要がないということですね。

通信の世界で使えと言ってたのはISO-2022-JPなわけだが(今でも日本語メールにその名残がある)
datをISO-2022-JPにしろとでもおっしゃいますか
アホか

>>410
名残もなにも、RFC 1468(ISO-2022-JP)は現役バリバリで obsolete されていないから、
text/plain での日本語環境 mail/netnews じゃ ISO-2022-JP しか使っちゃ駄目。

mailとnetnewsではね
2chにはあまり関係のないお話

そこまで言うならUTF-7でいいよ

むしろUTF-18で

いっそのことUTF-9で

うっとこはJST-9だよっ♪

>>413
全部実在するから始末に負えない

こんなにあるもんなのか

UTF-7
UTF-16 （後述）で表したUnicodeをBase64で変換して表す方式。
ただし、ASCIIのアルファベット範囲等については(ry

UTF-9
8ビット単位の可変長コード（1?5バイト）にエンコードする方式。
ISO-8859-1に対して一部互換である。
しかし、UTF-8が普及しつつあり、それと比べて欠(ry

UTF-18 (エイプリルフールネタだそうで)
Unicode符号位置を単一の18ビットによりエンコードする方式。
UTF-8に対するUTF-16のようなものだが、RFC公開時点のUnicodeで文字が定義されていた(ry

ネタもあるから注意が必要だ
有名どころではハトとか

HTCPCP/1.0とかもなw

実用的なところでは洗濯バサミとかなｗ
家庭内やSOHOぐらいだと意外と使えるぞ。

> 30 名前：止まない雨は名無しさん[sage] 投稿日：2008/04/11(金) 17:52:40 ID:3n18t16j0
> 狐は「もうずっと人大杉」にした。
> 　 ひろゆきは三度、専ブラを使え（で書き込め）なくした。
> 　 　 それを受け、むむむさんは静かにqb5・6を停止した。

ニュース実況＋＋ / ２ちゃん人大杉拡大　行き場を失ったユーザーの荒らし行為が各地で続発★３
ttp://news24.2ch.net/test/read.cgi/liveplus/1207900534/30
　嫌な予感がしてkakikomi.txt確認したら…>‎>1ネタをネタと(ry

よし、文字コード設計からやろう

datの先頭あたりで判別できるようにすればいいんじゃないかな

Shift_JIS：[名無し]さん(bin+cue).rar<>sage<>
UTF-8：[名無し]さん(bin+cue).rar><sage<>

ってみたいに

判別するだけだったら１文字か２文字でいいんじゃない？

できそうなところがないじゃない

UTF-8なDATは、BOM付きUTF-8にすればいい
先頭を見てBOMならUTF-8、さもなくばSJIS

専ブラは差分取得するのでdatの先頭にBOMを付けても役に立たない

ファイルの途中からUTF-8に変えるのかい？

いわゆる BOM 付き UTF-8 は問題児なので反対。RFC 3626 でも基本的に
「使用を禁止すべき」扱いだし。ていうか、HTTP header の Content-Type の
charset で十分だべ。

datファイルは２ちゃんねる専用フォーマットだから自由に設計していいんじゃね？
もちろん標準バリバリでXML化でも良いけど、標準ってのも移り変わるもんだからねぇ。

XMLは無駄にサイズ食うからなぁ。コードの見通しも悪いし。
賢明な選択肢とは思えん。

圧縮とセットならXMLもそれほど容量に影響しないと思う。
同じようなキーワードが並ぶのなら全部符号化されちまう。

XML化は利点が見えない。現状の1行1レコード、<>がフィールドセパレータ、で
困らないと思う。

このスレの主旨？とはまったく異なる視点で…

・read.cgi が吐くものを XML で再定義する
・それに食わせる dat？も XML で再定義する

ってのなら、まだ分からんでもないけど ＞ dat？の XML 化

専ブラ開発者からみたら、メリットはないわな。

これ以上専用ブラウザ作者に迷惑をかけるのはやめてやれよ

> ・read.cgi が吐くものを XML で再定義する

read.cgiの吐くhtmlにスキーマを付けるのには全く独立した話として賛成。

>>430
> いわゆる BOM 付き UTF-8 は問題児なので反対。RFC 3626 でも基本的に
> 「使用を禁止すべき」扱いだし。

RFC 3626 Optimized Link State Routing Protocol (OLSR) って
Unicode 関係なくない？

>>438
RFC 3629

書き込みがちょん切れたorz

RFC3629的には、
datが、HTTPでやりとりされる物だと見るなら、HTTPのContent-Type
ヘッダがあるからBOMは禁止すべきということになるけど、
dat ファイル単体として見ると、エンコーディングを知る方法が
（なんらかの拡張をしない限り）ないから、BOMは禁止されるべきでない。

専ブラがローカルに持ってるdatについて、ファイル名を変えるとか、
専ブラ独自の形式にするとか、外部に情報ファイルを持つとか、
しなきゃいけなくなる。

うぁ… RFC の番号打ち間違えてたか、すまん orz

dat 単体で見たときは云々、ってのはあくまでローカルな環境、ユーザエンドで
ファイル単体として扱うときの話なんで、それは環境・アプリ依存。
２ｃｈ の素の dat のファイルがどうあろうと、それをユーザ・アプリがどう扱おうと
好きにすればいい。

意味的には、したらばの EUC-JP な dat を Winodws な専ブラがローカルに
Shift_JIS(CP932) で保存するようなもの。

DATをテキストだと考えるからややこしいんだ。
いっそoctet-streamとしてバイナリ扱いにでもすればいい。

そもそも人間が読めるようにしてるのは誰かってことを考えればなんてことないわけで
作り直すのに時間とお金がかかるのが問題なのかなあとか思ったり
ご飯食べないで生きられて時間が無限にあれば全部解決

とか実も蓋もないことを書いてみる

金も時間もあって2chの心臓部に触れられる人間というと一人しかいないな
飯のかわりにうまい棒で済むし

そのおっさんがどうだろうって言ってるわけでふりだしに戻る

いやもう結論でてるし

そうか
IDかっこいいな

おっさんの気が変わった時に備えて議論しておこうとか

あぼーん

てす

テステス

tes

>>312
俺も国際標準になるんだぜ？

read.cgiをいじってみるよスレッド
http://qb5.2ch.net/test/read.cgi/operate/1222311594/

sjisをブラウザでutf8に変換してread.js使えばおｋじゃねの？

>>455
何周遅れだｗ

sjisをブラウザでutf8に変換とかある意味凄い発想ではある（わらい

DBの容量食うけどutf8でよいよ。
???????がなくなるな。

おっさんがまたその気にならないかなぁ

utf8にしたらrockの方もutf8にする必要あるんじゃないの？

現在のshift-jisに無い文字はhtmlで使われてる&〜; で対応可能だけど
utf8になったら生を扱う事になって（ｒｙ

その方がごっつぅ都合良かったりします♪

SJISはダメ文字がうざいな。
管理人の主眼はread.jsのようだが。

専ブラの対応は、文字コード処理なんてどの言語も
関数なりライブラリなりがあるから大した手間じゃないでしょ。
と、スクリプト程度しか作れない身で思ったら、
Delphiはめんどいのか>>361


切り替えは、ある時期に旧鯖は新スレ禁止、
utf鯖に全てスレを立て直して、keyの前後で区別すればいいよ。
鯖での区別はリスト保持がめんどい>>15

>>462
Delphiは2009からネイティブUnicode、
それ以前のでも表示させるのは可能だ
いまんとこJane系はNidaはUTF8も読める

スレタイにSJIS範囲外の文字が入ると化けるけど

dat + read.js
と
XML + XSLT
は、ブラウザはどっちが軽いんだろう。

専用ブラウザもIEのＴridentエンジン使ってるんだから大した修正なしで出来ると思うんだが

全部の専ブラがTrident使ってるわけじゃないし

モノ知らんヤツはいいなあｗ

まあまずは制限を1024KBに引き上げることだな
話はそれからだ

規制議論板から誘導されてきました。

この板を荒らした方が面白い反応が得られそうなので、これから数ヶ月間あの手この手で荒らし続けます。

これはほんの挨拶代わりのコピペマルチポポポです。

どうか面白い反応で楽しませてください。

以上、苦情は規制議論板まで。