+ JavaScript の質問用スレッド vol.142 +
レス数が950を超えています。1000を超えると書き込みができなくなります。
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
質問者は !slip:vvvvv を名前欄に、その後は「レス番」＋!slip:vvvvv
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」から解離した議論はよそでやること。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです
■前スレ
+ JavaScript の質問用スレッド vol.141 +
https://mevius.5ch.net/test/read.cgi/hp/1562318008/ >>847
3+3=6も3*3=9も同じ暗記じゃないか
熟語とか歌とかは覚えられるんでしょ？
だったら「さざんがく」とか覚えられない訳がないと思うが
というか>>835が疑問なんだけど
足し算ができるのなら7*8なら7を8回足したほうが早いんじゃないの
そしてそれが高速にできるのなら実質九九が言えるってことで
暗記して無くてもほぼ掛け算できるってことになるけど 数学ができるんだから別に7を8回足さなくても
7*8 → 7*(4+4) → (7+7)*4 → 14*(2+2) → (14+14)*2 → 28+28 → 56
くらいぱっとできそうなものだけど 自分自身に上手く適合するアルゴリズムも考えつかない者が
人様の無理難題を叶えるアルゴリズムを考えつくはずがないので
少なくともプログラマになるのは辞めたほうがよい >>851
いや掛け算はできるよそりゃ
丸暗記しなかっただけで >>853
自分にフィットしたアルゴリズムが>>835ですよ >>854
丸暗記してて100％の自身を持って一目で結果がわかる人なんて少ないよ
7×8とか見たら過半数の人がしちは、ごじゅうろく
というのを思い出すと思うよ 脳内でそういう絵が浮かぶというだけで実際に丸を１つずつ数えてるわけじゃないだろ
本当はできるしできてるのに俺はこういうやり方でしかできないと思いこんでいるだけ win10,64bitです。
SaveAsでpdfをテキストへ変換する処理を作っています。
VBAからコールしています（ブラウザは使用していません）。
ファイルサイズが大きい場合は当然ですが時間がやたらかかります。
必要なのは最初の1pだけなのですが
その部分だけ変換する方法は無いでしょうか。
先頭◎ページだの◎バイトだの指定するオプションがあったら
と思いましたが見つけられませんでした。 Ruby では、バイナリ読み込みで、
offset 位置に、seek して、そこから指定サイズ分だけ読み込める
binread(ファイルパス, length = nil, offset = 0) -> String | nil
でも、最初の1ページの、offset(1ページ目の始まる位置)やサイズが、どうやって分かるの？ >>860
これ誤爆？
JS関係ないけどpdftkやpdftotextを使えば簡単にできる もうさ、タイトルも「javascriptとrubyのスレッド」にしチャイナよ Rubyガイジが一番の粘着だろ
毎日早く死なないかなって思ってるよ スレに妖精が住み着くことは歓迎でしょ
本当に寂れたスレには妖精すら寄り付かない
Ruby君もスレがちょっと盛り上がったタイミングでいつも現れてるでしょ
目安になって丁度いい どっちにしろ次スレはIDとワッチョイつくから
好きな人はそのままにすればいいし
嫌いな人はNGすればいいから
もうこんなことで揉めることもなくなろう
誰も損しない >>868
本当の妖精とは違うんだけどね
本当の妖精は宣伝でも自己主張でもないけど
格別なレスを残していく異質な存在
jQuery厨やRuby厨はけしてそんな訳のわからない物ではないが
本物の妖精はもう何年も見なくなって寂しいので
仕方なくちっちゃな妖精ということにして気分をもり立ててるだけ >>869
世迷言を言う
懲りないねえ
若さかな? >>870
本物の妖精とか、実在するとでも思ってんのか？ｗ
元から物語の中だけのものですよ >>872
君も一度見たら分かる
まあもうこの板で見ることは無いかもしれないが Rubyガイジの登場でスレの盛り上がり判定とかRubyガイジ以上のガイジだわ https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQuery
2017年 71.9%
2018年 73.1%
2019年 73.6%
2020年 74.2%
2020年2月 74.4%
2020年6月 75.5%
2020年8月15日 76.2%
流石にこれは異常とも言える増加量
代わりに減ってるのは None みたい
今まで使ってなかったサイトがjQueryを使い出したのか？ 2011 28.3%
2012 42.8% (+14.5%)
2013 54.5% (+11.7%)
2014 57.4% (+2.9%)
2015 61.5% (+4.1%)
2016 68.3% (+6.8%)
2017 71.9% (+3.6%)
2018 73.1% (+1.2%)
2019 73.6% (+0.5%)
2020 74.2% (+0.6%)
2021 76.2% (+3.0%) 8ヶ月のデータからの予測 でも使われてるのは8割が1.x.xなんだな
https://w3techs.com/technologies/details/js-jquery
最近WordPressが同梱のを3.5.1に上げたらしいので、少しは3も増えるんだろうね >>881
それは当たり前だと思うよ
俺らがウェブの最先端を引っ張っていくのじゃーなんて息巻いて
自他ともにそういう会社だねって認める会社なんてわずかしか無い
1.xと2.xの機能は完全に同じ。対応ブラウザが "2の方が" 減ってるだけ
だから今3.xだったとしても一つ前のバージョンぐらいの意味でしか無いよ
まあ2割でも他に比べれば相当多いんだがねｗ AMPとかの有名なフレームワークに含まれてしまってるから
全体的にいくつかのライブラリの割合が上がってるが
実際はjQueryを使ってる人は見ないな お前が見るとか見ないとか言っても
何の説得力もないだろ
「俺はたくさん見る」で反論になるんだしｗ >>883
> AMPとかの有名なフレームワークに含まれてしまってるから
それはなんか根拠あるの？
仮にAMPに「jQueryが含まれてしまってる」として、
それらのAMPに「その他のライブラリは含まれてない」から
こんなにシェアが大きく違うんだよね？ >>885
そういうこと、他のライブラリは必要な所で必要なだけ使われてるが
jQueryは無駄に配られて決まっているということ
昔はまだCDNでキャッシュが効いてたが昨今ダブルキーイングになってからは
とにかくリソースの無駄遣いとして嫌われてるってわけよ > jQueryは無駄に配られて決まっているということ
AMP？とかで使ってるんだろ？
それは無駄っていわねーよ > 昔はまだCDNでキャッシュが効いてたが昨今ダブルキーイングになってからは
意味不明。その理屈ならリソースの無駄の原因はダブルキューイングだろ
jQuery以外にも当てはまるんだからさぁ 使わないライブラリを載せててもCDNでキャッシュが効いてた頃は問題にならなかったと言う意味かと だからフレームワークが内部で使うんでしょ？使うから含まれてるわけで 例えキャッシュが効かなくてもCDNで配布されてるなら
回線が高速ってことだし、自サーバーの負荷は減ることに変わりはない
>>886みたいなのってただjQueryに狙いをつけて言ってみただけって感じがするよな
論理的な理屈が伴ってない フレームワークで使ってないんだよ！だからサーバーのディスク容量を圧迫するだけなんだよ！
使ってないからダウンロードしない。だけどリソースの無駄なんだよ
リソースの無駄ってえーとあの通信量？ダウンロードしないけどね！
どこからも使ってないからダウンロードしないけど外部から使ってるって検出できるんだ！
みたいな意味不明な理屈を言い出しそうだから先に指摘しておくね >>889
無駄なものを極力なくそうというのは良し悪し
マヨネーズやケチャップの底に溜まってる部分があるだろ
でもそのおかげで他の部分がスムーズに出るんだ
世の中の本質ってそんなもん
どうせ人間の時代なんてあと100年も続かずにAIに管理されるようになるんだからさ
宇宙のエントロピーをほんの僅か無駄に増大させてもいいじゃないか
適当に楽しく生きなよ 俺のも溜まってるので肌の露出した女性を見るだけで少し出てしまいます/// 長いことこのスレにいるがjQuery厨はｼｪｱｶﾞｰｼｪｱｶﾞｰとはよく言うが
他と比べてこういうときにここが良いから選んで使ってるという話は見たことがない >>895
話してもいいよ？
まず標準のDOM APIと相性がいいということ
薄いラッパーで変なことはしてないから
ウェブの標準のやり方と大きく変わることがない
なんならDOM APIと混ぜて使える
それでいながら宣言的な記述のシンプルなインターフェースを備えており
HTML/CSSと相性が非常にいい。HTML/CSSとうまく組み合わせて使うと
JavaScriptのコードも大きく減らせる
今は役目を殆ど終えたが、それでもスマホなどのいくつかの端末用の
ワークアラウンドが含まれており、標準DOM APIを使うのに比べて安心ができる
1系、2系を使えば何も気にせず古いIEに対応することも可能
そしてファイルサイズはわずか30KB程度で高速なCDNで配布されてる
という話をしたんだからシェアがーという話だけをしてるなんて
今後はいわないでね。それはもう嘘になってしまうから jQuery 3.5 では、解凍すると、min 版で、90KB
Ajax などを省いた、slim 版で、70KB >>897
解凍することに何の意味があるんだ？
速度を意識してるなら通信レベルでgzip圧縮されるだろ
CDNの配布も普通にjsファイルを置いているように見えて
通信は圧縮されてる
ってことも知らない程度の知識の人かな？ >>898
今は当たり前過ぎて
気にしたことすらない人が一定数いるかもね
2ch閉鎖祭りを思い出すなあ
あの時も、今ほどではないが暑い夏だったなあ 自分がアクセスするサイトだけで言えば
10年前は半数以上はjQuery使ってたが今は多く見積もっても2~3割
w3techs.comのデータはほんと謎 Ruby on Rails 6 でも、Bootstrap, React などを使う
Bootstrap は、jQuery, Popper.js に依存しているから 最近のJSエンジンはファイルをストリーミングでパース・評価できる
それを前提として圧縮していないとその恩恵が受けられない
通信速度も高速化しててせいぜい10ms程度しか節約できないのなら圧縮する意味がなくなる
だから近年の常識としては基本的にMB単位のファイルだけをBrotliで圧縮できる場合だけする
gzipは2G/3Gスマホのためには有効だからまだ世界的には標準だが、
日本では害の方が大きいので全部で使うくらいなら全部で使わない方が良い つまりこういうことね
最近のJSエンジンはファイルをストリーミングでパース・評価できる
それを前提として圧縮していないとその恩恵が受けられない
ウェブで使われるgzip圧縮はそれを前提として圧縮しているため恩恵が受られる gzipではストリームダメだからbrotli作ったという話では？ gzipと比べた時にbrotliに圧縮率が高い以外の特徴なんてねーよ そもそも展開時にストリーミングができない圧縮形式なんてあるのか？
圧縮時は全体眺めて同じデータを探す必要があるが
展開時は前から処理できるだろ >>908
一般的にデータ部分の展開は順次できるけど
まずデータ部分の場所を特定するのに一番最後を見ないといけない形式も多い
ZIPがその代表例
圧縮する側に立って考えてみたら分かる
圧縮する前に圧縮後のデータ量を知ることはできない
ファイルを順次圧縮して追加していって最後まで終わった段階で
ようやくファイル構造が確定するのでそれを末尾に乗せることができる
１ファイルだけを圧縮するgzipでもCRC32がデータの後に着くのが普通なので
ファイルが壊れているかどうか気にしないのでなければ受信途中で読み始めることはしない
だから普通はHTTPのチャンク機能を使ってデータを分割する（HTTP2ではまた別の機能）
ただし各チャンクのサイズを小さくするとオーバーヘッドが多くなりすぎるし、
かといってサイズを大きくすると、ストリーミングの効果が薄くなるので難しい んで、ウェブで使われているgzip形式っていうのは
データの最初から展開できるようになってる >>909
> 圧縮する前に圧縮後のデータ量を知ることはできない
> ファイルを順次圧縮して追加していって最後まで終わった段階で
> ようやくファイル構造が確定するのでそれを末尾に乗せることができる
先頭に入れても良いのでは？ 十分大きいバッファをメモリに持っておいて圧縮が終わってからディスクに書き込むのならできるだろうな もしかして今の若い人は一般的なファイルシステムだとファイルは末尾に追記するか真っ更から書き直すかしかないってことを知らないのだろうか
頭に追加しようと思ったら全部読んで退けておいて書き換えないといけないってことは常識かと思ってた 数バイトオフセット取って書きはじめて最後に先頭にポインタ戻してサイズ書き込めばいいだけじゃんｗ
Cのファイル操作の基本でできるけどｗｗｗ つーか、圧縮ファイルで先頭に何を書きたいのかわからん
ファイルの数とかか？そんなもん最初に書き込む領域数バイトを
ヘッダ領域として予約するだけじゃん 当然各ファイルのデータ毎に（ほぼ）固定長のヘッダーはあるが
それだけではファイルの一覧を見るのに頭からお尻まで舐めないといけない
さらに、10000個目のファイルを見たいときに10000個辿らないといけない
だから、ファイルのデータ以外の情報がどこかに局所的に固まっていないといけないのだが
それを先頭に持ってくるのはいろんな理由で難しい
最初１０個のファイルを書き込む予定が９個になるかもしれないし
５個の時点で設定容量に達して複数アーカイブに分割するかもしれない
そもそも圧縮を始める前に全てのファイル情報を読まないといけない
一方もし末尾に置くのであれば、この先のことを考えずに
今圧縮するファイルのことだけを考えて次から次へと圧縮を進めることができる
要するに圧縮がストリーミングでできる
そして全てのファイルの圧縮が終わった後にそれまでの結果を末尾に書けばいいだけだから楽だし安心 すべてが終わったあとに予約しといた先頭に書けばいいだろ >>919
> 当然各ファイルのデータ毎に（ほぼ）固定長のヘッダーはあるが
> それだけではファイルの一覧を見るのに頭からお尻まで舐めないといけない
1つのファイルだけを圧縮する、httpでの配信でそれなんか関係あんの？
ファイルの頭に最初に処理するファイル名だけを格納するだけじゃん [JavaScript] reduceは可読性が悪くループで置き換え可能なので使うべきではない
https://qiita.com/standard-software/items/3254c19ed5229f3aba9a
正しい（笑）
reduceはsum関数などを作るための"材料"として使うもので
直接使うもんじゃないよ
そして材料としての役割はあるにしてもJavaScriptでは関数呼び出しで
遅くなるので最適化すると単純なループのほうが良くなるというね ヘッダーが固定長なら、問題ない。
abc を、axc に変えても、後ろに影響が及ばない
でも、可変長では、後ろのデータも上書きされてしまう。
abc のb をxy にすると、axy となり、cも消える
つまり、同じサイズじゃないと、バグる だから、ヘッダー・データを別々に作って、
データだけを一旦、ファイルに保存しておいて、
ヘッダーとデータを、cat で連結させて、新しいファイルを作る
でも、これは、ファイルコピーばかり、やってる事になる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 豊富なメソッドがあれば便利っちゃ便利だけど
ぶっちゃけ、ゴリゴリにアルゴリズムが必要な場面以外ではありがたみが薄いし
ゴリゴリに必要な場面では最適化のために使いにくい JavaScriptでサーバー内のバイナリファイルを読み込みたいのですがその手段はどのようなものですか？
調べたところクライアント側のローカルファイルの読み込みなら<input type="file">でfileオブジェクトを生成してイベントハンドラで読み込めることが分かったのですが結局のところ目的の達成ができていません。
C言語のfopen関数みたいにファイルを簡単に読み込める便利なAPIはないですかね >>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
プロ野球選手にどこがすごいの？レジ打ち遅いじゃんって言ってるようなもんだろｗ サーバー内のバイナリファイルを読み込みたいってのは
特定のURLでアクセス可能なWeb上のファイルを
クライアント側JavaScriptからダウンロードしたいということだったのか
え！？ だったのかって、俺は読んでそうかなと思ったぞ
分かりにくい質問だったが、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は下記に作成しました
https://jsfiddle.net/0kj5oe9s/ >>947
勉強のためにCSV読み込みを自作したいなら
まずクォートされてる範囲を取れるようにしたらいいよ
そうすれば、クォート内のカンマは無視できるようになる
ただ読み込みたいだけならライブラリもあるし
または、先にCSVをJSONに変換しておくのが楽だと思う >>947
正規表現は「単語はアルファベットの並び」などという定義をするためのもので
この順番に単語が出てきたらこれは動詞みたいな意味を定義するものではありません
つまり正規表現でCSVを解釈することはできません
CSVなどの文字列の意味を解釈するために使う道具が正規表現であって
CSVなどの意味を解釈するものはパーサーと言うんです
あなたはパーサーを作らなければいけないのに
それを作らずに正規表現でやろうとしています >>948
>>949
> 勉強のためにCSV読み込みを自作
そうですね、正規表現の勉強も兼ねてライブラリなしで読み込みたい感じです
JSfiddleを見てもらうとわかると思いますが
クォートの範囲を取ることは出来てます、あとクォートされてない文字列を取ることも
ただ、文字列がない部分を配列に格納することだけが出来ないので悔しくてこちらで聞かせて頂きました… >>950
正規表現でやる以上
マッチしないところは無理だわな
先頭から1文字ずつ追いなされ レス数が950を超えています。1000を超えると書き込みができなくなります。
