読者です 読者をやめる 読者になる 読者になる

mogami74開発日誌

フリーライターがPHPとかJavaとか勉強してます

headタグの中身が見えてしまったら

HTML CSS

同級生SさんからのSOS。

head要素の中身、特にtitle要素とscript要素の中がブラウザに表示されてしまうのだという。同級生の中でもデキるSさんからのSOSなので、まさかそんな、と思いながら画面を見せてもらった。(画面はサンプル)

f:id:mogami74:20170317034112j:plain

たしかにtitle要素の中身、本来、ブラウザウィンドウのタブ上にとか、ウィンドウバーに表示される内容が、ブラウザの画面内にも表示されている。タブ上にも表示されているので、title要素としての機能は生きている。meta要素などは画面にこそ表示されないが、やはり機能は正常。

タグの綴りミスなども見て見たが、間違っているように思えない。

私が画面を見て首を捻っていると、同級生が集まってきて検討に加わった。

才気あふれるKくんがふと「display:noneにしてみたらどうなるんですかね」と言った。

解決編

開発者ツールでtitle要素に「display:none」を指定してみると、ちゃんと消えた。それどころか、もともと「display:none」という指定があったのが、打ち消し線で「無効」になっていたのを発見した。

無効化された「display:none」の出所は「user agent stylesheet」つまりブラウザのデフォルト状態だ。

f:id:mogami74:20170316164543j:plain

謎はすべて解けた。

そもそも、ブラウザはデフォルトのスタイル指定を持っている。padding やmarginの指定がブラウザによってまちまちなのはよく知られており、それをリセットするための「リセットCSS」といった考え方も存在する。

実は、head 要素やtitle要素のデフォルトのスタイル指定が内部に存在し、それは「display:none」になっているらしい。逆に、普通のhtmlページで、head要素とtitle要素に「display:block」を指定すると、Sさんのページと同様、title要素の中身を表示することに成功?した。

実はmeta要素も「display:block」されていたのだが、meta要素はそもそも空要素のタグで閉じタグがないので、innerHTMLが存在しない。だから画面上に表示されるものがないのだ。title要素やscript要素はinnerHTMLがあるので、表示されてしまう。

Sさんのスタイルシートを確認したところ、リセットCSSの一環として、全称セレクタで「display: block」を指定していたことが判明。

html * {
    margin:0;
    padding:0;
    display:block;
}

なるほど。これがそんなふうに出てくるとは思わなかった。勉強になった。

オブジェクト指向とUML

Java UML オブジェクト指向 MVC

仕事先からもらった資料でオブジェクト指向の勉強中。だいたいは知っていることだけど、時々は知らないことも出て来て勉強になる。

カプセル化情報隠蔽

  • カプセル化……データと操作をひとまとめにして扱うこと。
  • 情報隠蔽……データへの直接アクセスを阻止すること。

これまで両方ひとまとめにしていた(資料では「そういう技術書もある」と補足されていた通り)ので、カプセル化の概念がいまひとつわからなかったが、これで合点がいった。

汎化(継承)と拡張(extends)

もらった資料では継承と拡張の違いがよくわからなかったので検索して調べた。

www.itsenka.com

汎化

「is a」関係、つまり、「ユースケースB is a ユースケースA」または、「アクタB is a アクタA」の関係が成り立ちます。

拡張

ユースケースAに対して、機能を追加するようなユースケースBの関係を示します。

なるほど。汎化の場合は、「〜のうちの一種」という関係で、抽象化の逆になる、ということか。

また、アクター間でも汎化が使える、というのは新しい気づきだった。オブジェクト側でばかり考えていた。これまで、アクターが汎化されるようなケースでいろいろ悩みがちだったので。

抽象クラスとインターフェイス

  • 抽象クラス……データ項目と抽象操作をまとめたもの。

  • インターフェイス……抽象操作のみをまとめたもの。

Enumulateインターフェイスとか、よくわからず使っていたけれど、なるほど、抽象操作(メソッド)という観点で把握すればいいのか。

ユースケース記述

ユースケースの内容を詳細に記述する。このDescriptionsから処理を書き起こしていけばいいわけで、わかりやすい。これまでユースケースから「えいや」でそのまま処理を起こしていたので、自分でも「どうも大雑把だな」と感じていたし、先生にも「関数化が未熟」と指摘されていた。ここのところをきちんとやれば改善されそう。

シナリオ記述も同様。

ロバストネス分析MVC

  • ロバストネス分析……エンティティオブジェクト、バウンダリオブジェクト、コントロールオブジェクトで分析する手法。らしい。

  • バウンダリオブジェクト……アクターとシステムの接触点を示す。画面とか。これはMVCのViewになると思われる。

  • エンティティオブジェクト……現実世界のオブジェクトを表現する。これは主にMVCで言うModelになると思われる。

  • コントロールオブジェクト……ユースケースに対応する。ユースケースの完了と同時に消滅する。

この説明のおかげで、MVCの意義がやっとわかってきた。というかコントロールオブジェクトの意義がやっとわかってきた。コントローラにすべての機能を渡すのは「fatty(肥大化) controller」として嫌われるというのはまぁ分かるんだけど、こういう基準があれば、fattyかどうかの判断がしやすい。

管理オブジェクトというのもあるらしい。オブジェクトの生成や削除を管理し、リストを持つことで外部からの利用が便利になる。これもなかなか為になる。

追記

必ずしもロバストネス分析MVCと一致するわけでもないらしい。

https://inoccu.com/blog/2014/01/26/153315.htmlinoccu.com

さくらのレンタルサーバーからメール送信する

PHP さくらインターネット 改行コード シングルクォート ダブルクォート

PHPでHTMLメール送信

フォームで情報を入力してもらった際、PHPから同時にメールで情報が飛ぶようにしたい。せっかくだからHTMLメールを送信できるか、試してみよう。

ameblo.jp

メール届くだけならこれで届いたんだけど、まだ中身がぐちゃぐちゃ。むむむ。 ということで、もう少し情報を探してみる。

タイトルからしてキャッチー。nice html email、まさにそれだよ私が送りたいのは。

Sending Nice HTML Email with PHP | CSS-Tricks

\r\nってのは改行コードだよなこれたぶん。

charsetの指定、海外サイトだとちょっと不安だったので日本語のサイトを探した。 coliss.com

techblog.ecstudio.jp

ちゃんと情報は届いたんだけど、htmlタグがそのまま見えちゃう。うーん、何が問題なんだ? 

mb_convert_encodingのエラー

いくつかいじっているうちに、「mb_convert_encoding(): Illegal character encoding specified」のエラーが出てしまった。むむむ。悪化してるじゃん。

apocriphanet.blog17.fc2.com

qiita.com

この辺り参考になる。

どうも、mb_convert_encodingの文字コード指定に間違えて変な文字列を書いちゃっていたみたい。

mg_internal_encoding(“UTF-8”)にしてmb_convert_encoding(‘From:hoge@hoge.ne.jp\r\n’,‘JIS’,‘EUC-JP’)にするととりあえずエラーはおさまった。

メールのソースを比較

自分のところに正しくhtmlで届いているメール(たとえば、Pinterest)と、htmlソースが見えちゃうメールのオリジナルソースを比較してみた。

あれ、Content-Typeがtext/plainになってしまっている。おかしいな。ちゃんとtext/htmlで書いてるんだけど、反映されてない。

よく見ると、From行から後の改行コードが認識されず、\r\nでつながっちゃっている。改行コードが問題か。

blog.poyo.jp

ちゃんと\r\nで記述しているのだけれど、オリジナルソースの方は「From:hoge@hoge.jprn MIME-Version":1.0\r\n」のように、最初のFrom行の末尾のバックスラッシュが認識されずに溶けてしまっている。なんだこりゃ。半角アキを入れたりしてみたが、効果無し。

php mb_send_mail 改行コード バックスラッシュが消える」で検索して、いくつかポチポチ見ていたら、答えが見つかった。

www.tryphp.net

おお。シングルクォートのせいか。無意識にシングルクォート使ってたから気づかなかったわ。

いくつか阿呆な記述ミスを修正したら、無事、HTMLパースされたメールが届くように。やったー!

いくつかの記事で「CSSはインラインで書くように」とあったけれど、Pinterestのメールはスタイル要素使ってヘッダに書いているようなので、その辺は今後の研究ということで。

jsonデータを開いて連結する

PHP MySQL RestaurantDB

json_encode()で作ったデータをつなぎたい。

最初はMySQLのクエリでLEFT JOINしようとしたんだけど、欲しいデータが2重ループみたいな感じになっている。

foo1
 bar1
 bar2
foo2
 barA
 barB
 barC

MySQLのLEFT JOINで作ると、1段階目のデータが重複してちょっと扱いづらい。まぁ重複して出て来たデータは無視すりゃいいんだけども。

foo1 bar1
foo1 bar2
foo2 barA
foo2 barB
foo2 barC

MySQLの結果もらってfetchで回す時に、2重ループ作るしかないか…。

while($result1=$stmt->fetch(PDO::FETCH_ASSOC)){

 echo json_encode($result1);
 while($result2=$stmt->fetch(PDO::FETCH_ASSOC)){
  echo json_encode($result2);
 }

}

いや、待てこれもダメだな。json_encode($result1)の中にjson_encode($result2)を入れてやらないといかんのだな。$result1開いて書くしかないか……。

echo "{";
while($result1=$stmt->fetch(PDO::FETCH_ASSOC)){

 echo $resutl1['hoge'];
 echo $result1['honya];
 while($result2=$stmt->fetch(PDO::FETCH_ASSOC)){
  echo json_encode($result2);
 }

}
echo "}";

……正直めんどくさいけどしょうがないか。

開発日誌を書くことにした

PHP JavaScript Java さくらインターネット WordPress MySQL JSP Servlet

web上の情報を集めていく時に、案外思った通りのものが見つからないで苦労する場合もあるので、そうしたことをメモしておくことにした。自分のためにも、誰かのためにも。

英語で書いてもいいかもしんないなー、とか思ったり。思わなかったり。