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

http://www.it-swarm.dev/ja/http/%E7%8F%BE%E5%AE%9F%E3%81%AE%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%8Cdeflate%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%88%E3%82%8A%E3%82%82gzip%E3%82%92%E5%A5%BD%E3%82%80%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%A7%E3%81%99%E3%81%8B%EF%BC%9F/957517037/

> 詳細については、このWebサイトを確認してください：
> http://web.archive.org/web/20120321182910/http://www.vervestudios.co/projects/compression-tests
>
> 仕様によると、Deflateは実際には zlib （Web経由でコンテンツをストリーミング
> するために特別に開発された圧縮形式）...これはdeflateのラッパーです。

なるほどね。最初からストリーミング対応で設計された圧縮方式を
ウェブでは扱われているわけだ

つまりこういうことね

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

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

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

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

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

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

へぇー詳しい

>>909
勉強になりました

んで、ウェブで使われているgzip形式っていうのは
データの最初から展開できるようになってる

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

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

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

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

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

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

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

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

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

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

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

いつもの恥の上塗りっ子

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

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

[JavaScript] reduceは可読性が悪くループで置き換え可能なので使うべきではない
http://qiita.com/standard-software/items/3254c19ed5229f3aba9a

正しい（笑）


reduceはsum関数などを作るための"材料"として使うもので
直接使うもんじゃないよ

そして材料としての役割はあるにしてもJavaScriptでは関数呼び出しで
遅くなるので最適化すると単純なループのほうが良くなるというね

ヘッダーが固定長なら、問題ない。
abc を、axc に変えても、後ろに影響が及ばない

でも、可変長では、後ろのデータも上書きされてしまう。
abc のb をxy にすると、axy となり、cも消える

つまり、同じサイズじゃないと、バグる

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

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

>>924
安定のクソ記事だなw

Ruby では、with_object(蓄積変数), with_index(auto increment) で、メソッドチェーンできる。
これで、変数をブロック内スコープに限定できる

text = <<'TEXT'
a
b
TEXT

# 1行ずつ処理する。index は、1 始点
ary = text.each_line.with_object( [ 5 ] ).with_index( 1 ) do | ( line, acc ), idx |
line.chomp! # 末尾の改行を削除する
acc.push [ idx, line ]
end

p ary # [5, [1, "a"], [2, "b"]]

もし、これで蓄積変数を使わないと、外のスコープへ広がる

ary = [ 5 ]

text.each_line.with_index( 1 ) do | line, idx |
line.chomp!
ary.push [ idx, line ]
end

p ary # [5, [1, "a"], [2, "b"]]

Elixir でも、for の内包表記を使うと、指定した回数分だけループできる

for cnt <- 1..length( 'abc' ), do: IO.inspect cnt # 1～3

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

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

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

レスくださった方々、ありがとうございます
>>931
node.jsは使用していませんがnode.jsのapiとweb標準のapiが違うということを知れました。勉強になりました
将来的にnode.jsの勉強もするかもしれないので目を通しておきます。ありがとうございました
>>932
探していたものはまさにこれでした。fetchでファイル処理ができそうです。ありがとうございます
>>933
c++から入った日曜プログラマーなのでご指摘の通りwebとjavascriptの理解が浅いです^^;
canvasでRPG作ったら勉強になるっしょってノリでゲーム作ってますが難しいですね
型がなかったり割とガバガバなコードでも通っちゃうので大混乱です。これを使いこなしてる人すげーなって思いました
ありがとうございました

もう来んなよ
こんな所に

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

名付けてCanvasRPG地獄だ

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

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

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

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

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

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

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

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

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

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

サーバー内のバイナリファイルって説明がなぁｗ
webで外部に公開されとるんかーいｽﾞｺｰってなもんよｗ

質問です
CSVの行データから配列を作ろうと思ったのですが、
ダブルクォーテーションの中にカンマが入ったりするので思ったように分割できません
書いた正規表現は下記です

このコードの問題点は、文字列が入ってない部分は配列化されず無視されてしまうことです…
例えば000はその前にカンマがあるので配列上は二番目であるべき


var text=',000,"111",,"111,222",,,"111,222,333",,,,"111,222,333,444"';
var Array=text.match(/("[^"]*"|[^,]+)/g);

どなたかアドバイス頂けますでしょうか

JSfiddleは下記に作成しました
http://jsfiddle.net/0kj5oe9s/

>>947
勉強のためにCSV読み込みを自作したいなら
まずクォートされてる範囲を取れるようにしたらいいよ
そうすれば、クォート内のカンマは無視できるようになる

ただ読み込みたいだけならライブラリもあるし
または、先にCSVをJSONに変換しておくのが楽だと思う

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

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

>>948
>>949

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

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

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

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

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