のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,913人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

    元スレ+ JavaScript の質問用スレッド vol.142 +

    JavaScript覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

    902 = :

    最近のJSエンジンはファイルをストリーミングでパース・評価できる
    それを前提として圧縮していないとその恩恵が受けられない
    通信速度も高速化しててせいぜい10ms程度しか節約できないのなら圧縮する意味がなくなる
    だから近年の常識としては基本的にMB単位のファイルだけをBrotliで圧縮できる場合だけする
    gzipは2G/3Gスマホのためには有効だからまだ世界的には標準だが、
    日本では害の方が大きいので全部で使うくらいなら全部で使わない方が良い

    904 = :

    つまりこういうことね

    最近のJSエンジンはファイルをストリーミングでパース・評価できる
    それを前提として圧縮していないとその恩恵が受けられない
    ウェブで使われるgzip圧縮はそれを前提として圧縮しているため恩恵が受られる

    907 = :

    そもそも展開時にストリーミングができない圧縮形式なんてあるのか？
    圧縮時は全体眺めて同じデータを探す必要があるが
    展開時は前から処理できるだろ

    908 = :

    >>908
    一般的にデータ部分の展開は順次できるけど
    まずデータ部分の場所を特定するのに一番最後を見ないといけない形式も多い
    ZIPがその代表例

    圧縮する側に立って考えてみたら分かる
    圧縮する前に圧縮後のデータ量を知ることはできない
    ファイルを順次圧縮して追加していって最後まで終わった段階で
    ようやくファイル構造が確定するのでそれを末尾に乗せることができる

    １ファイルだけを圧縮するgzipでもCRC32がデータの後に着くのが普通なので
    ファイルが壊れているかどうか気にしないのでなければ受信途中で読み始めることはしない
    だから普通はHTTPのチャンク機能を使ってデータを分割する（HTTP2ではまた別の機能）

    ただし各チャンクのサイズを小さくするとオーバーヘッドが多くなりすぎるし、
    かといってサイズを大きくすると、ストリーミングの効果が薄くなるので難しい

    909 = :

    へぇー詳しい

    910 :

    >>909
    勉強になりました

    913 = :

    >>909
    > 圧縮する前に圧縮後のデータ量を知ることはできない
    > ファイルを順次圧縮して追加していって最後まで終わった段階で
    > ようやくファイル構造が確定するのでそれを末尾に乗せることができる

    先頭に入れても良いのでは？

    914 = :

    十分大きいバッファをメモリに持っておいて圧縮が終わってからディスクに書き込むのならできるだろうな

    915 = :

    もしかして今の若い人は一般的なファイルシステムだとファイルは末尾に追記するか真っ更から書き直すかしかないってことを知らないのだろうか
    頭に追加しようと思ったら全部読んで退けておいて書き換えないといけないってことは常識かと思ってた

    916 = :

    数バイトオフセット取って書きはじめて最後に先頭にポインタ戻してサイズ書き込めばいいだけじゃんｗ
    Cのファイル操作の基本でできるけどｗｗｗ

    917 = :

    つーか、圧縮ファイルで先頭に何を書きたいのかわからん
    ファイルの数とかか？そんなもん最初に書き込む領域数バイトを
    ヘッダ領域として予約するだけじゃん

    918 = :

    当然各ファイルのデータ毎に（ほぼ）固定長のヘッダーはあるが
    それだけではファイルの一覧を見るのに頭からお尻まで舐めないといけない
    さらに、10000個目のファイルを見たいときに10000個辿らないといけない
    だから、ファイルのデータ以外の情報がどこかに局所的に固まっていないといけないのだが
    それを先頭に持ってくるのはいろんな理由で難しい

    最初１０個のファイルを書き込む予定が９個になるかもしれないし
    ５個の時点で設定容量に達して複数アーカイブに分割するかもしれない
    そもそも圧縮を始める前に全てのファイル情報を読まないといけない

    一方もし末尾に置くのであれば、この先のことを考えずに
    今圧縮するファイルのことだけを考えて次から次へと圧縮を進めることができる
    要するに圧縮がストリーミングでできる
    そして全てのファイルの圧縮が終わった後にそれまでの結果を末尾に書けばいいだけだから楽だし安心

    919 = :

    すべてが終わったあとに予約しといた先頭に書けばいいだろ

    920 = :

    まさにそれがし難いという理由を書いたんだよ

    921 = :

    いつもの恥の上塗りっ子

    922 = :

    >>919
    > 当然各ファイルのデータ毎に（ほぼ）固定長のヘッダーはあるが
    > それだけではファイルの一覧を見るのに頭からお尻まで舐めないといけない

    1つのファイルだけを圧縮する、httpでの配信でそれなんか関係あんの？
    ファイルの頭に最初に処理するファイル名だけを格納するだけじゃん

    925 = :

    だから、ヘッダー・データを別々に作って、
    データだけを一旦、ファイルに保存しておいて、
    ヘッダーとデータを、cat で連結させて、新しいファイルを作る

    でも、これは、ファイルコピーばかり、やってる事になるw
    データが大きいと、無駄が多い

    928 = :

    豊富なメソッドがあれば便利っちゃ便利だけど
    ぶっちゃけ、ゴリゴリにアルゴリズムが必要な場面以外ではありがたみが薄いし
    ゴリゴリに必要な場面では最適化のために使いにくい

    930 = :

    >>930
    http://nodejs.org/docs/latest-v13.x/api/fs.html

    932 = :

    >>932
    だとしたらWebの基礎の基礎を全く理解してないことになるのでAPIの話をしても無駄だよね

    934 = :

    もう来んなよ
    こんな所に

    935 = :

    日曜プログラマでCanvasでRPGとか糞バカだな
    RPGとかこの世で作るのが一番難しいものの一つだろ
    シナリオ・音楽・絵、マップそれらを全て他所から持ってくるにしても苦労するのに
    それに加えてCanvas使ってプログラミングとかもはや273番目の地獄だわ

    名付けてCanvasRPG地獄だ

    そんなんができる根気と能力があったら日曜プログラマどころか
    起業して日本のスティーブ・ジョブズになれるっつうの
    いかに無謀なことしてるかよく考えたほうが良いぞ
    がんばりな

    936 = :

    そうかあ？
    小学生のクソ馬鹿だった俺でも
    すごーくシンプルなのはBasicでなんとか出来たから
    意外となんとかなるんじゃない？
    根気はいると思うけど

    937 = :

    別に挑戦する分にはいいんじゃないの
    生canvasはやめてライブラリの使用をおすすめするけど

    938 = :

    なんでスティーブ・ジョブズなん？
    全く畑が違うやんｗ

    939 :

    正直スティーブ・ジョブズのどこがすごいか分からん。
    たまたまiPhoneが出たときその会社のトップだっただけじゃないの？
    頭はいいのだろうか？ちゃんと微分方程式の難しいの解けたり物理学の面白さを語れるんだろうか？あるいはプログラミングならデザインパターンをどう適応するのかちゃんと根本的な理解をしているのだろうか？
    オレはこれらすべてできるが。

    940 = :

    自分を有名にする能力だけは間違いなくあるだろうな

    941 = :

    >>940
    恥ずかしいから静かにしてたほうがいいよ

    942 = :

    >>940
    プロ野球選手にどこがすごいの？レジ打ち遅いじゃんって言ってるようなもんだろｗ

    944 = :

    だったのかって、俺は読んでそうかなと思ったぞ
    分かりにくい質問だったが、Nodeの質問が来る確率なんて極めて小さいでしょ

    C10Kとか言ってNodeムーブメントが起きてた頃はちらほら質問が来てたが
    そのころでもNodeやサーバーサイドと言わず当たり前のように質問する人はいなかったと思うぞ

    948 = :

    >>947
    正規表現は「単語はアルファベットの並び」などという定義をするためのもので
    この順番に単語が出てきたらこれは動詞みたいな意味を定義するものではありません
    つまり正規表現でCSVを解釈することはできません

    CSVなどの文字列の意味を解釈するために使う道具が正規表現であって
    CSVなどの意味を解釈するものはパーサーと言うんです
    あなたはパーサーを作らなければいけないのに
    それを作らずに正規表現でやろうとしています

    949 = :

    >>948
    >>949

    > 勉強のためにCSV読み込みを自作

    そうですね、正規表現の勉強も兼ねてライブラリなしで読み込みたい感じです

    JSfiddleを見てもらうとわかると思いますが
    クォートの範囲を取ることは出来てます、あとクォートされてない文字列を取ることも
    ただ、文字列がない部分を配列に格納することだけが出来ないので悔しくてこちらで聞かせて頂きました…

    950 = :

    >>950
    正規表現でやる以上
    マッチしないところは無理だわな

    先頭から1文字ずつ追いなされ


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド

    トップメニューへ / →のくす牧場書庫について