Studio TA Subsite の案内とお知らせ

カテゴリ:PC環境(ハード/ソフト)( 66 )

訂正箇所をHTML編集画面ですぐに見つける方法

2017年 09月 23日
普通の投稿では余り長文にならないので、この話は少し特殊でしょう。

スキンアレンジなどでCSSコードを扱う場合、全文がとても長くなります。 また、HTML編集画面は、コードとタグが入り乱れて来ます。 こんな投稿を扱っている時に、「通常編集」で訂正したい場所を見つけ「HTML編集」で訂正しなければならなくなった時の問題です。

「通常編集」と「HTML編集」の画面は、スクロール位置は全く連動していませんから、その箇所をHTML編集画面の中で探すことになります。 これが短い投稿文なら簡単ですが、「入り乱れた」投稿文の場合、なかなか探すのに苦労したり、勘違いして別の所を弄ってしまう事があります。

編集画面のアレンジをしているので、CSSでこれを改善する方法を考えたのですが、Javaスクリプト等を使わないと難しい様です。 で、ブラウザの検索機能を使った代案の覚え書きです。



先ず、普通は使わない文字で、主要フォントからマークに利用する文字を探します。 Windowsなら「文字コード表」で探せば、沢山候補があります。

a0349576_22540594.png

これをIMEに文字登録します。 私は1文字登録を良く使いますが、この場合は「た」の読みで「❖」のマークを登録しました。「た」と打って変換すればこのマークが直ぐに出る様にしたわけです。

「通常編集」で訂正したい場所を見つけたとして、その近辺で、後で処理がし易い場所にこのマーク文字を書き込みます。 下図はその例で「❖」を書き込んでいる所です。

a0349576_22403327.png

「HTML編集」に切り替えます。 Chromeでは「F3」を押すと、下図の様に検索窓が出ます。

a0349576_23045242.png

ここで、先の「❖」を打ち込み、「Enter」を押すと、自動的にこのマーク行までスクロールします。「❖」を消して「訂正箇所」を修復すれば、目的を達するというわけです。



Chromeで実際に試すと、「HTML編集」に切り替えてから、「F3」「た」「↓×2」「Enter」で、目的の行に到達しました。 慣れると、実用的なテクニックに出来そうです。 編集画面自体に、簡単にワープできる機能があれば良いのですが、ブログ編集画面ですからね。




この記事はカテゴリ「スキン編集」にトラックバックしています。



[PR]
by Ataron | 2017-09-23 23:31 | PC環境(ハード/ソフト) | Comments(0)

ログインできなくなった時の防備録 / エキサイトブログ

2017年 08月 08日
IE11のセキュリティ設定を色々触っていると、エキサイトブログにログインできなくなりました。 いや、正確に言えば、半分ログインしている状態です。

症状は明らかです。 ログインしていないと出来ない作業をしようとすると、エキサイトブログのトップページに飛ばされます。 要するにログインしろという事です。

a0349576_12094754.png

で「ログイン」を押してログインのページに入ると、既に「ログイン状態」になっています。

a0349576_12132613.png

この二つのページを往復しても、また一旦ログアウトしてやりなおしても、先に進めません。

これは、エキサイトブログ向上委員会のコメントの中で、時々見かけるトラブルです。 危機こそ好機なりと、かたっぱしから条件を変えてテストしてみました。



エキサイトのヘルプでは「Cookie」の削除を解決策の最初に書いています。


〔Cookieのリセット〕
IE11の「歯車マーク」から「インターネットオプション」を起動。

a0349576_12173232.png

最初のタブページ「全般」→「閲覧の履歴」で「削除」を押すと、下のダイアログが出ます。

a0349576_12212724.png

「クッキーとWebサイトデータ」にチェックを入れて(他は不要)、下の「削除」を押します。



〔サイトのプライバシー管理〕

次に書かれた対策です。「プライバシー」のタブページを開き、「サイト」をクリックします。

a0349576_12275176.png

ここで開くダイアログで、「exblog.jp」「excite.co.jp」の2ヵ所のドメインネームが登録されている必要があります。 ドメイン表記で、上の太字の通りでないとダメです。

a0349576_12313939.png



〔信頼済みサイトの登録〕

今回、これが効果がありましたが、IE11を起動すると初回だけはトップページに飛ばされる症状が残りました。「セキュリティ」のタプページで、一番上のゾーン選択で「信頼済みサイト」のアイコンをクリックします。 このページの設定は、4つのゾーンで別個の登録になっていますから、どのゾーンの設定か混乱しないでください。

a0349576_12380920.png

デフォルトで「信頼済みサイト」は下方の「保護モードを有効にする~」にチェックがないはずで、チェックが入っていたら外しておきます。 その上で、上図の「サイト」ボタンを押します。

信頼済みサイトのダイアログが開きます。 ここで〔サイトのプライバシ管理〕と同様に「exblog.jp」「excite.co.jp」を登録。 登録後に一度ダイアログを閉じ、もう一度開くと下図の様に「*.exblog.jp」「*.excite.co.jp」に変わっていました。 この登録枠はURL形式なので、適した形に変えられた様です。 下の「サーバーの確認」は、この形の登録なのでチェックなしです。

a0349576_17050569.png


これで一応ログインができる様になりましたが、妙な事にIE11を起動してから初回だけトップページに飛ばされる症状が残りました。 2度目編集画面に入る時は、問題ないのです。 しかし、元はトップページに飛ばされる事など無かったので、まだ変なわけです。



ここで、もう一度挑戦しました。

〔サイトのプライバシー管理 登録削除 そして 再登録〕

私のこの「プライバシー」の登録、実は最初から登録していました。 その状態での不具合だったので、「信頼済みサイト」の方を登録したのです。 しかし未だ完全ではないので、一度「プライバシー」の登録を削除してみました。 IE11を一旦閉じて再起動し、この「プライバシー」の登録をやりなおした所、トップページに飛ばされることが全くなくなりました。

最初から、この作業だけで良かったのかも知れません。 先ほどの「信頼済みサイト」の登録は削除しましたが、問題なくログインが出来る本来の状態になりました。



今後SSL化で、再び登録の内容が問題になるかも知れません。 またログインできなければ、なんとでも出来そうな気がします。 一度ひねくれてしまったシステムをいかにリセットするか、そんな問題に思えます。 今回の私のアガキ方、難儀している方の参考になれば幸いです。




この記事はカテゴリ「ブログ」にトラックバックしています。



[PR]
by Ataron | 2017-08-08 13:20 | PC環境(ハード/ソフト) | Comments(0)

Win10 カーネルこちょこちょイジったの?

2017年 07月 25日
しきりにアップデートの要請が出るので、Win10を再起動すると、やたらと時間がかかっています。

a0349576_21393413.png

暇だから画面のハードコピーを取ったが、再起動してクリップボードは飛ぶかなと思ったら、何故か上の画像が残ってました。 実際、数十分は何かやっていたので、これはカーネルまで弄ってるなと訝ったのですが、実際はどうでしょう。

●テキスト編集の時に画面中央に文字入力のポップアップが出る様になった
調べてみると、これはIMEの新機能で、嫌ならOFFに出来る様です。 タスクバーのIMEを右クリックして、下図の様に進むと表示のON/OFFの選択が出ます。 末行の「精細設定」で本来のダイアログが出る様に変更されてます。

a0349576_21394674.png

以下のサイトに目ぼしい変更点の内容と、それらの対処方法を整理してくれてます。 よくお世話になるサイトです。


●「コントロールパネル」がメニューの底に行ってしまった
OS設定の管理にコンパネを使うデザインは時代遅れとの判断なのか、フムフム。 まあ、設定はなんとでもアクセス出来るからいいけど。

●IE11に「Edge」を開くタブが勝手に付いた
こんなタブは要らないな。 そんなのするなら、早くEdge標準のユーザースタイルシート機能を作って欲しい。 もう1年も待ってるけど、Edge専用アプリを探してもその影もありません。 勝手に作れって? 私、そこまで詳しくないのです。 まあ、そんなのが揃わない間は宣伝をしても、Edgeユーザーは増えないと思う。

こんな事が、今回の感想。 アップデートは欠かせないですから。



[PR]
by Ataron | 2017-07-25 13:44 | PC環境(ハード/ソフト) | Comments(0)

エキサイトブログの常時SSL化に関する要チェックポイント

2017年 06月 07日
2017年夏にかけてエキサイトブログの常時SSL化が実施される様です。 最初の告知は以下です。
エキサイトブログは、余りアレンジユーザーは多くなさそうですが、そういったユーザーでなくても、SSL化によって自分のブログページの問題が生じないかは、SSL化の実施の過程でチェックした方が良い様に感じます。 私が知り得るポイントで、SSL化で最も問題になりそうな事は、URLが「ブログ記事」や「スキンコード」に記述されている場合です。

SSL化(安全対策化)されたブログページで、外部ファイルを参照する「http://」のURLが記述されている場合、ブラウザが警告を出す場合があるという情報もあります。 その場合、外部ファイル取得やリンク先へのジャンプに関して、ユーザーの選択を求める形が予想されますが、実際には常時SSL化が実施されてみないと判りません。

b0174191_09522169.png



〔ブログ記事上の外部リンク〕
例えば、YouTube動画の埋め込みで、動画コード内に「src="http://www.youtube.com.~」等と「s」抜きURLを書き込んでいる場合があります。 このブログページがどんな表示になるのか、動画は表示されるのか、今の所は不明です。 但し、エキサイトの編集アイコンでYouTube動画を埋め込んだ場合は、「src="//www.youtube.com.~」となる様で、これは問題が生じないでしょう。

動画に限らず、外部サイトやその記事などのリンクを記述していて、そのURLが「http://」である場合は、ブラウザで警告表示されるのでしょうか?

〔ブログ記事上の自ブログ他ページへの相対パスリンク〕
自分のブログの他ページへのリンクのURLを、相対パス表記で「href="/xxxxxxxx/"」等としている場合は、問題はないでしょう。(xxxxxxxxはブログ記事番号)

〔ブログ記事上の自ブログ他ページへの絶対パスリンク〕
エキサイトは「以前に投稿した記事(httpのURL)へのリンクは、そのままで問題ございません」としていますが、これはデスクトップに置いたリンクや、全く別のサイトに置いたリンクの事で、それらをたどる際は「https」にリダイレクトされ、ちゃんとページが表示されると言っているだけの様に見えます。(それは、システム側で可能な基本的なリダイレクトですから)

しかし、自ブログ他ページへのリンクのURLを、絶対パス表記で「href="http://~~"」等としている場合、参照先がリダイレクトされれば「https://」という所までブラウザが解釈してくれるか、或いはシステムがフィルターをかけてエキサイトブログのURLは「s」付きとしてブラウザに読ませるか、など、実際にSSL化されないと判らないものです。

〔ブログ記事上のリッチリンク〕
これは「src="//bp.exblog.jp/richlink/」という相対パス表記ですから、問題は生じないでしょう。

〔ブログ記事上の画像〕
普通に設置した画像はエキサイトの特殊タグで扱われ、その元はエキサイトの画像サーバのURLです。 現在のURLは「http://pds.exblog.jp/」ですが、SSL化以降は「https://」になり問題を生じないでしょう。 但し、特殊に外部の画像ファイルのURLをリンク先として記述している場合は、問題を生じ得る可能性があります。

〔ブログ記事上のジャンル(バナー)やライフログ〕
「href="http://www.exblog.jp/genre/」「src="http://md.exblog.jp/img/」「href="http://item.excite.co.jp/」等が使われていますが、SSL化以降は「https://」に変わると思います。 昔のページに配したこれらは、記述が「http://」のままでも、ページを表示した際は自動的にリダイレクトされ、問題はなさそうに思います。

〔ブログ記事上のマップ〕
埋め込まれるのはマップ機能の特殊コードで、問題は生じないと思われます。 ちなみに、Google Map のリンクコードは以前より「https://」で、それを埋めこんでいる場合も問題ないはずです。



〔ブログパーツなど〕
一例で私が使用しているユニクロカレンダーは「src="http://www.uniqlo.com/」を参照しています。 このパーツの動作はどの様になるのか? 他にも「http://」サイトを参照する埋め込みブログパーツはあるでしょう。

フェースブックボタンは「https://」参照ですが、各所に出て来る「Yahooの宣伝」は「http://」参照です。 これらはどうなるのか、無くなりはしないでしょうが。



〔スキン上のリンク〕
スキンのHtmlやCSS上に記述されたURLはどう扱われるのでしょうか? 公式スキンの場合は、書き込まれたURLは、おそらく殆どが背景や枠などのデザイン用の画像パーツでしょう。 参照対象のURLは「S」付きになるわけですが、スキン側の書き換えをするか、自動的なリダイレクトが働くので既存スキン書換えは無いかも知れません。私は後者を予測しますが。

スキンアレンジを施しているユーザーは、そう大した作業でも無いでしょうから、URL記述ヵ所を検索して「https://」に書き換える事をお勧めします。 エキサイト内のURLを参照するものである限り、問題は生じないと予測しますが、僅かでも表示スピード上でプラスになるかも知れません。



以上、常時SSL化が実施されたら、チェックしておきたい部分を挙げて整理しました。 私は、上記で「」を付けた項目は要チェックと考えています。



〔追記〕2017.06.08
URL表記の型式で調べると、「http://」「https://」等はそのURLのサーバーが通信する「プロトコル」を表すとあります。 現在のブラウザは、通信プロトコルを自動的に判断するので、一般にこの部分を省略したURL表記でこと足りるのでしょう。 今後、エキサイトブログに絶対パス表記でリンクを置く場合は、「//~~~」という表記型が間違いないと思います。

〔追記〕2017.06.12
私は編集画面アレンジにユーザースタイルシートを使用しています。 そのコード中のアイコン画像のURL指定では、IE版に限り「http://~」でないと無効になります。 Chrome版(Stylist拡張機能使用)では「//~」型が有効でした。 これは、CSSそのものより、それを扱う環境(ユーザースタイルシートの環境)に関係する様な気がします。 IEは一番気難しいのは他の事でも頻繁に経験しますから。

一方、CSSで一番皆んなが利用しているのがブログスキンですが、こちらのCSSに書き込んだ「http://~」型のURL指定は「//~」型に書換えても全く問題ない様です。 ブログスキンのCSS(Htmlも)は、エキサイト内部で先ず読みだされるからの様な気がします。 自分でアレンジしている場合は、ブログスキン上の「http://~」表記は、予防的に「//~」型に書き換えて良いと思われます。

〔追記〕2017.07.25
エキサイトの新しい告知がありました。
「ブログパーツで無効になる種類がある」「バナーの更新が必要なのがある」は、予想されていましたが、過去記事に貼った「バナー」も張り替えが必要な様に思えます。 サイドメニューならブログスキンの書き換えで簡単ですが、多数の過去記事内に貼っている方は、いちいち記事の再編集になりそうです。 これは諦める人が多いかも。

文句が沢山出そうですが、これは自ブログのシステムを見直す良い機会になると思います。



[PR]
by Ataron | 2017-06-07 14:00 | PC環境(ハード/ソフト) | Comments(0)

エキサイトブログ編集のツボ 画像を越えられないカーソルと消えるカーソル

2017年 04月 09日
ブログ編集をしていて最近気になった事は、文末の編集でカーソルが一時的に消失してしまう現象です。 通常編集を専らとするChromeユーザーは経験しているかも知れません。 IE11ではカーソル消失は無い様ですが、文末で先にカーソルを進め難い事は同様にあります。 いずれも、エキサイトブログの文書編集枠(通常編集)の特性とブラウザの仕様が絡まった問題に思えます。



今回の事象が一番良く判るのは挿入画像の前後ですが、ブロックや表等でも同様に生じます。 以下の説明はブラウザがChromeですが、IE11もほぼ同様です。


①最初は、編集中に画像を文末に中央配置で挿入したとします。

b0174191_21273796.png

上図の様な位置にカーソルがある場合、キーボードだけでは下図の様になって画像の後方に文字を書くことができません。

b0174191_21293546.png

もちろん、この場合はマウスでカーソルを画像の後方に置ければ解決します。

b0174191_21374901.png

b0174191_06272101.png



➁上記は画像が中央配置でしたが、左寄せや右寄せの場合は話が違います。 下図は、文末に挿入した画像を左寄り配置にした場合です。

b0174191_21410073.png

運よく画像の後方に何か文字や改行等が入っていた場合は、下の様に画像の側面(Html上は画像の後方)の先の部分にカーソルを進める事が可能です。

b0174191_21420505.png

しかし普通は、マウスを使ってもカーソルを画像の後方に置けません。

b0174191_21475278.png

こうなると、画像を中央配置にしてマウスで先に進めてから左寄せにするか、HTML編集で先を書く(HTMLでは確実に後方に進める事が可能です)しか無い様です。


➂最初の①の場合に、時々妙な状況に出会う事があります。

現象を確かめるには、①の状態で画像の後方にカーソルが置ける場合に、「Backspace」「Delete」で画像以降の入力を全て削除します。

b0174191_06474934.png

編集時に案外とこの様な状況にはならないのですが、この状況になると、マウス操作でもカーソルを画像の後方に置けない現象が生じます。

この場合、一般的にはHTML編集で、画像の後方に文字を書き込んで解決します。 しかし、HTML編集を開くのが面倒なら、画像配置のメニューを出して抜ける手があります。 これは以下に説明します。


④「カーソル消失」はChromeでのみ生じる様ですが、編集画面にスクロールバーが出る長さの文書の末尾に画像がある場合で、➂と同様に画像の後方に何の入力も無い状態で生じます。

下図は、➂と同様に画像以降の入力を綺麗に削除した状態で、画像の横に長いカーソルがあります。

b0174191_22001707.png

この時、マウスを使ってカーソルを置ける場所は、下図の ❶➋の場所か より手前の部分です。 また、右のスクロールバーはこれより下方が無い表示です。

b0174191_22063605.png

この状態になると、画像の後方にカーソルを置く事が出来ません。 以前の「画像周囲での文字入力」で採り上げていますが、❶➋の場所で文字を書いたり改行をするとややこしい事になります。 この状態はHTML編集で切り抜けるのが普通ですが、通常編集内で先に進む方法があります。

●先ず画像をクリックして画像位置指定のメニューを出し、無意味な様ですが位置指定「中」を押します

b0174191_22154636.png

この操作で、下図の様にスクロールバーが動き、文書の最下端が伸びた事が判ります。

b0174191_22180313.png

マウスのホイール等で文書の最下端を表示させ、下図の様にグリーンのあたりをクリックして、画像の後方にカーソルが置けないかを試します。

b0174191_22195305.png

●状況が変わらず、先の❶➋の場所にしかカーソルが置けないなら、素直にHTML編集に行った方がよさそうです。 しかしそうではなく、カーソルが消える「カーソル消失状態」になる事が良くあります。(これが生じる条件の詳細は不明です)

その場合はキーボードで「Enter」を入力すると、画像の後方にカーソルが現れます

以上の操作のコツを覚えれば、HTML編集に行く手間が省けます。「Enter」を押す時は、❶➋の場所にカーソルが無いか確かめましょう。




[PR]
by Ataron | 2017-04-09 22:45 | PC環境(ハード/ソフト) | Comments(0)

エキサイト編集画面 ペースト時に無意味なタグ が付加される件

2017年 03月 10日
エキサイト編集画面の「通常編集」で文書を作成して「HTML編集」を開くと、自動的に生成された色々なタグを目にします。 これは、Html生成の編集援助機能がタグを書き込んだ結果で、タグはブログ文面をネット上に表わすために不可欠なものです。

PCブラウザで Google Chrome を利用している場合は、このタグの中で「<span style="font-size: 13px;">」というフォントサイズ指定のタグが、場合によっては多数が書き込まれているかも知れません。(IE11ではこの現象がありません)

これは、同じ「通常編集」の画面内でコピー/ペーストを行った場合などで発生します。 このコードの生成で、ブログの文書の表示や構成に、本質的な問題はありません。 ただ「無意味で余計なコード」が書き込まれて、Htmlを読み難くします。 一般の文書では余り気にならないかも知れませんが、英文やコード記述をしている場合、これはけっこう目障りで邪魔なものです。

以下は、この不要コードが書き込まれてしまう編集操作の2例です。

b0174191_09025090.png
b0174191_09025551.png

この問題に関しては、ブログ編集画面のアレンジを始めた当初に気付き、以下に纏めています。

上の記事の時点で、「編集画面」(textarea)の動作を調べ、問題を一旦は解消出来たのですが、最近に再びこの問題が再現しているのに気付きました。 私の場合は編集画面のアレンジをしているので「<span style="font-size: medium;">」のタグが記入されます。

以前は編集画面のアレンジの関連を認めたので、ユーザースタイルシートによるアレンジをOFFにして調べると、今回は以前とは状況が異なります。 アレンジしない本来の編集画面でも「<span style="font-size: 13px;">」が生成され、これを止める根本的な方法は見つかりませんでした。

このコードが再び入り始めた時期を調べると、今年の2月中旬あたりの様です。 それ以前の記事にコード混入がなく、考えられる原因は、エキサイトのシステム変更、あるいはChromeのバージョンアップですが、どちらにせよ従わざるを得ない問題の様です。



〔Chrome 使用の場合の対策〕

Chrome 使用のPC環境で、この余分なコードの追加を回避する方法は、限られています。
ひとつは「HTML編集」の画面で操作する 方法で、ペースト操作では原則的な一番手堅い手段です。 一方「通常編集」の画面を主に使っている場合は、「プレーンテキストとして貼り付ける」のが簡単です。 この機能は、すでに2016年の段階でChromeに搭載されていた様です。

● Textareaにペーストする際に「Ctrl+Shift+V」のショートカットでペーストします。
または、下の様に右クリックメニューからも可能です。

b0174191_17333747.png

この操作は、ブラウザ上の他ページから、テキストをコビー/ペーストする場合にも有効で、ショートカットキーを覚えておいて損はないでしょう。



〔他のブラウザ使用の場合〕

IE11ではこの様なタプの追加は全くなく、エキサイトのシステムはIEを前提のものという気がします。 しかし、Edgeでは、「<b></b><i></i><u></u><sub></sub><sup></sup><strike></strike>」という、更に意味不明なタグがコピー/ペースト時に追加されます。 Edgeには、プレーンテキストのペースト機能は無く、「HTML編集」を使うか、一旦「メモ帳」にペーストして再びコピー/ペーストするしかなさそうです。


[PR]
by Ataron | 2017-03-10 18:44 | PC環境(ハード/ソフト) | Comments(2)

エキサイトブログにアニメーションGIF画像を投稿し表示させる

2017年 03月 07日
「アニメーションGIF画像」は小サイズで簡単なアニメーションを表示する画像部品として、ネット上の修飾的な表示に良く使われます。 乱用するとページに落ち着きがなくなりますが、説明に利用したい場合は良くあります。 エキサイトのブログ画面はGIF画像を投稿し表示させる事が出来、またブログスキン上でもGIF画像を使う事が可能です。 これは、アニメーションGIF画像も利用できると考えられ、今回これを試しました。



アニメーションGIF画像を作るには、それが可能なグラフィックアプリが必要です。 フリーアプリやサイト上で作成可能なサービスがありますが、私は「Photoshop Elements」を使いました。 ここでは、旧い Ver6.0で説明しますが、以降のバージョンの「Photoshop」「Photoshop Elements」でも同様の機能を搭載している様です。

アニメーションの元画像も「Photoshop Elements」上で作成しました。 最初に背景となる画像を作り、その複製レイヤーをひとつ上の層に作って、アニメーションさせた変形を加え、更にその複製を上層に作り変形させ・・・と繰りかえして行きます。 それらのレイヤーがアニメーションのコマとなります。 アニメーションのコマを作る方法は、色々な方法が考えられ工夫の余地があるでしょう。

下図はサンプルとして、「ファイルをゴミ箱に入れる操作」のアニメーションのコマを作成している所です。

b0174191_10382419.png

コマ(レイヤー)の作成段階での注意点は以下です。
●アニメーションはレイヤーの下側から上側に向かって表示される
●各レイヤーはどれも均等な時間表示される(0.2sec等で時間は調節可能)
●従ってタイミングの調節は、レイヤーを複製して複数並べることで調節する
●レイヤー数が増えても、最終的なGIFファイルサイズは余り大きくならない

以上の要領でコマ群が出来たら、「ファイル」メニューの「Web用に保存」を押します。

b0174191_10391586.png

下図の様な設定画面が表示されます。
●右側の赤枠で囲んだ部分が「アニメーションGIF画像」を出力させるための設定ポイントです。

b0174191_10395339.png

この画面の下方の「プレビュー」ボタンを押すと、ブラウザが起動して赤枠の設定内容でアニメーションが表示されます。 赤枠の設定を調節したり、元の画面に戻ってコマを更新したりして、納得の行くアニメーションを完成させます。
●最後に、上記画面の上方の「OK」を押して「GIFファイル」を保存します。



完成した「アニメーションGIF」ファイルは、通常の画像ファイルと全く同様にアップロードし、ブログ原稿内に挿入できます。

しかし、ここでちょっとした問題が発生します。(この問題はブラウザの Chrome とIE11で確認され、エキサイトのシステムの問題と考えられます)「通常編集」の画面では問題なくアニメーションGIFの画像が挿入された様に見えるのですが、「HTML編集」の画面で挿入した画像コードを調べると以下の様になっています。

b0174191_10402146.png


赤線の部分が問題で、「 mid|1|1 」は、エキサイトのシステムが、画像サイズを正しく受け取れなかった事を意味します。 このままでは、画像が表示されません。 そこで、アップロードしたアニメーションGIF画像のサイズを確認して、「HTML編集」で手書きで画像サイズを修正します。

私がサンプルで作ったアニメーションGIF画像の画像サイズは「360pic×240pic」でした。 下は自動入力された画像コードを修正した状態です。

b0174191_10404340.png

これで、ブログ文面上で正しくGIF画像が表示される様になります。
以上の様に、エキサイトブログでは、
●アニメーションGIF画像を挿入する際、画像コードの画像サイズを手書き修正する必要がある

下は、サンプルのアニメーションGIF画像を実際に挿入したものです。

b0174191_00083653.gif




[PR]
by Ataron | 2017-03-07 00:50 | PC環境(ハード/ソフト) | Comments(0)

Stylist / Google Chrome 対象URLの指定方法の詳細

2017年 03月 02日
ブラウザ Google Chrome 上で、ユーザースタイルシート機能を管理する拡張機能 Stylist は、安定した動作で、機能も一般ユーザーには充分と思います。 Stylist の基本的な操作は、以下に纏めています。


このページは上記ページの補足で、「対象URL」の指定方法の少し詳しい説明です。



Stylist の「Style set」枠で「All site」を選択しなかった場合は、下図の赤枠で示した「対象URL」の指定枠が表示されます。 この指定枠は「add Rule」を押して幾つでも追加が可能です。

b0174191_14425987.png

その指定枠の左端に、上図の様に「prefix」「domain」「regexp」の3種の指定方法の区別があり、これらは自由に切り替えが可能です。 この3種の指定方法について、前ページでは説明を省略したので、以下に説明します。



インターネット上のサイトのURLは、エキサイトブログ向上委員会のページを例にすると、およそ以下の構成になっています。

b0174191_15492999.png

◎URLは「http」で始まる全ての部分です。

◎domain(ドメイン)名は「staff.exblog.jp」の部分です。
「exblog.jp」というドメインに対して「staff.exblog.jp」はサブドメインと呼ばれる形ですが、別個の独立したドメインとして扱われます。 本社と支社は別の住所ですと言う感じ。 左側に「.」を挟んで更に複雑な形で表す事も出来ます。

◎「/23689200」の部分はサブディレクトリと呼ばれます。 これは各支社内での部署みたいなものです。 右側に「/」を挟んで追記し、更に細分化したディレクトリ先を指定出来ます。

以上の事を理解していれば、3種の指定方法の区別は理解し易いでしょう。

prefix:URLの「先頭側から始まる一部分」を指定して、それが一致するURLなら適応する。

「prefix」は基本的な選択枝です。右枠内の記入の際に「http://」を省略せず、正しく記入する必要があります。 また、右側をどこまでで切るかで、対象となるURLの範囲が変わって来ます。
▪「http://staff.exblog.jp/23689200」と全て記入すれば、「23689200」の個別ページのみ指定されて、トップページの「http://staff.exblog.jp」は指定対象外となります。
▪「http://staff.exblog.jp」と記入すれば、トップページも「23689200」や他の個別ページも、指定対象に入ります。

domain:ドメイン名(またはサブドメイン名)を指定して、同じドメイン名のURLなら適応する。

「domain」の指定は、ドメイン名の指定だけでサブドメインも適応されます。
▪「staff.exblog.jp」と指定すると「exblog.jp」は指定の対象外となります。
▪「exblog.jp」と指定すると「staff.exblog.jp」「someone.exblog.jp」等も指定の対象になります。
▪「staff.exblog」や「staff.exblog.jp/23689200」などとすると正しいドメイン名でないので、エラーで無効となります。

regexp:URLの「一部の文字列」を指定し、同じ「文字列」が含まれるURLなら適応する。

「regexp」での指定は、上記の設定では出来ない文字列検索と同様の指定が可能になります。
▪例えば右枠を「ex」と指定すれば、「exblog.jp」「www.excite.co.jp」「http://www.tv-asahi.co.jp/news-ex/」等も指定対象となります。



以上が、3種の指定方法の違いです。 多くの場合は「All site」や「prefix」で事足りるはずですが、他の指定方法が便利な場合も考えられます。 特にサブドメイン構成になったサイトは多く、「domain」の使い所はありそうです。



[PR]
by Ataron | 2017-03-02 17:56 | PC環境(ハード/ソフト) | Comments(0)

PCを夜中に起動させない方法とLANのリセット

2017年 02月 20日
Win10にアップグレード後に、スリープに落としていたPCが、夜中に勝手に起動して困る話は良く聞きます。 Windowsやセキュリティアプリの自動アップデートやシステムバックアップ等を夜中に設定している場合なら、時刻指定を変えれば良いでしょう。 しかし、それらの指定を無視してでもとにかく起動させたくない場合や、起動の原因が不明な場合は、およそ以下の箇所の設定で対策をすれば良い様です。

b0174191_23433097.png



(1)スリープ解除タイマーの設定
「電源オプション」→「コンピューターがスリープ状態になる時間を変更」→「詳細な電源設定の変更」で以下の「電源オプション(詳細設定)」のウインドウが表示されます。 この「スリープ」の項の「スリープ解除タイマーの許可」の設定を、下図の様に「無効」に設定します。

b0174191_22160825.png

(2)ネットワークアダプター(NIC)の設定
「デバイスマネージャー」を開き、使用している「ネットワークアダプター」を右クリックし「プロパティ」を開きます。

b0174191_22205472.png

開いた「ネットワークアダプターのプロパティ」のウインドウで「詳細設定」タブを開き、下図の様に「Wake on Magic Packet」「Wake on pattern mactch」「WakeOnLAN From PowerOff」等のプロパティを「Disabled」に設定します。

b0174191_22331802.png

一般家庭のPCではこれらを「Disabled」としても問題ないでしょう。
更に「電源の管理」タブを開き、3項目(特に下側の2項目)のチェックを外します。

b0174191_22342940.png

但し、宅内LANで他PCの遠隔起動等をしている場合は、「Magic Packet」関係の機能を「Enabled」にする必要があります。

(3)マウスとそのほかのポインティングデバイスの設定
「デバイスマネージャー」を開き、使用している「マウス」を右クリックし「プロパティ」を開きます。

b0174191_22453391.png

開いた「マウスのプロパティ」のウインドウで「電源の管理」タブを開き、下図の様に2項目(特に下側)のチェックを外します。

b0174191_22455676.png

以上の(1)(3)の3ヵ所の設定が、スリープからの自動復帰をコントロールするポイントになります。



これらの設定を弄った後は、PCを再起動するべきです。 ところが、そのままスリープさせてしまったのが災いしたらしく、スリープから復帰後にネットワーク接続が不可能になっていました。

b0174191_10413926.png

上図の様にWin10の「ネットワーク」の状態を示すアイコンに「×」印が付いて消えなくなったのです。

ネットワーク接続は「有効」になっていて、明らかにソフトウエアの問題なのに、トラブルシューティングは「LANケーブルが繋がっていない」と言うだけです。 PCの再起動、先の設定の一旦差し戻し、ネットワークアダプターのドライバー更新、デバイスマネージャー上からアダプターの一旦削除、ルーターのリセット、PCの電源断しPCの再起動、LANケーブルの繋ぎ換え、ついにはWindowsの復元などを行ったのですが、一向に「×」印が消えずネットワークが繋がりません。

ソフトウェア設定でアダプターが故障するのかと半分思いかけたのですが、一つ徹底していなかった事がありました。 PCの電源断だけでなく「PCのコンセントを抜く」という操作です。 PCのシャットダウン後にコンセントを抜き、10秒ほど経ってからコンセントを繋ぎPCを起動すると、ようやく正常に戻りました。

ネットワークアダプター(NIC)は、PCのシャットダウンとは無関係に通電して働いていて、これをリセットするにはPCのコンセントを抜く必要があったのですね。

LANのリセット手段として知っておくべき事として以下に纏めておきます。

●モデムやルーター類のリセットは、そのリセットボタンを押すか電源コードを抜く
●ネットワークアダプター(NIC)のリセットは、PCの電源コードを抜く





[PR]
by Ataron | 2017-02-20 23:24 | PC環境(ハード/ソフト) | Comments(0)

Chrome のフリーズと McAfee WebAdvisor の関係

2017年 02月 17日
2017年2月に入ってからと思いますが、Chromeが頻繁にフリーズする様になりました。 新しいページを開こうとすると「Chromeが応答していません」に陥り、Chromeを終了するしかなくなり、同時に他のブラウザも使えなくなります。 この状態を抜けるにはPCの再起動しかなく、再起動後はしばらく問題ないのですが、ページを往復している内に再びフリーズします。

これは一日に数回は経験し、並列して使用している2台のPCでほぼ同時に生じた現象なので、当初はインターネットルーター等を疑いましたが解決しませんでした。 その後、ネットの最近の情報で「McAfee」との関係を疑う記事があり、私も「McAfee」ユーザーでこの点に注目しました。



新しいページを開く際やその直後にフリーズするので、私は「McAfee WebAdvisor」を疑いました。「McAfee」は Chromeに対しては自動的に「McAfee WebAdvisor」というChrome拡張機能をインストールします。 その場合は、下の様なくすんだ拡張機能のアイコンが表示されます。

b0174191_17455430.png

この「McAfee WebAdvisor」がフリーズの原因なら、動作を停止するのは簡単です。 上のアイコンを右クリックして「拡張機能を管理」を押すと、下図の様にChrome拡張機能の管理ページが開きます。

b0174191_17523840.png

ここで「▢有効」のチェックを外すと「McAfee WebAdvisor」の機能が停止します。

この拡張機能は、ネット上の危険サイトのURLリンクを、ユーザーが開く前に察知して警告する機能です。 働かせた方が安全ですが、他の「McAfee」のセキュリティ機能は働いているので、私はチェックを外して様子を見ています。 この拡張機能がフリーズの原因ではない様なら、再びチェックを入れれば再稼働が可能です。



この記事は、2月17日の時点のものです。 現在のところこの対策でフリーズ再発がなくなり、一定の解決を見たと感じます。 同様の問題で困っている方の参考になればと、この「McAfee WebAdvisor」の対策を提案します。

しかしながら、「McAfee」あるいは「Chrome」によるアップデートで、このフリーズ問題は簡単に解決してしまう可能性があります。 また異なった原因により似た問題が生じている可能性も色々と考えられますので、その判断は各自にお任せします。



「McAfee」に原因する問題らしいという事が判って来ました。 以下のページに関連した情報がありました。

  バージョン更新後?クロームが頻繁に応答なしになる Google Chrome ヘルプ フォーラム

2月19日現在、「McAfee」側で対策したバージョンアップがされた様に書かれています。 既に解決済みの環境も多いと思いますが、もし再発がある様なら「McAfee」の「更新の確認」を押して手動で更新のダウンロードをして、PCの再起動を試してください。



[PR]
by Ataron | 2017-02-17 18:09 | PC環境(ハード/ソフト) | Comments(0)