元スレ+ JavaScript の質問用スレッド vol.128 +
JavaScript覧 / PC版 /みんなの評価 :
151 = :
Date.parse()で認識可能な文字でいいじゃん
152 = :
>>149
ヒント: 正規表現で (?:pattern)?
153 = :
<input type=time>を使うのがベスト
154 = :
>>150
日本語でもこのような表記にすればいけますよ的な感じには
したいのですが、その前に置換するので、'1h30m10s''30m10s'
等がうまく処理できれば大丈夫です。
>>151
ありがとうございます。
ちょっと調べてみます。
155 = :
((\d+)(h|時間))?((\d+)(m|分間?))?((\d+)(s|秒間?))?
こんな感じのでいけないか?
157 = :
>>155補足
この場合だと
var data = [ '3h50m32s', '30m10s', '1時間3分' ],
regexp = /((\d+)(h|時間))?((\d+)(m|分間?))?((\d+)(s|秒間?))?/ ;
for( var i=0,max=data.length; i<max; ++i ){
console.log( data[i].match(regexp) );
}
こんなかんじで書くと、data[2], data[5], data[8] それぞれ順番に時分秒としてundefinedか数字かが入る
正規表現の単位のところは (:?h|時間) と書いてメモリ節約のため省略してもいいし(添え字はズレるが)
入力に現れた単位として別途使っても良い
158 = :
>>156
fooという適当な名前だから駄目なだけで、グローバルな名前として
定義されているものなら全然問題ないよ。
例えばライブラリのクラスだって、変数に関数が入っているだけだし。
159 = :
>>152
ありがとうございます。
教えていただいたものをググって調べてみます
>>153
ありがとうございます。
素のHTMLなら安定してよさそうですね
>>155
おお!ありがとうございます。
教えていただいたものでいけそうです。
皆様ありがとうございました!
正規表現ってやっぱりすごいですね。
160 = :
>>157
ご丁寧にありがとうございます。
おかげさまでいろいろなケースに対応できそうです。
161 = :
>>160
テストコードちゃんと書けよ。
こういうのは一番テストしやすいんだから
ユニットテストをやるのに適した題材だ。
162 :
テストをやるようなレベルのものじゃないだろ……
163 = :
>>162
テストコードはすべてのものに必要
164 = :
仕様や目的が曖昧かつ合理性に疑問があるからテストを書く段階ではないな。
もしくはここにいる人に見せて問題がありそうな状況を探ってもらうことこそが
適当なテストケースで適当にテストするよりも、良いと言えるだろう。
そういう意味で粗方意見が出尽くして本人も納得している状況をもって
そのコードはこの上なくテストに合格していると見なして良い。
165 = :
だから仕様を明らかにするために
テストコードを書くんでしょ。
それがテストファーストだし
166 = :
このスレへんな人常駐してるね・・・
167 = :
すごくレベルの低い人が少しレベルの低い人に適当な回答をもらうスレッドだからしょうがない。
168 = :
割とマシな方だぞ
やばい奴はもっとやばい
169 = :
このスレでは昔のメールのように一定数の文字で改行入れたり、空行を頻繁に入れる人は高確率で変な奴だと思ってる
170 = :
>>169
お前横に長すぎ
171 = :
最近の若者は視野角が狭いんだな
スマートフォンばかり見てるからなのか
172 = :
だいたいみんな名前日付部分にあわせた長さを意識して編集するからな
文字数でいうと30文字ぐらいか
173 = :
>>169はおそらくコードを1行100文字も200文字も書くタイプなんだろうな
174 = :
昔は一行80文字がメールマナーとされていたが、今では30文字で改行する人もいるのか
あれはモニタの解像度の問題だったはずだから今ならもっと増えてもいいはずなんだがな
人間が退化してるんじゃないか
175 = :
2chはメールじゃねえし
実際お前もその程度で改行してるじゃないか
176 = :
文末で改行は誰でもやってるからなあ
たまたま1行が80文字になっていただけで改行なんて意識しないわ
177 = :
ひとりよがりのレスは誰も読んでくれないのは頭に入れておこうな
178 = :
解像度の問題?長すぎると読みづらい、それだけだろ?
179 = :
そう思うならお前の個人的な感想で他人を否定するのも誰も参考にしないから止めような
180 = :
100文字や200文字ぐらい普通に読めるし、自分の視野の狭さを基準にするなよ
181 = :
素朴な疑問なんだけど、コードを書くときに1行辺りの文字数って気にする?
俺は全然気にしないんだけど、100文字ぐらいは割と有る
200文字は流石にほとんどない
他のライブラリを見ても100~130文字ぐらいはあるのが多かった
182 = :
いちおう78バイト(CRLF込で80バイト)っつーのは昔のメーラーで
それ以降をカットしちゃうのがあるってのが理由だ
けっして読みやすさだけの理由じゃない
今ではまず心配いらないが改行する習慣の元はこれ
あとフロントエンドメインの人にはあまり知られてないが
1行998バイト制限(CRLF込で1000バイト)ってのがある
998以降で強制改行されるとマルチバイト文字だと
以降まるっと文字化けしちゃう
RFCで78は推奨、998は必須事項として記述されている
さらにPHPのmail関数だったかな?では
900バイトくらいで勝手に折り返す
つまり998を守っていても事故ることがある
だからメール配信するシステムでは余裕を見て改行することが多い
183 = :
掲示板だと読点以外で改行する理由が特にないな。
特に2chは2chブラウザで整形するから勝手に改行されるほうが困る。
改行は筆者の自己主張だからな。
184 = :
自分は大丈夫といかいう問題じゃないね
まあこういうレスする人は何が悲しくて人に無理やり反論ばかりしたがるんだろうね
185 = :
だいたい横伸びしてるレスは訳ありだから読まないで飛ばすけどね
186 = :
>>182
ほー、知らんかった 参考までにそういう挙動をするメーラーをいくつか教えてくれるか?
187 = :
>>186
俺も知らんのよ
20年前とかそういうレベルの話だと思われる
188 = :
RFCに沿って改行を追加するのならわかるがカットしちゃうというのは聞いたことがない
それが「メールマナー」だったというのも聞いたことがない
189 = :
改行なんて文章作ってりゃ普通にするだろ。
小学校の作文から始まって、wordでも見やすいように改行するのは習慣。
日本人が潜在的に意識してるのはA4だ。
190 = :
カット(truncate)するメーラーは俺も知らないが
たしかにRFC2822にはそういう実装してるメーラーにも一応配慮しようぜと書いてるな
こっから先は想像だから適当に読み流して
カットしてしまうというのは今の感覚では理解できない実装だが
コンピュータリソースが超貴重な時代においては
例えば糞でかいバイナリデータ(=改行コードがない)等の誤送信を考慮して
こういう実装も一理あったんじゃないかと思うね
78バイト以降カットっていうのはメッセージの完全性を
著しく損なう可能性のある厳しい制限だが
1バイト単位でリソース切り詰めてた時代からメールは使われてたわけだし
フェイルセーフの発想でこうなったというのは十分考えられるね
191 = :
そんなに若そうにも見えないが…
メーラーではなくsmtpが手紙として文字数を規定した
それでMIMEなど他の仕様もそうなった
1000の根拠は適当だろう
192 = :
RFCを持ち出すまでもなくメールとBBSの書き込みを混同しこじつけているだけである
論理の飛躍も散見される
193 = :
何でWebでWordを持ち出すんだろ
HTML文書で30文字毎にbr要素を挿入したら笑われるぞ
194 = :
場合による。
ケータイだったらちょうどいいかもしれない。
195 = :
>>194
ケータイやスマホでそれやると1文字だけとか2文字だけの行が多発して
目も当てられない惨状になるよ
まあメールならしょうがないかとも思うが
HTML文書でそんなサイトがあったらちょっといただけない
「場合による」からこそ成り行きで改行させたほうがええよ
196 = :
ウェブサイトでもちょっと前は、リキッドレイアウトにするべきだって
言っていたのに、今は最大幅が存在する半リキッドレイアウトだからな。
完全なリキッドだと横に長くなり過ぎで見づらい
197 = :
>>195
ガラケー用Webページもそうだったけど
キャリアがうまいこと処理しろよ、100歩譲ってモバイルのUAが処理しろよって話なんだよな
別にいただけなくもなんともねーよ
198 = :
>>197
「30文字毎にbr要素を挿入」してるHTMLのレンダリングを
どうやってキャリアがうまいこと処理すんだ
199 = :
>>197
キャリアとUAとんだとばっちりw
200 = :
まあ「うまいことやる」=「一定ルールでHTMLを自動改変して表示する」だから
ある程度上手くやっても
勝手に変換すんなよとか独自ルールやめろよくそがとか間違いなく言われる
キャリアが勝手に独自仕様作って「これに沿って対応してね☆ミ」とどっちがマシかはわからん
類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.108 + (1001) - [97%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
トップメニューへ / →のくす牧場書庫について