「mysql concat null」でググると、
という至極当たり前のことをさも大発見かのように語る記事が多く、「どうしたらいいか」について触れられていないものばかりを開いてしまった。
おそらくワタクシメのヒキが悪かったせいで、ちゃんと対処法も書いてある記事もあったに違いない。
まーでも対処法を書いた記事が多くなったほうが良いであろうと考え、本記事を執筆することにした。

なんて偉そうなことを言っているんでしょうか私は…。
『CONCAT_WSも知らないくせに』とか思われるのかな。
ま、いっか。

しかし、掲題に結論を書いてしまったので、もう書くこと無いね。
まあ一応結果でも書きますか。

SELECT CONCAT('hoge', null, 'fuga');

　↓

NULL

SELECT CONCAT_WS('', 'hoge', null, 'fuga');

　↓

hogefuga

CONCAT_WS() では、空の文字列がスキップされません。 ただし、区切り文字引数のあとの NULL 値はすべてスキップされます。

今回のように区切り文字を空文字にしていると同じになるけど、区切り文字を指定した場合に違いが出る。

SELECT CONCAT_WS('&', 'hoge', '', 'fuga', 'CHAKE', null, 'YASUKA');

　↓

hoge&&fuga&CHAKE&YASUKA

引数のhogeとfugaの間に空文字が入っているのに対し、CHAKEとYASUKAの間にはnullが入っています。
すると返り値では、hogeとfugaの間には「&&」と&が2つ重なってしまっています。
対してCHAKEとYASUKAの間は&が1つで「CHAKE&YASUKA」となっていますね。

結論から言うと、↓この記事の通りです。

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]" />

でも発動。

親切のつもりが、場合によっては迷惑になる…。
これで便利になって皆に喜ばれる、と思って作ったら『小さな親切余計なお世話』なんて言われたら切ないよね(´Д⊂ｸﾞｽﾝ
うーむ、難しいなぁ。

まさにコレなんだけど。

アカウント連携の解除について、Messaging APIに対してrequestを送信する必要などはなく、連携解除の際にはサイト側で持っているデータのみの削除で完結します。

まー、頭が凝り固まってると、ダメだねー。
LINE連携の解除というと、スマポアプリ側で設定することが思い浮かんで、この操作をAPI経由でやるにはどうするんだ？と考えた。
一度そういうアプローチをしてしまうと、軌道変更って難しい。
でも、答えを知って目からウロコ。
Webサービス側が持ってるLINEユーザーIDを破棄すればええんやん。
LINEと我々を結ぶ糸はLINEユーザーIDのみ。これ無しで連携なんてできませーん。
ま、LINEアプリ側には連動アプリとして残っちゃうけどね。
と思ったけど、これを気にするということは、連動解除する画面まで行けてるってことだから、そのまま連動解除すればいいじゃんー、って話だよね。

クレジットカード情報の入力ってタイヘンですよね。
たまにしか入力しないから記憶することも難しいので、入力が必要になった時にクレジットカードを探し出して、見ながら入力しなければならず、たまたま出先だったりして『今手元にない』となったりしますよねー。
いや、私の場合は1枚のカードだけは覚えましたので、そういうことは無いんですけど。それでも入力するのは面倒です。
そんな時、一度入力すれば記憶してくれるんです、そう、Chromeならねっ！
ん？なんか違和感のある文章が生まれたぞ。まいっか。

今回の記事は、そのありがたーい自動入力機能が、意図せず動作して困った、というお話です。
百聞は一見に如かず。この画像を見てもらいたい。

table内にフォームパーツを入れているんだけど、1行目に<th>名前</th>として、2行目以降に<input>タグが入っている。
このinputタグが

<input type="text" id="name_1" name="name_1">

<input type="text" id="name_2" name="name_2">

...

というname属性になっている。「name="name"」が良くないのか？ッと思って

<input type="text" id="hoge_1" name="hoge_1">

<input type="text" id="hoge_2" name="hoge_2">

...

としてみるも効果なし。
タチの悪いことに、「autocomplete="off"」は無視されるらしい。実際無視されましたよ。。。
うーん、何で判断しているのか？
<th>名前</th>…まさかね。。と思いつつこれを<th>名称</th>に変更すると…
出ない！
ではこれは？<th>お名前</th>→出た。
どうやら「名前」を含む文字列ならなんでもござれらしい。
「海老名前に行ったことあるぞー」とかでも出る。

ちなみに、海老名は海老名SAに寄ったことがあるような気がする程度です。って、んなこた誰も聞いてない(^_^;)
しかし、「名前」があるだけでカード情報入力と判定してしまうなんて、どうしたんだグーグル様。
だってカード番号らしき入力欄も無いんだよー。どうしてカード情報と思うかなぁ…

perlreref - Perl の正規表現のリファレンス - perldoc.jp より

アンカー
すべてゼロ幅の表明です。

   ^  文字列(/m が指定されている場合には行)の先頭にマッチします

   $  文字列(/m が指定されている場合には行)の終端もしくは改行の前にマッチします

   \b 単語境界(\w と ￥W の間)にマッチします

   \B 単語境界以外(\w と \w の間か \W と \W の間)にマッチします

   \A 文字列の先頭(/m には影響されません)にマッチします

   \Z 文字列の末尾(省略可能な改行の前)にマッチします

   \z 文字列の本当の末尾にマッチします

   \G 前回の m//g のマッチした場所の末尾にマッチします