元スレJavaScript の質問用スレッド vol.132
JavaScript覧 / PC版 / みんなの評価 :
752 = :
FILE API でテキストを読み込ませる処理でアドバイス欲しいです
D&D形式ではなくinput typeのFILEから1つのtxtファイルを選択して読み込ませたいのですが
ファイル選択待ちの間にonloadが止まってしまいます。
ローカル環境では一瞬で止まるのでしょうか？
以下、流れ
参照ボタンで発火
DOM idからファイル情報を取得
ifで振り分け(テキストファイルのみ実行許可)
以降はFILE APIです
発火のタイミングを参照終了後にする方法があれば良いのですが、便利な方法などありませんか？
ボタンを二回押す方式なら可能なのですがそれだと面倒なので、ファイルを選択して読み込ませたと同時に発火させたいです。
753 = :
日本語でおk
754 = :
>>752
コードを貼ってくれた方が回答を得やすいと思うよ
755 = :
>>751
Firefoxでは動くのにChromeじゃ動かないコードは掃くほどあるからな
動作確認はChromeの方がいいかもなｗ
756 = :
>>755
IEでは動くのにFirefoxじゃ動かないコードは掃くほどあるからな
動作確認はIEの方がいいかもなｗ
757 = :
>>755
chromeで動かない=webkitで動かないってことにほぼ等しい
今の時代そんなコードはゴミに等しいんだよ
開発の確認で使うならFireFoxは今すぐ投げ捨てたほうがいい
758 = :
IEってほんとまともになってきたよね・・・
759 = :
アロー演算子認識してくれなくね？
760 = :
>>757
webkitはもう切り捨ててるよ。
使ってるブラウザ少ないし
IEよりもシェアが低い
761 = :
>>760
君恥ずかしいからもう来ない方がいいぞ
763 = :
>>752 です。
解決できました。
jsの発火タイミングをonChangeに変更したらonloadが正常に動きました。
問題が解決する前はファイルを選択画面を表示させるボタンを押したと同時に発火していたため、onloadが終了を確認する前に強制停止していたようです。
ちなみに、ローカルでもサーバーでも2往復して変化がなければ強制停止するみたいです(IE、FFで確認)
764 = :
うん。初心者が躓きやすいポイントだね。
でもすぐ気づいたのは素晴らしいよ。
その調子で頑張ってね。
765 = :
また問題発生。
FILE APIでwindowsのコンピュータに生成したテキストファイルをbase64エンコードをかけて保存。
読み出すと英数字は取得できるが、デコードをかけると文字化けを起こす。
どんな問題が考えられますかね？
767 = :
jsならutf8に統一せんと今後苦労するぞ
768 = :
>>761
webkitは、ほぼSafari専用だよ
他のブラウザはwebkit使ってない
知らないの？
769 = :
>>768
釣りなんだろうけど、シェアトップのChormeはWebkitベースだし、スマホのシェアも
約半数がiPhone Safariで、次点でAndroid Chromeだけど、これらもWebkitだよ
ログをとっていなくても、サイト制作経験があるなら
-webkit-という接頭辞で自ずとわかるはずなんだけどね
771 = :
Blink「…」
772 = :
純粋なWebkitはSafari, iOS Safari
WebkitからフォークされたBlinkがGoogle Chrome, Android Chrome, Android標準ブラウザ, Opera
歴史的経緯からGoogle Chromeのベンダー接頭辞は -webkit、Operaは知らん
他、ニンテンドー3DS, PS3,PS4...etc
774 = :
>>766
>>767
文字コードチェックしたところ、js,css,htmlファイルともにutf-8のボム無しでした。
ですが、jsから吐き出されたtxtファイルはbase64エンコードを通したものだけshift-JISに変換されていたようです。
windowsに保存されたので文字コードが変換されたのかと思い、念のためにbase64を通さずFILEAPIだけで生成してみたところ、こちらはutf-8ボム無しで保存されていました。
原因はほぼ間違えなくbase64エンコード関係だとみています。
ですが、保存は最終的にはFILEAPIで行うのに途中で文字コードが変わるんですかね？
775 = :
>>774
抜粋したソースでいいから貼ってもらえないかな？
776 = :
なんぞライブラリ通して使っててそのライブラリが勝手にやってるとかじゃねーよな
777 = :
>>769
> 釣りなんだろうけど、シェアトップのChormeはWebkitベースだし、スマホのシェアも
釣り？ ChormeはWebkitベースじゃない
当然スマホもiOSを除きWebkitベースじゃない
そしてWebkitベースじゃないものがほとんど
778 = :
直接関係なくかつ無知で申し訳ないんだが
File APIの、ユーザにとっての安全性って
要するに「ユーザに選ばせるから通常のinput type="file"と同じよ」ってことでいい？
んで機能的には非表示iframeをtargetにしてformからアップロード、ってさせなくてもjsがデータ受け取れるよ的な
779 = :
Chromeの中に含まれていたWebkit由来のコードは
2014年の時点ですでに半分にまで減っている
今は殆どないだろう
781 = :
>>772
> 歴史的経緯からGoogle Chromeのベンダー接頭辞は -webkit、Operaは知らん
違う。Google Chromeのベンダー接頭辞はつけない。
Blink、新機能に対して新たなベンダープレフィクスを追加しない決定
http://cpplover.blogspot.jp/2013/05/blink.html
今も残っているとしたら、それは過去の遺産だろう
OperaはChromeと同じエンジンを使っている
Webkitではない
782 = :
CSS からベンダプレフィックスという仕組みが消える日
http://hyper-text.org/archives/2013/05/goodbye_vendor_prefixes.shtml
「ベンダプレフィックスに -chrome- が増えるの？」 という質問に対して、
今後、新しい機能に対してベンダプレフィックスを増やすことはしない
実験的な DOM / CSS の機能に関しては、about:flags で設定可能にする
正式にリリースが可能になった時点で、dev/canary チャネルにおいてデフォルト有効の状態にする
既存の -webkit- ベンダプレフィックスは引き続き使用可能
プレフィックス付きの記述をどのタイミングで廃止するかは、統計データを基に決める
783 = :
>>778
> んで機能的には非表示iframeをtargetにしてformからアップロード、ってさせなくてもjsがデータ受け取れるよ的な
iframeは必要ない。そんなものを使わなくても、formからsubmitしなくても
input type="file"でファイルを選んだ時点でjsからデータ取れる
784 = :
>>783
言い直しただけやん
786 = :
>>784
よく読もうねおじいちゃん
787 = :
元々はwebkitからforkしてました
だんだんとwebkitのコードから独自のコードに変えていきました
当時のベンダープレフィックスはwebkitだったけど今後は-webkitでも-chromeでもなくprefix無しになります
どれも数年前の話からそのまま進んでるといえど
>ChormeはWebkitベース
>歴史的経緯からGoogle Chromeのベンダー接頭辞は -webkit
これ間違ってないように見えるのだが
788 = :
-webkit- をサポートしていたら、それはwebkitというのなら、
Edgeはwebkitってことになるなｗ
http://msdn.microsoft.com/en-us/library/mt270097(v=vs.85).aspx
Supported WebKit APIs
For improved compatibility, Microsoft Edge supports a variety of "-webkit-" prefixed APIs.
Below is a list of these supported APIs.
Google翻訳
サポートされているWebKit API
互換性を向上させるために、Microsoft Edgeでは、プレフィックス付きのさまざまな "-webkit-" APIをサポートしています。
以下は、これらのサポートされているAPIのリストです。
789 = :
この阿呆はマイクロソフト系ばかりの平社員PGって感じだな
もっと現実的をみろよ
790 = :
>>787
Webkitのコードは削除されたのでもはやWebkitではない。
Blinkで動いてテストしても、Webkitで動くことにはならないのだから
>歴史的経緯からGoogle Chromeのベンダー接頭辞は -webkit
互換性のために残しているだけ。
Edgeが互換性のために-webkit-をサポートしているのと何も変わらない
791 = :
Chromeで動かないJSコード書くアレな人はまだムキになって屁理屈捏ねてるの？
792 = :
Chromeで動けば、Safariでも動くって思っている人には
夢見せてあげれば良いんじゃないっすかね？ｗ
Safariで動くかテストした？って聞かれれば
Chromeで動いたからだいじょっブッスよｗｗｗ
って言っておｋ
BlinkからWebkitのコードが削除され
WebkitからChrome用のコードが削除されてるってことは
知らなかったことにしておけば良いｗｗｗ
793 = :
>>790
blinkにはwebkitのコードは最早存在しないということか？
そういうのってどの辺みればわかるの
795 = :
※確認していません
796 = :
確認しろよｗ
797 = :
http://caniuse.com/
Browser scores
Chrome 56: 275
Firefox 52: 274
Safari 10: 217
Edge 14: 210
これみても、ChromeとFirefoxは同じぐらいだけど、
そこから2割差が開いてSafariはEdgeと同じぐらいだからな。
これで同じと思っちゃうのは頭が悪い
798 = :
>>792
話そらすのに必死だなおまえ
Chromeで動かないレベルのコード書くバカなんだからそろそろ自重しないと
799 = :
○○ベースっていう言葉のいみすら分からないの？
800 = :
WebKitはKDEプロジェクトで開発されたKHTMLをフォークして作られたのだから
KHTMLベースと言うべきだ。どんなに変わっとしてもだ！
http://ja.wikipedia.org/wiki/WebKit
> WebKitは、元々アップルのmacOSに搭載されるSafariのレンダリングエンジンとして、LinuxやBSDといった、
> Unix系用のレンダリングエンジンであるKHTMLをフォークして開発された。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.132 + (1001) - [91%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [88%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.133 + (1001) - [88%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.113 + (1001) - [88%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.130 + (974) - [88%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.123 + (1002) - [88%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [88%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.123 + (966) - [88%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.103 + (1001) - [88%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.130 + (1001) - [88%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.102 + (1001) - [88%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [88%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.142 + (984) - [88%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.122 + (116) - [88%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [88%] - 2015/2/14 4:45
トップメニューへ / →のくす牧場書庫について