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

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に引き上げることだな
話はそれからだ

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

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

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

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

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