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

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

    JavaScript覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
    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を自動改変して表示する」だから
    ある程度上手くやっても
    勝手に変換すんなよとか独自ルールやめろよくそがとか間違いなく言われる
    キャリアが勝手に独自仕様作って「これに沿って対応してね☆ミ」とどっちがマシかはわからん


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

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


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