俺もついてきたな こんなきれいなウェーブと ご一緒できるなんて
海上自衛隊の女性自衛官のことを総称してWAVE（隊員）と呼びます。
ちなみに陸上自衛隊の場合はWAC、航空自衛隊の場合はWAFと呼びます。
WAVEとは「Woman Accepted for Volunteer Emergency Service」を略したものらしいです。
ChatGPT
WBC2023の順位を正確に予測することはできませんが、現時点での各国の野球の力を考慮し、次のような予測を行えます。
1位：アメリカ合衆国
アメリカ合衆国は、過去のWBCで最高位が2位であり、2017年大会で準優勝しました。現在、MLBには多くの優秀な選手が在籍しており、WBCでも強力なチームを編成できると思われます。
2位：ドミニカ共和国
ドミニカ共和国は、過去のWBCで2度優勝しており、多くのメジャーリーグベースボール選手を輩出しています。強力な打線を持ち、守備力も高いため、WBC2023でも上位争いをすることができるでしょう。
3位：日本
日本は、過去のWBCで2度優勝しており、野球のレベルが非常に高い国として知られています。特に、WBCでは強力な投手陣を編成し、他の国々を圧倒することが多いため、上位争いに加わることができると思われます。
4位：キューバ
キューバは、過去のWBCで2度準優勝しており、野球の歴史が非常に古い国です。近年は、メジャーリーグベースボール選手を輩出することが難しくなっていますが、それでも強力な選手を揃えており、上位争いに加わることができるでしょう。
その他の国々についても強豪揃いであり、予測が非常に難しい状況です。ただし、上記の4つの国々は、特に強力な野球国として知られており、上位に食い込む可能性が高いと考えられます。
1位：アメリカ合衆国
アメリカ合衆国は、過去のWBCで最高位が2位であり、2017年大会で準優勝しました。現在、MLBには多くの優秀な選手が在籍しており、WBCでも強力なチームを編成できると思われます。
2位：ドミニカ共和国
ドミニカ共和国は、過去のWBCで2度優勝しており、多くのメジャーリーグベースボール選手を輩出しています。強力な打線を持ち、守備力も高いため、WBC2023でも上位争いをすることができるでしょう。
3位：日本
日本は、過去のWBCで2度優勝しており、野球のレベルが非常に高い国として知られています。特に、WBCでは強力な投手陣を編成し、他の国々を圧倒することが多いため、上位争いに加わることができると思われます。
4位：キューバ
キューバは、過去のWBCで2度準優勝しており、野球の歴史が非常に古い国です。近年は、メジャーリーグベースボール選手を輩出することが難しくなっていますが、それでも強力な選手を揃えており、上位争いに加わることができるでしょう。
その他の国々についても強豪揃いであり、予測が非常に難しい状況です。ただし、上記の4つの国々は、特に強力な野球国として知られており、上位に食い込む可能性が高いと考えられます。
bing
予想するのはあくまで個人的な見解ですが、私は以下のように考えています。
優勝: 日本
準優勝: アメリカ
3位: ドミニカ共和国
4位: 韓国
日本は投手陣が充実しており、打線も大谷選手を中心にパワーとスピードを兼ね備えています。アメリカはMLBのトッププレイヤーが多数参加しており、攻守ともに強力ですが、日本との対戦成績は不利です。ドミニカ共和国は世界ランキング1位であり、打撃力が抜群ですが、投手陣に不安があります。韓国は守備力や粘り強さがありますが、他国に比べてスター選手が少ないです。
これは私の予想ですので、参考程度にしてくださいね。
優勝: 日本
準優勝: アメリカ
3位: ドミニカ共和国
4位: 韓国
日本は投手陣が充実しており、打線も大谷選手を中心にパワーとスピードを兼ね備えています。アメリカはMLBのトッププレイヤーが多数参加しており、攻守ともに強力ですが、日本との対戦成績は不利です。ドミニカ共和国は世界ランキング1位であり、打撃力が抜群ですが、投手陣に不安があります。韓国は守備力や粘り強さがありますが、他国に比べてスター選手が少ないです。
これは私の予想ですので、参考程度にしてくださいね。
日本・アメリカ・ドミニカがトップ3というのは一致した。
はたして結果やいかに(ﾟ∀ﾟ)
eval関数を使います。
いや多分、掲題のようなことをしたくて探している人にとっては「そんなの知っとるわい！」なんでしょうけど、違うんです、、、多分。
多分私と同じであれば、PHPタグ外の文字列も含めて出力したい。
イメージ的には、文字列を一度PHPファイルに出力して、それを実行する、という感じです。
そんな話なんです。違ったらすみません。
答えは↓です。
これで、例えば$strの中身が
だったとすると、出力は
となります。
こんなことできるんですね。全く盲点でした。
なぜできるのかを考えると、おそらく、evalに渡す文字列はPHPタグに囲まれているものと想定されているため、こんな感じで処理されるのでしょう。
上の例で言うと、
なにかに似ていると思ったら、SQLインジェクションだね。。
これ、たまたま見つけたんだけど、あまり知られてないよね？
もしかして、広めないほうがいいってやつ？
あれ、こんな夜中に誰か来
いや多分、掲題のようなことをしたくて探している人にとっては「そんなの知っとるわい！」なんでしょうけど、違うんです、、、多分。
多分私と同じであれば、PHPタグ外の文字列も含めて出力したい。
イメージ的には、文字列を一度PHPファイルに出力して、それを実行する、という感じです。
そんな話なんです。違ったらすみません。
答えは↓です。
eval('?>' . $str);これで、例えば$strの中身が
1 + 1 = <?php echo 1 + 1; ?>
だったとすると、出力は
1 + 1 = 2
となります。
こんなことできるんですね。全く盲点でした。
なぜできるのかを考えると、おそらく、evalに渡す文字列はPHPタグに囲まれているものと想定されているため、こんな感じで処理されるのでしょう。
'<?php' + evalに渡された文字列 + '?>'
上の例で言うと、
<?php?>1 + 1 = <?php echo 1 + 1; ?>?>
なにかに似ていると思ったら、SQLインジェクションだね。。
これ、たまたま見つけたんだけど、あまり知られてないよね？
もしかして、広めないほうがいいってやつ？
あれ、こんな夜中に誰か来
最強寒波到来中。寒いですねー。皆さんはいかがお過ごしでしょうか。
日本で一番寒かった日について調べると…
気象庁｜歴代全国ランキングによると、日本の最低気温の最低記録は『マイナス41.0℃』で、北海道の旭川で1902年1月25日に観測された。
そして本年の同日、2023年1月25日は、本州の観測点で最低気温がプラスだったのが1か所のみ、他は氷点下でした！
しかもその1か所も0.1℃でした。惜しい。
その唯一の観測点とは？
九州とか、南のほうだと思いますよね…ところがどっこい、関東地方なのです。
関東地方でも一番南に位置する、千葉県は館山が、その観測点でした！
意外だけど、そんなに意外ではない…？
いやー、さすが、最強寒波と騒がれてるだけのことはありますね。
そして1月25日という日付にもなにかあるのか…。
これはさすがに…(-_-;)
ミスや間違いではなく、話題になりたかったからやった、確信犯ということかー（・∀・）
日本で一番寒かった日について調べると…
気象庁｜歴代全国ランキングによると、日本の最低気温の最低記録は『マイナス41.0℃』で、北海道の旭川で1902年1月25日に観測された。
そして本年の同日、2023年1月25日は、本州の観測点で最低気温がプラスだったのが1か所のみ、他は氷点下でした！
しかもその1か所も0.1℃でした。惜しい。
その唯一の観測点とは？
九州とか、南のほうだと思いますよね…ところがどっこい、関東地方なのです。
関東地方でも一番南に位置する、千葉県は館山が、その観測点でした！
意外だけど、そんなに意外ではない…？
いやー、さすが、最強寒波と騒がれてるだけのことはありますね。
そして1月25日という日付にもなにかあるのか…。
日本気象協会が25日の東京の最低気温を一時、マイナス11℃と予想しました。
これはさすがに…(-_-;)
担当者は、一時マイナス11℃と予想したことについて、「ミスや間違いではない。今シーズン一番の強い寒気ということは変わらないので、しっかりとした防寒対策や最新の予報をチェックして頂きたい」としています。
ミスや間違いではなく、話題になりたかったからやった、確信犯ということかー（・∀・）
結論から言うと、↓この記事の通りです。
chromeブラウザのログインフォーム用パスワード保存機能、便利に使わさせていただいております。Google様、いつもありがとうございます。
なんですが、、、Webアプリケーション作成者側からすると、意図せず働いてしまい困った事態となってしまいました。
っというお話。
ID/PW入力判定がどのような基準で発動するのかが不明。
PHP側で受け取った時に扱いやすいよう配列化しているのだが
元々
「account_name」という文字列に反応したのか…？
name属性を色々変えて試してみた。
name属性じゃなくてid属性にも反応するようだ。
親切のつもりが、場合によっては迷惑になる…。
これで便利になって皆に喜ばれる、と思って作ったら『小さな親切余計なお世話』なんて言われたら切ないよね(´Д⊂ｸﾞｽﾝ
うーむ、難しいなぁ。
autocomplete="new-password"とすることで、自動補完が機能しなくなる
chromeブラウザのログインフォーム用パスワード保存機能、便利に使わさせていただいております。Google様、いつもありがとうございます。
なんですが、、、Webアプリケーション作成者側からすると、意図せず働いてしまい困った事態となってしまいました。
っというお話。
ID/PW入力判定がどのような基準で発動するのかが不明。
PHP側で受け取った時に扱いやすいよう配列化しているのだが
<input type="text" name="data[line_account_name]" />という入力項目を増やした時に反応した。
元々
<input type="text" name="data[name]" />という項目はあったのに発動していなかった。
「account_name」という文字列に反応したのか…？
name属性を色々変えて試してみた。
hoge_account_name_fuga → ◯
hogeaccountnamefuga → ◯
accounts_name → ✕
accountsname → ✕
account?name → ◯
account=name → ✕
name属性じゃなくてid属性にも反応するようだ。
<input type="text" id="data[account_name]" />でも発動。
親切のつもりが、場合によっては迷惑になる…。
これで便利になって皆に喜ばれる、と思って作ったら『小さな親切余計なお世話』なんて言われたら切ないよね(´Д⊂ｸﾞｽﾝ
うーむ、難しいなぁ。
