Google スプレッドシートと比較して、Microsoft Excel が決定的に劣る点。
長年のウィークポイントであった同時編集については、Office 365 でほぼ挽回しているようだし、今回ツッコむのはその点ではない。
ズバリ、Microsoft Excel は「行列の削除ができない」。
なんのこっちゃ、という人もいらっしゃるやもしれないが、試しに Microsoft Excel で「空白のブック」（新規ワークブック）を開いてもらいたい。
そして、ワークシートで最大行列のセル（一番右下のセル）を選択する。[Ctrl]+[↓] と [Ctrl]+[→] でキー操作すると早い。行は「1048576」、列は「XFD」になっているはずだ。
その上で、適当な行や列を「削除」してみる。行や列を選択して、右クリックのプルダウンメニューから [削除] を選択する。しかし、表示されている最大行列のラベルは「1048576」と「XFD」のままだ。
言うなれば、選択した行列の削除はされているのだが、域外から削除されたのと同数の行列が追加されている。つまり、ワークシートの行列数は増減しない。
これが「行列の削除ができない」の意味。
Google スプレッドシートの場合は、削除すれば普通にその分行列は減る。
実に単純だ。
一見どうということもない違いではあるが、さに非ず。Microsoft Excel はワークシートの全体像を明示できないのだ。
見えている範囲の表や数値で全てかと思っていたら、極端な話 XFD1048576 のセルにデータが入っているかもしれない。それは実際に調べてみないと判らない。
確かに [Ctrl]+[End] で「最後のセル（右端の使用されている列の、最も下の使用されている行のセル）」へ移動できるので、それで確認はできるが、そうやって意図的に調べないと判らない。
削除できないのなら非表示にするという手もあるが、「見えていないだけで実体としては残っている」というのは混乱の種になるだけだ。
対して Google スプレッドシートの場合、不要な行列をバッサリ後腐れなく削除しておけば、シートの全体像は一目瞭然になる。
実に明瞭だ。
Microsoft Excel はバージョンを重ねても、この辺りの仕様が改善される気配はない。
おそらく高邁なる設計思想に基いているからなんだろうが、それだけにこれからも「決定的に劣る点」として残り続けるだろう。
2018/02/26
2018/02/21
ソフトバンクのキャリアメール、運用ポリシー変更した？
ソフトバンクのキャリアメール（ @softbank.ne.jp ）、SMTP Server の運用ポリシー変更したのかな。
先週金曜日（2018/02/16）から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。
しっかし、キャリアメールは昔から頭痛の種なんだよな。
早く絶滅せんものか。
今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな（実際利用者は右肩下がりらしいので喜ばしいこと）。
先週金曜日（2018/02/16）から、突然「dsn=5.0.0, stat=Service unavailable」で受取拒否されるようになった。もちろん全部が全部ではいものの、以前はほぼ皆無だったんだが…。
しっかし、キャリアメールは昔から頭痛の種なんだよな。
早く絶滅せんものか。
今さら言うのもバカバカしいが、こういうキャリアメールの "特殊処理" は「eメール」として普通じゃない。諸般の事情があるとは言え、送ったメールが常態的に届かないなんて、実用サービスの体を成してないだろ。
SMTP Server の運用は各組織のポリシーに委ねられている訳だが、当たり前のようにこんな "特殊処理" を常態化させているサービスは、理の当然として淘汰されるべきだろうな（実際利用者は右肩下がりらしいので喜ばしいこと）。
2018/02/20
e-Tax のインフラは Akamai
e-Tax って、Akamai（※）のネットワーク使って展開してるんだ。
今更ながら、「www.e-tax.nta.go.jp」を正引＆逆引して気が付いた。
さらにフロントエンドのみならず、バックエンド側も Akamai のネットワークでかためている模様。
※：
アカマイ・テクノロジーズ - Wikipedia
世界最大手の CDN業者。本社米国。
何だかなぁ。これは一納税者として納得いかん。
国家事業なんだから、安全保障上からも国内産業育成からも、国内の業者に任せるべきだろ。
余分に金を積んででも、IIJ 辺りにやらせて欲しい。
今更ながら、「www.e-tax.nta.go.jp」を正引＆逆引して気が付いた。
さらにフロントエンドのみならず、バックエンド側も Akamai のネットワークでかためている模様。
※：
アカマイ・テクノロジーズ - Wikipedia
世界最大手の CDN業者。本社米国。
何だかなぁ。これは一納税者として納得いかん。
国家事業なんだから、安全保障上からも国内産業育成からも、国内の業者に任せるべきだろ。
余分に金を積んででも、IIJ 辺りにやらせて欲しい。
2018/02/19
G Suite グループでは配信不能レポートは配送できない
G Suite（旧 Google Apps）のグループ（ML、メーリングリスト）では、SMTP Server からの配信不能レポート（エラーメール）は配送できない。
Google グループに関するよくある質問（管理者向け） - G Suite 管理者 ヘルプ
----------引用ココから
グループに送信できないメールの種類はありますか？
「返送メッセージ」とも呼ばれる配信不能レポート（NDR）をグループに送信または転送することはできません。NDR に似ているメッセージも、送信や転送はできません。
----------引用ココまで
この仕様、つい忘れて毎度「？？？」となってしまう。
単に「できません」としか書かれていないが、具体的な動きとしては配信不能レポートを dsn=2.0.0 で受取った上で、何処へ何も残すことなく（グループの管理画面にも痕跡を残さず）暗黙の内に破棄してしまう。
グループアドレスを代表にして、それを使ってチームで顧客対応をしたりする場合。つまり、各メンバはグループアドレスを From にして顧客へメール送信し、顧客にはグループアドレスへ返信してもらう（自動的にグループメンバでシェア）という運用の場合、問題が出てくる。
顧客のアドレスを間違って入力した場合（またはアドレスが既に存在しない場合）、普通は User Unknown で配信不能レポートが戻ってくるので直ちに気がつけるのだが、この場合 G Suite のグループは配信不能レポートを飲み込んでしまうので、それに気が付けない。これは困る。
回避方法としては、グループを使うのではなく G Suite の実アカウントを使って転送設定するか、「デフォルトの転送の設定」を使って転送設定するか…辺りか。
前者はユーザレベルでもメンテナンス可能（メンバの追加／削除が可能）だが、実アカウントを使う関係上コスト増になる。もちろん個別にアカウントを用意せずとも、個人アカウントで併用するという手もあるが…さらに管理が面倒になる。
後者はメンテナンスが管理者に限られる上、クリティカルな作業になってしまう（下手するとドメイン全体のメール配送に悪影響が及ぶ）。メンバの追加／削除ごときで、毎度々々そんなところをいじってられない。
どちらの方法にしても、非常に整備性が悪い。
G Suite というのは優秀なサービスなんだが、こういう割り切って使わなくてはいけない仕様が所々ある。
まぁ、何でもトレードオフということなんだろうが…。
Google グループに関するよくある質問（管理者向け） - G Suite 管理者 ヘルプ
----------引用ココから
グループに送信できないメールの種類はありますか？
「返送メッセージ」とも呼ばれる配信不能レポート（NDR）をグループに送信または転送することはできません。NDR に似ているメッセージも、送信や転送はできません。
----------引用ココまで
この仕様、つい忘れて毎度「？？？」となってしまう。
単に「できません」としか書かれていないが、具体的な動きとしては配信不能レポートを dsn=2.0.0 で受取った上で、何処へ何も残すことなく（グループの管理画面にも痕跡を残さず）暗黙の内に破棄してしまう。
グループアドレスを代表にして、それを使ってチームで顧客対応をしたりする場合。つまり、各メンバはグループアドレスを From にして顧客へメール送信し、顧客にはグループアドレスへ返信してもらう（自動的にグループメンバでシェア）という運用の場合、問題が出てくる。
顧客のアドレスを間違って入力した場合（またはアドレスが既に存在しない場合）、普通は User Unknown で配信不能レポートが戻ってくるので直ちに気がつけるのだが、この場合 G Suite のグループは配信不能レポートを飲み込んでしまうので、それに気が付けない。これは困る。
回避方法としては、グループを使うのではなく G Suite の実アカウントを使って転送設定するか、「デフォルトの転送の設定」を使って転送設定するか…辺りか。
前者はユーザレベルでもメンテナンス可能（メンバの追加／削除が可能）だが、実アカウントを使う関係上コスト増になる。もちろん個別にアカウントを用意せずとも、個人アカウントで併用するという手もあるが…さらに管理が面倒になる。
後者はメンテナンスが管理者に限られる上、クリティカルな作業になってしまう（下手するとドメイン全体のメール配送に悪影響が及ぶ）。メンバの追加／削除ごときで、毎度々々そんなところをいじってられない。
どちらの方法にしても、非常に整備性が悪い。
G Suite というのは優秀なサービスなんだが、こういう割り切って使わなくてはいけない仕様が所々ある。
まぁ、何でもトレードオフということなんだろうが…。
2018/02/15
RAIDストレージが壊れた & RAID1 の分散読込による高速化
自宅で使っていた RAIDストレージが、壊れてアクセスできなくなった。
とは言っても、RAID を構成している物理ドライブが壊れたのではなく、壊れたのは筐体側というあるあるパターン。つまり、RAIDストレージは一撃にして使用不能。
ドライブは多重化できても、筐体（RAIDコントローラ）はシングルポイントにならざるを得ない。あまつさえ使っていた筐体は NAS ではなく USB 接続の「HDDケース」で、オモチャみたいな RAID機能だった。こうなったのも、まぁ宜なるかな。
ただ、幸い RAID1（ミラーリング）で使っていたので、構成ドライブの片方を引抜いて USBアダプタで直結すれば、何の問題もなくそのまま使える（もちろん冗長性は失われているが）。
RAID5 や RAID6、それに RAID10 ではこうはいかないわけで、RAID1 の単純さ故の利点（※）。
※：もっとも、それ故にドライブの廃棄時や、修理交換時には（他の RAID 以上に）気を使うんだが…。
かくなる次第で現在、後釜にすべき製品を選定中。
どれを選んでも大差なかろうから適当に選んでいいかと思いつつも、できれば RAID1 の分散読込に対応している製品はないかと物色している…のだが、その辺りに言及している品が見つからない。
当今では RAID1 の分散読込ぐらい当たり前に対応しているだろうと思い、かつては今回壊れた製品を購入したのだが、読込では片一方のアクセスランプしか点灯せずにガッカリしたという事がある。
分散読込に対応しているような「気の利いた」製品は、昔同様やはり相応に本格的なもの（お高価い）である必要があるんだろうな。
追記：
軽く検索してみたのだが、世の中には「RAID1 の分散読込による高速化」というものを頑なに理解しない人がいるらしい。前世紀からの常識と言わずとも（実際 1990年代で普通に言及されていた）、2台のドライブへどの様にデータが保存されているのか考えたら、分散読込が可能なことは（技術的な手間や是非は置くとして）自明だと思うのだが。
例： 『RAID1構築での読み込みドライブは１つ？』 - 価格.com
とは言っても、RAID を構成している物理ドライブが壊れたのではなく、壊れたのは筐体側というあるあるパターン。つまり、RAIDストレージは一撃にして使用不能。
ドライブは多重化できても、筐体（RAIDコントローラ）はシングルポイントにならざるを得ない。あまつさえ使っていた筐体は NAS ではなく USB 接続の「HDDケース」で、オモチャみたいな RAID機能だった。こうなったのも、まぁ宜なるかな。
ただ、幸い RAID1（ミラーリング）で使っていたので、構成ドライブの片方を引抜いて USBアダプタで直結すれば、何の問題もなくそのまま使える（もちろん冗長性は失われているが）。
RAID5 や RAID6、それに RAID10 ではこうはいかないわけで、RAID1 の単純さ故の利点（※）。
※：もっとも、それ故にドライブの廃棄時や、修理交換時には（他の RAID 以上に）気を使うんだが…。
かくなる次第で現在、後釜にすべき製品を選定中。
どれを選んでも大差なかろうから適当に選んでいいかと思いつつも、できれば RAID1 の分散読込に対応している製品はないかと物色している…のだが、その辺りに言及している品が見つからない。
当今では RAID1 の分散読込ぐらい当たり前に対応しているだろうと思い、かつては今回壊れた製品を購入したのだが、読込では片一方のアクセスランプしか点灯せずにガッカリしたという事がある。
分散読込に対応しているような「気の利いた」製品は、昔同様やはり相応に本格的なもの（お高価い）である必要があるんだろうな。
追記：
軽く検索してみたのだが、世の中には「RAID1 の分散読込による高速化」というものを頑なに理解しない人がいるらしい。前世紀からの常識と言わずとも（実際 1990年代で普通に言及されていた）、2台のドライブへどの様にデータが保存されているのか考えたら、分散読込が可能なことは（技術的な手間や是非は置くとして）自明だと思うのだが。
例： 『RAID1構築での読み込みドライブは１つ？』 - 価格.com
2018/02/07
FireFox のプロキシ設定でハマリかけた
FireFox のプロキシ設定でハマリかけたので。
なお、これは Windows 10 Fall Creators Update + FireFox 58.0.1 の話。
さて、順を追って書いていくのも面倒なので、引掛けポイントを列挙する。
1. FireFox は DHCP による WPAD に未対応
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
3. Microsoft DNS Service には「DNS 禁止リスト」がある
プロキシ設定の配布方法には色々な方法があり、その中で一番自動化された方法が WPAD による配布。
さらに、WPAD による配布にも二通りあり、DHCP で配布する方法と、DNS で配布する方法がある。
WebブラウザのProxy設定を行うための4つの方法（WPADのススメ） - @IT
で、FireFox は DHCP による配布には対応していないというわけ。なので、WPAD を使おうとすると、勢い DNS で配布する必要がある。
以下のページで主要ブラウザについてまとめられているが、FireFox のそれは Windows に於いて例外的な挙動。
Browser Support - FindProxyForURL
まぁこういう仕様になっている理由は、概ね類推できるが…足並み揃えて欲しいよなぁ。
FireFox のプロキシ設定は、デフォルトで [システムのプロキシ設定を利用する] になっている。
そうなっているのは普通に考えるならベターな選択だとは思うが、残念ながらシステム設定を利用してくれない場合がある。
システム（IE）のプロキシ設定： [設定を自動的に検出する]
FireFox のプロキシ設定： [システムのプロキシ設定を利用する]
以上の場合（なお、これが OS & FireFox のデフォルト状態）、当然 IE 側は WPAD を検索して見つかればその設定を使ってくれる。FireFox も WPAD を検索してくれ…そうなものだが、してくれない。
どうも「[設定を自動的に検出する] というシステム設定」は、利用してくれないようだ。なので FireFox で WPAD を利用しようとすると、デフォルトから [このネットワークのプロキシ設定を自動検出する] へ変更しないといけない。
これが意味するところ、プロキシが必要な環境において、FireFox はどう頑張ってもデフォルトで動くようにできないということ。もちろん、FireFox の設定ファイルを自動配布するという手もあるが、本来はネットワーク側の設定だけで解決する話が、わざわざ別途そこまで手をかけてやる必要がある。
これは、心底ガックリ仕様。
なお、念のため確認したところ、macOS High Sierra + FireFox 58.0.1 では再現しない。つまり [システムのプロキシ設定を利用する] でちゃんとシステム設定に従って WPAD を検索してくれる。
…これ、Windows版 FireFox の不具合なんじゃねーの？
これは FireFox の問題ではないが、関連してハマリかけたので。
DNS 禁止リストからの WPAD の削除 - Microsoft
セキュリティ上の問題で、「wpad」は「DNS 禁止リスト」に入れられている。なので普通に設定しただけでは、問い合わせに答えてくれない。
これは「DNS 禁止リスト」を更新すれば解決。
動的更新で「wpad」レコードを登録されたら…と考えると当然の処置だが、それならそれで設定時に「禁止リストに入っとるで」と警告を出すとかして欲しいよなという気も。
----------
「2」の現象、Windows XP + FireFox 47.0.2 なんていう化石環境でも再現する。
どうも「不具合」というわけではなく、Windows版 FireFox の「仕様」である模様。
「不具合」であれば、新バージョンで改善するという希望も持てたんだが…。
なお、これは Windows 10 Fall Creators Update + FireFox 58.0.1 の話。
さて、順を追って書いていくのも面倒なので、引掛けポイントを列挙する。
1. FireFox は DHCP による WPAD に未対応
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
3. Microsoft DNS Service には「DNS 禁止リスト」がある
1. FireFox は DHCP による WPAD に未対応
プロキシ設定の配布方法には色々な方法があり、その中で一番自動化された方法が WPAD による配布。
さらに、WPAD による配布にも二通りあり、DHCP で配布する方法と、DNS で配布する方法がある。
WebブラウザのProxy設定を行うための4つの方法（WPADのススメ） - @IT
で、FireFox は DHCP による配布には対応していないというわけ。なので、WPAD を使おうとすると、勢い DNS で配布する必要がある。
以下のページで主要ブラウザについてまとめられているが、FireFox のそれは Windows に於いて例外的な挙動。
Browser Support - FindProxyForURL
まぁこういう仕様になっている理由は、概ね類推できるが…足並み揃えて欲しいよなぁ。
2. FireFox の [システムのプロキシ設定を利用する] は必ずしもシステム設定を利用しない
FireFox のプロキシ設定は、デフォルトで [システムのプロキシ設定を利用する] になっている。
そうなっているのは普通に考えるならベターな選択だとは思うが、残念ながらシステム設定を利用してくれない場合がある。
システム（IE）のプロキシ設定： [設定を自動的に検出する]
FireFox のプロキシ設定： [システムのプロキシ設定を利用する]
以上の場合（なお、これが OS & FireFox のデフォルト状態）、当然 IE 側は WPAD を検索して見つかればその設定を使ってくれる。FireFox も WPAD を検索してくれ…そうなものだが、してくれない。
どうも「[設定を自動的に検出する] というシステム設定」は、利用してくれないようだ。なので FireFox で WPAD を利用しようとすると、デフォルトから [このネットワークのプロキシ設定を自動検出する] へ変更しないといけない。
これが意味するところ、プロキシが必要な環境において、FireFox はどう頑張ってもデフォルトで動くようにできないということ。もちろん、FireFox の設定ファイルを自動配布するという手もあるが、本来はネットワーク側の設定だけで解決する話が、わざわざ別途そこまで手をかけてやる必要がある。
これは、心底ガックリ仕様。
なお、念のため確認したところ、macOS High Sierra + FireFox 58.0.1 では再現しない。つまり [システムのプロキシ設定を利用する] でちゃんとシステム設定に従って WPAD を検索してくれる。
…これ、Windows版 FireFox の不具合なんじゃねーの？
3. Microsoft DNS Service には「DNS 禁止リスト」がある
これは FireFox の問題ではないが、関連してハマリかけたので。
DNS 禁止リストからの WPAD の削除 - Microsoft
セキュリティ上の問題で、「wpad」は「DNS 禁止リスト」に入れられている。なので普通に設定しただけでは、問い合わせに答えてくれない。
これは「DNS 禁止リスト」を更新すれば解決。
----------
Afterfollow 2018/02/13
「2」の現象、Windows XP + FireFox 47.0.2 なんていう化石環境でも再現する。
どうも「不具合」というわけではなく、Windows版 FireFox の「仕様」である模様。
「不具合」であれば、新バージョンで改善するという希望も持てたんだが…。
2018/01/26
DELL PC で警告イベント「イベントID: 19」が大量出力
DELL のデスクトップPC（OptiPlex 9020）を、Windows 10 Fall Creators Update でクリーンインストールした直後、OS のシステムログへ以下の警告イベントが大量に吐出されていた。
----------イベントログ 引用ココから
ログの名前: System
ソース: Microsoft-Windows-WHEA-Logger
日付:
イベント ID: 19
タスクのカテゴリ: なし
レベル: 警告
キーワード:
ユーザー: LOCAL SERVICE
コンピューター:
説明:
修正されたハードウェア エラーが発生しました。
コンポーネントによる報告: プロセッサ コア
エラー ソース: 修正されたコンピューター チェック
エラーの種類: 内部パリティ エラー
プロセッサ APIC ID:
----------イベントログ 引用ココまで
なんぞ？と思い、BIOSレベル／OSレベルで診断プログラムを実行するも、全て異常なし。
Webで調べると「イベントID: 19」は、CPU交換したら or 電圧上げたら or 電源ユニット交換したら治まったという情報があったので、何らかの異常が検知されるの（機材の故障）を期待したんだが…。
診断プログラムで異常が出ない以上ちょっと気が引けたが、その為の費用は出しているんだからとサポートへ問合せを入れた（急がないのでメールで）。
問合せを入れた直後ふと気になって、BIOS は最新だよな（先日バージョンアップしたばかりだし）と念の為確認した所…なにかおかしい。先日適用した最新バージョン（A21）がサポートサイトから…消えている！？
まさに「あ…（察し）」。
そう言われてみれば、A21 では CPU関連の脆弱性（Meltdown & Spectre）対策も含まれてたな。
その線からサポート情報を探ると、簡単に出てきた。
マイクロプロセッサーのサイドチャネル脆弱性（CVE-2017-5715、CVE-2017-5753、CVE-2017-5754）: デル製品への影響 - DELL
----------引用ココから
更新日: 2018年1月22日
インテルは、スペクター（バリアント2）、CVE-2017-5715対応のためにリリースされたBIOSアップデートに含まれているマイクロコードによる「再起動の問題」に関する新たなガイダンスを公表しました。デルでは、すべてのお客様は、現時点ではスペクター（バリアント2）脆弱性のためのBIOSアップデートを導入しないようにすることを推奨いたします。デルは影響のあるBIOSアップデートをWebから削除中であり、影響を受けるプラットフォームに対する新たなBIOSのアップデートはサスペンドになっています。
すでにBIOSアップデートの適用を行ってしまった場合は、新たな情報およびBIOSのアップデートリリースが入手できるまでお待ちください。現時点では、それ以外のいかなるアクションも行わないでください。引き続きアップデートを過去にさかのぼってご確認ください。
----------引用ココまで
今回の警告イベント大量出力は、これに関連する余波ではないかと類推できるんだが「いかなるアクションも行わないでください」とのことだから、軽挙妄動して旧バージョン（A20）へ戻すことなく、一旦サポートからの回答を待つことにする。
恐らくサポートは情報を掴んでいるはずなので、適切にアドバイスしてくれるだろう。
----------
今日、サポートからの回答があった。
予想通り「Meltdown & Spectre 対策の副作用」だった模様。
もっとも、自分が掴んでいた以上に追加する情報はなく、上記ページの URL を案内してくれた上で「新しい BIOS のリリースを待ってくれ」とのこと。
まぁやっちまった（BIOS をアップデートしてしまった）ものは仕方ないので、アドバイス通り新しい BIOS のリリースを待つことにする。
幸いなことに目に見えた障害は発生していないことだし。
----------イベントログ 引用ココから
ログの名前: System
ソース: Microsoft-Windows-WHEA-Logger
日付:
イベント ID: 19
タスクのカテゴリ: なし
レベル: 警告
キーワード:
ユーザー: LOCAL SERVICE
コンピューター:
説明:
修正されたハードウェア エラーが発生しました。
コンポーネントによる報告: プロセッサ コア
エラー ソース: 修正されたコンピューター チェック
エラーの種類: 内部パリティ エラー
プロセッサ APIC ID:
----------イベントログ 引用ココまで
なんぞ？と思い、BIOSレベル／OSレベルで診断プログラムを実行するも、全て異常なし。
Webで調べると「イベントID: 19」は、CPU交換したら or 電圧上げたら or 電源ユニット交換したら治まったという情報があったので、何らかの異常が検知されるの（機材の故障）を期待したんだが…。
診断プログラムで異常が出ない以上ちょっと気が引けたが、その為の費用は出しているんだからとサポートへ問合せを入れた（急がないのでメールで）。
問合せを入れた直後ふと気になって、BIOS は最新だよな（先日バージョンアップしたばかりだし）と念の為確認した所…なにかおかしい。先日適用した最新バージョン（A21）がサポートサイトから…消えている！？
まさに「あ…（察し）」。
そう言われてみれば、A21 では CPU関連の脆弱性（Meltdown & Spectre）対策も含まれてたな。
その線からサポート情報を探ると、簡単に出てきた。
マイクロプロセッサーのサイドチャネル脆弱性（CVE-2017-5715、CVE-2017-5753、CVE-2017-5754）: デル製品への影響 - DELL
----------引用ココから
更新日: 2018年1月22日
インテルは、スペクター（バリアント2）、CVE-2017-5715対応のためにリリースされたBIOSアップデートに含まれているマイクロコードによる「再起動の問題」に関する新たなガイダンスを公表しました。デルでは、すべてのお客様は、現時点ではスペクター（バリアント2）脆弱性のためのBIOSアップデートを導入しないようにすることを推奨いたします。デルは影響のあるBIOSアップデートをWebから削除中であり、影響を受けるプラットフォームに対する新たなBIOSのアップデートはサスペンドになっています。
すでにBIOSアップデートの適用を行ってしまった場合は、新たな情報およびBIOSのアップデートリリースが入手できるまでお待ちください。現時点では、それ以外のいかなるアクションも行わないでください。引き続きアップデートを過去にさかのぼってご確認ください。
----------引用ココまで
今回の警告イベント大量出力は、これに関連する余波ではないかと類推できるんだが「いかなるアクションも行わないでください」とのことだから、軽挙妄動して旧バージョン（A20）へ戻すことなく、一旦サポートからの回答を待つことにする。
恐らくサポートは情報を掴んでいるはずなので、適切にアドバイスしてくれるだろう。
----------
Afterfollow 2018/01/29
今日、サポートからの回答があった。
予想通り「Meltdown & Spectre 対策の副作用」だった模様。
もっとも、自分が掴んでいた以上に追加する情報はなく、上記ページの URL を案内してくれた上で「新しい BIOS のリリースを待ってくれ」とのこと。
まぁやっちまった（BIOS をアップデートしてしまった）ものは仕方ないので、アドバイス通り新しい BIOS のリリースを待つことにする。
幸いなことに目に見えた障害は発生していないことだし。
2018/01/24
Windows Server DHCP の引越し（Export & Import）コマンド
「Windows Server 2003 の～」という書出しだが、2008 R2 → 2016 の引越しでもちゃんと動いてくれた。更に言えば、ページの最終更新日は「2017/01/08」。
Netsh ユーティリティを使用して DHCP スコープをエクスポートまたはインポートする方法 - Microsoft サポート
----------Export方法 ココから
C:\>netsh
netsh>dhcp server \\servername
netsh dhcp server>export c:\temp\dhcpdb all
コマンドを正しく完了しました。
netsh dhcp server>
----------Export方法 ココまで
----------Import方法 ココから
C:\>netsh
netsh>dhcp server \\servername
netsh dhcp server>import c:\temp\dhcpdb all
コマンドを正しく完了しました。
netsh dhcp server>
----------Import方法 ココまで
「\\servername」のところは Export元／Import先のサーバ名に置換える。
引越しに際して、予約設定（MAC Address と IP Address の紐付け設定）がアホほどあるので、さてどうしたものかと考えていたら、ちゃんとコマンドが用意されていた。まぁ何を今更な発見で、何年 Windows Server を管理しているんだという話だが…。
なお、Export されるファイルはバイナリなので、これをテキストエディタで編集して…という技は不可（残念
Netsh ユーティリティを使用して DHCP スコープをエクスポートまたはインポートする方法 - Microsoft サポート
----------Export方法 ココから
C:\>netsh
netsh>dhcp server \\servername
netsh dhcp server>export c:\temp\dhcpdb all
コマンドを正しく完了しました。
netsh dhcp server>
----------Export方法 ココまで
----------Import方法 ココから
C:\>netsh
netsh>dhcp server \\servername
netsh dhcp server>import c:\temp\dhcpdb all
コマンドを正しく完了しました。
netsh dhcp server>
----------Import方法 ココまで
「\\servername」のところは Export元／Import先のサーバ名に置換える。
引越しに際して、予約設定（MAC Address と IP Address の紐付け設定）がアホほどあるので、さてどうしたものかと考えていたら、ちゃんとコマンドが用意されていた。まぁ何を今更な発見で、何年 Windows Server を管理しているんだという話だが…。
なお、Export されるファイルはバイナリなので、これをテキストエディタで編集して…という技は不可（残念
2018/01/23
Google Chrome 初期化方法
Google Chrome の調子が悪い時は、小細工せずにコレで一発解決。
コレでダメなら、Chrome 自体の再インストールしか無いんだが、そこまでの経験は今のところない。
さて、一発解決の方法。
Chrome を終了（常駐も含め）させた上で、以下のフォルダ（ユーザデータのフォルダ）をリネームしてしまう。
なお、常駐を含めて終了させても、プロセスが残ってファイルを掴んでいてリネームに失敗する場合がある。その場合は再起動させた上で実施。
%LOCALAPPDATA%\Google\Chrome\User Data
リネームしてから Chrome を起動すると、ユーザデータが見つからないので新規に作ってくれる。
これで大概の問題は解決する。
ただ、この方法には前提があって、Google アカウントへリンクさせていないと（当然だが）すべての設定が空っぽになってしまう。反対に言えば、Google アカウントへリンクさせているのなら、アカウントへログインすれば一瞬で環境は復元される（復元されないのは cookie くらい）。
なお、Chrome の設定画面に「リセット」があるが、恐らくこの方法の方が根本的処置になるんでないかな。
コレでダメなら、Chrome 自体の再インストールしか無いんだが、そこまでの経験は今のところない。
さて、一発解決の方法。
Chrome を終了（常駐も含め）させた上で、以下のフォルダ（ユーザデータのフォルダ）をリネームしてしまう。
なお、常駐を含めて終了させても、プロセスが残ってファイルを掴んでいてリネームに失敗する場合がある。その場合は再起動させた上で実施。
%LOCALAPPDATA%\Google\Chrome\User Data
リネームしてから Chrome を起動すると、ユーザデータが見つからないので新規に作ってくれる。
これで大概の問題は解決する。
ただ、この方法には前提があって、Google アカウントへリンクさせていないと（当然だが）すべての設定が空っぽになってしまう。反対に言えば、Google アカウントへリンクさせているのなら、アカウントへログインすれば一瞬で環境は復元される（復元されないのは cookie くらい）。
なお、Chrome の設定画面に「リセット」があるが、恐らくこの方法の方が根本的処置になるんでないかな。
2017/12/28
ルート証明書を無効にされた「WoSign」その後
恣意的かつデタラメな認証局運用で各ブラウザから無効にされた、例の WoSign（と StartCom）その後どうなったかなぁ…と思ってアクセスしたら、普通にアクセスできた。
アレ？ WoSign のルート証明書は「信頼されていない証明書」へ登録しているのに何で？…と証明書チェインを確認すると…DigCert の下位認証局になってた :-P
しかし、この WoSign へ "助け舟" を出した「DigCert」だが、例の Symantec の認証局業務（Google からダメ出しされた）を買収したところでもあるんだよなぁ。
なんだか認証局業界の廃物利用企業という感。
話を WoSign へ戻すと、IE、Chrome、FireFox でルート証明書を無効にされて、ルート認証局から下位認証局へ落ちぶれたわけだけれども、何故か Opera だけはルート認証局として認めてくれているらしい。なんとも不思議な話ながら、その理由は以下の通り。
マイクロソフト、不正が指摘されていた中国CAの証明書を無効に - CNET Japan
----------引用ココから
WoSignの証明書をおそらく今後も信頼するであろうウェブブラウザの1つが、Operaだ。Operaブラウザは2016年、Golden Brick Silk Roadを中心とする中国企業のコンソーシアムに買収されている。このコンソーシアムには、北京のモバイルゲームベンダーであるKunlun TechやQihoo 360が名を連ねており、WoSignとStartComはQihoo 360の傘下にある。
----------引用ココまで
なんともかんとも胡散臭い話だ。
アレ？ WoSign のルート証明書は「信頼されていない証明書」へ登録しているのに何で？…と証明書チェインを確認すると…DigCert の下位認証局になってた :-P
しかし、この WoSign へ "助け舟" を出した「DigCert」だが、例の Symantec の認証局業務（Google からダメ出しされた）を買収したところでもあるんだよなぁ。
なんだか認証局業界の廃物利用企業という感。
話を WoSign へ戻すと、IE、Chrome、FireFox でルート証明書を無効にされて、ルート認証局から下位認証局へ落ちぶれたわけだけれども、何故か Opera だけはルート認証局として認めてくれているらしい。なんとも不思議な話ながら、その理由は以下の通り。
マイクロソフト、不正が指摘されていた中国CAの証明書を無効に - CNET Japan
----------引用ココから
WoSignの証明書をおそらく今後も信頼するであろうウェブブラウザの1つが、Operaだ。Operaブラウザは2016年、Golden Brick Silk Roadを中心とする中国企業のコンソーシアムに買収されている。このコンソーシアムには、北京のモバイルゲームベンダーであるKunlun TechやQihoo 360が名を連ねており、WoSignとStartComはQihoo 360の傘下にある。
----------引用ココまで
なんともかんとも胡散臭い話だ。
2017/12/19
「マイナンバー」に代わるもの
名簿の名寄せ乃至それに類した作業をしていると、同姓同名の人に悩まされる。
他の属性（生年月日や住所）があって判定の材料にできれば良いのだが、必ずしもそういう属性が（対象リストに）あるとは限らないし、そもそも変化してしまう属性も多くある。
そこで時の政府は「マイナンバー」なるものを考案したわけだが、もっと良いことを思いついた。
ズバリ、「姓名」で一意になるようにしてしまえば良いのだ。
人名に使える漢字を 2,998字として。
もっともオーソドックスな「姓2文字 + 名2文字」の構成で考えても、名前空間は「2998^4」（80兆余り）。「姓1文字 + 名3文字」や「姓3文字 + 名1文字」の構成を許すなら「2998^4*3」（242兆余り）。更に「姓名で 5文字」まで許容すれば「2998^5*4」（96京余り）。
本邦の人口を 1.27億人として、この名前空間がどれだけの広さか考えると…
「2998^4」であれば、全人口に 63万回余り名前を付与できる。「2998^4*3」であれば 190万回余り。「2998^5*4」に至っては 76億回余り。
言い換えると、それだけの世代交代の間、この名前空間は持つということ（人口が増減しないという前提）。ちなみに、生命誕生は 45億年前とか。生命誕生から毎年世代交代していても「2998^5*4」であれば、まだ 31億くらい残ってるね。
…これ、何気に素晴らしいアイディアじゃないか。
今からでも遅くないので「マイナンバー」なんていう無粋なものは廃止して、「マイネーム」制度として進めてはどうか。
他の属性（生年月日や住所）があって判定の材料にできれば良いのだが、必ずしもそういう属性が（対象リストに）あるとは限らないし、そもそも変化してしまう属性も多くある。
そこで時の政府は「マイナンバー」なるものを考案したわけだが、もっと良いことを思いついた。
ズバリ、「姓名」で一意になるようにしてしまえば良いのだ。
人名に使える漢字を 2,998字として。
もっともオーソドックスな「姓2文字 + 名2文字」の構成で考えても、名前空間は「2998^4」（80兆余り）。「姓1文字 + 名3文字」や「姓3文字 + 名1文字」の構成を許すなら「2998^4*3」（242兆余り）。更に「姓名で 5文字」まで許容すれば「2998^5*4」（96京余り）。
本邦の人口を 1.27億人として、この名前空間がどれだけの広さか考えると…
「2998^4」であれば、全人口に 63万回余り名前を付与できる。「2998^4*3」であれば 190万回余り。「2998^5*4」に至っては 76億回余り。
言い換えると、それだけの世代交代の間、この名前空間は持つということ（人口が増減しないという前提）。ちなみに、生命誕生は 45億年前とか。生命誕生から毎年世代交代していても「2998^5*4」であれば、まだ 31億くらい残ってるね。
…これ、何気に素晴らしいアイディアじゃないか。
今からでも遅くないので「マイナンバー」なんていう無粋なものは廃止して、「マイネーム」制度として進めてはどうか。
2017/01/31
ChatWork その認証（パスワード）関係の仕様について
ビジネス向けチャットツールの雄である「ChatWork」。
自分も好む好まざるに関わらずお世話になっているわけですが、その認証関係の仕様を確認して、今更ながらに愕然となった。
ChatWork のパスワードは「半角英数記号8文字以上」となっている。
でもこれ「半角英数記号から任意に使って8文字以上」という意味だったりする。半角英数記号を混在させる必要はない。入力チェックしているのは文字数だけなので、なんなら「11111111」（"1" を 8文字）でも通ってしまう。
何だよこれ。
これで二段階認証があるのならまだしも、それも無い（2年くらい前から実装するする言っているけど、未だに…）。
管理者がパスワード強度を引き上げる（強いパスワードをユーザに強制する）オプションがあるのかと思いきや、それも無い。
せめて、ユーザのパスワード強度を一覧できる機能でもあれば個別に指導もできるのだが、それすら無い。
このお粗末さは、ビジネスツールとして如何なものかと。
「チャットツール」と聞けば軽いイメージがありますが、ビジネス向けともなれば重要な内容が飛び交うわけで、あまつさえファイル添付機能もある。
ちょっと安心して使えるツールとは思えないなぁ。
2016/09/29
「WoSign」と「StartCom」を「信頼されていない証明書」ストアへ
中国最大の認証局「WoSign」が証明書発行日改竄などを行っていたとしてFirefoxがブロックの方針 - GIGAZINE
こんなルート証明機関を「信頼」していたら、公開鍵基盤が成立しないでしょう。
遅まきながらではありますが、「Certification Authority of WoSign」と「StartCom Certification Authority」のルート証明書を、「信頼されていない証明書」ストアへ登録しました。
ルート証明機関というのは、公開鍵基盤の要です。
いまや色々な社会基盤、例えば銀行（オンラインバンク）でさえも公開鍵基盤に依存しているわけです。その要であるルート証明機関には、極めて高度なモラルが要求されます。
問題のあるルート証明機関が一つでもあれば、公開鍵基盤全体が危機に晒されるからです。
それが瑕疵や怠慢ですらなく、故意にルールに反した運営をしていたわけで、話にならないとしか言い様がないです。
Firefox ready to block certificate authority that threatened Web security - Ars Technica
----------引用ココから
A Google spokesman declined to say whether Chrome planned to issue similar recommendations against WoSign/StartCom.
----------引用ココまで
なお、Google は上記引用のように呑気に構えているようです。
FireFox 嫌いの自分ではありますが、FireFox の迅速なブロック方針には賛辞を贈りたいです。
こんなルート証明機関を「信頼」していたら、公開鍵基盤が成立しないでしょう。
遅まきながらではありますが、「Certification Authority of WoSign」と「StartCom Certification Authority」のルート証明書を、「信頼されていない証明書」ストアへ登録しました。
ルート証明機関というのは、公開鍵基盤の要です。
いまや色々な社会基盤、例えば銀行（オンラインバンク）でさえも公開鍵基盤に依存しているわけです。その要であるルート証明機関には、極めて高度なモラルが要求されます。
問題のあるルート証明機関が一つでもあれば、公開鍵基盤全体が危機に晒されるからです。
それが瑕疵や怠慢ですらなく、故意にルールに反した運営をしていたわけで、話にならないとしか言い様がないです。
Firefox ready to block certificate authority that threatened Web security - Ars Technica
----------引用ココから
A Google spokesman declined to say whether Chrome planned to issue similar recommendations against WoSign/StartCom.
----------引用ココまで
なお、Google は上記引用のように呑気に構えているようです。
FireFox 嫌いの自分ではありますが、FireFox の迅速なブロック方針には賛辞を贈りたいです。
2015/09/04
「ー（長音）」。 いいえ、「―（ダッシュ）」です。
一連のデータの中から、あるカタカナ名称を検索していてヒットしないので、おかしいなと思っていたら…「ー（長音）」であるべきところが「―（ダッシュ）」で記載されていた。
もうね、ひたすら脱力。
ややこしいデータで、ヒットしない（その名称が含まれない）可能性は色々考えられたので、あれやこれや調べていた。その後だっただけに尚更。
で、その憂晴らし事後調査で見つけたのがこのページ。
日本語の横棒記号に絶望した - taichino.com
----------引用ココから
まず半角記号の’-'はハイフンマイナス(0x2d)と呼ばれていて、ハイフンとマイナスの意味を包含した記号になっています。ASCIIコードのビット数の制限があった事を考えても、センスの良さが光る決定だと思います。文脈でハイフンかマイナスかは容易に判断できる訳です。ハイフンとマイナスを別々にしていたら、今頃マイナスのつもりで書いたハイフンに対するコンパイルエラーで世界中のプログラマのイライラは100%水増しと言った状況なわけです。世界平和に繋がっているといっても過言ではありません。
一方でJIS記号由来でunicodeに採用されている一連のマルチバイトな横棒のセンスのなさと言ったらありません。色んな文脈で使われる横棒を全部別々に定義してしまっています。
----------引用ココまで
一般論として、文字の意味を分けて定義しておくというのは、間違った選択ではないと思うんですよね。
統合されたものを分離し直すより、分離されているものを統合し直すほうが遥かに楽なわけです。前者にはなにがしかの判断が（それが「容易」なものであれ）必ず必要ですが、後者は機械的におこなうことができますから。
ただし、ここまで見た目が紛らわしい文字を、ここまで細かく分けて定義してしまっているというのは、間違いなく悪手でしょうね。
ユーザの選択能力を過大評価したのか、単に何も考えていなかったのか…。
慣れた人でも注意深く使い分けないといけないので、慣れていない人の場合は推して知るべし。
さらに、PC上の文字はコードにより抽象化されているということを知らない人の場合、説明しても「見た目は同じなんだから、なんでダメなの？」となってしまうのです。んがくく…。
ちなみに、自分の場合は「-（半角ハイフン マイナス）」、「－（全角ハイフン マイナス）」、「ー（長音）」、「一（漢数字の 1）」を "注意深く" 使い分けるので手一杯です。それ以外は意識的に無視して使わないようにしています。
もっとも、それだけに今回は「―（ダッシュ）」に考えが及ぶのが遅れたんですが…はぁ…。
もうね、ひたすら脱力。
ややこしいデータで、ヒットしない（その名称が含まれない）可能性は色々考えられたので、あれやこれや調べていた。その後だっただけに尚更。
で、その
日本語の横棒記号に絶望した - taichino.com
----------引用ココから
まず半角記号の’-'はハイフンマイナス(0x2d)と呼ばれていて、ハイフンとマイナスの意味を包含した記号になっています。ASCIIコードのビット数の制限があった事を考えても、センスの良さが光る決定だと思います。文脈でハイフンかマイナスかは容易に判断できる訳です。ハイフンとマイナスを別々にしていたら、今頃マイナスのつもりで書いたハイフンに対するコンパイルエラーで世界中のプログラマのイライラは100%水増しと言った状況なわけです。世界平和に繋がっているといっても過言ではありません。
一方でJIS記号由来でunicodeに採用されている一連のマルチバイトな横棒のセンスのなさと言ったらありません。色んな文脈で使われる横棒を全部別々に定義してしまっています。
----------引用ココまで
一般論として、文字の意味を分けて定義しておくというのは、間違った選択ではないと思うんですよね。
統合されたものを分離し直すより、分離されているものを統合し直すほうが遥かに楽なわけです。前者にはなにがしかの判断が（それが「容易」なものであれ）必ず必要ですが、後者は機械的におこなうことができますから。
ただし、ここまで見た目が紛らわしい文字を、ここまで細かく分けて定義してしまっているというのは、間違いなく悪手でしょうね。
ユーザの選択能力を過大評価したのか、単に何も考えていなかったのか…。
慣れた人でも注意深く使い分けないといけないので、慣れていない人の場合は推して知るべし。
さらに、PC上の文字はコードにより抽象化されているということを知らない人の場合、説明しても「見た目は同じなんだから、なんでダメなの？」となってしまうのです。んがくく…。
ちなみに、自分の場合は「-（半角ハイフン マイナス）」、「－（全角ハイフン マイナス）」、「ー（長音）」、「一（漢数字の 1）」を "注意深く" 使い分けるので手一杯です。それ以外は意識的に無視して使わないようにしています。
もっとも、それだけに今回は「―（ダッシュ）」に考えが及ぶのが遅れたんですが…はぁ…。
2015/08/19
ディスプレイ電源オフでウィンドウの配置やサイズが崩れる問題と、その回避方法
Windows7Home 省電力の設定でディスプレイの自動OFF後にマウスなどでディスプレイの電源ONになった際に開いていたいくつかのWindowが全て小さくなる - Microsoft コミュニティ
ディスプレイの電源を切って入れ直すとデスクトップの各ウィンドウサイズが変わる - Microsoft コミュニティ
Windows 利用中にディスプレイの電源をオフにすると、何故かウィンドウの配置やサイズが崩れてしまう（画面左上方へ押し込められてしまう）現象。
どうも画面解像度の変更処理（ないしはそれに類似した処理）が走ってしまっているようなのですが、この現象、自分も困ってるんですよね。
翌日へ作業を持ち越すためにログオフしないでロックだけして帰る時、ディスプレイの電源をオフにできないのです。
放置しておけば省電力モードへ移行するのですが、それまでの間に「マメな人」がディスプレイの電源を切ってくれたりするわけで、そんな時は翌朝悲惨なことになります。
理屈で考えて「ディスプレイからの信号が無くなったからといって解像度を変える必要はなく、新たな信号がくるまで現状の解像度を維持すれば良いだけ」なのですから、この現象はディスプレイドライバの問題であると理解しています。
しかし「仕様」と考えて（＝諦めて）あまり深く突っ込んでいませんでしたが、そうか、VGA端子を使うという手もありましたか。
試しに VGA端子で（わざわざ VGAケーブルを探して）接続して試してみると…おぉ、自分の環境では再現しません。
この辺り、リンク先でも書いておられるように、VGA規格の旧さが奏功しているのでしょうね。
ともあれ、これでメデタシメデタシ…なわけ無いだろ！
CRTディスプレイが絶滅した今、何が悲しくて VGA なんぞ使わなくてはいけないのかと。
----------
そこで、この問題を（とりあえず）回避する「手抜き Tips」を紹介します。
要は、ディスプレイの電源をオフする際、予めディスプレイとログオン中ユーザとの "リンク" を切断しておけばよいのです。
「ディスプレイとログオン中ユーザとの "リンク" を切断」と言ってもどうするか。
ロック（Windowsキー + Lキー）だけでは不可です。前述のとおり再現してしまいます。ログオフすれば当然に切断できますが、それだと意味がありません（やれるならやってる）。
現行のクライアント向け Windows（Windows Vista ～ 8.1、そして恐らく 10 も）であれば、「Ctrlキー + Altキー + Delキー」のメニューを表示して、「ユーザの切り替え」を選択（Altキー + Wキー）します。これで切断されます（正しくは「コンソール・セッションでなくなる」と表現すればいいのかな）。
実際に別のユーザでログオンする必要はなく、この手順でログオン画面にするだけで可です。
復帰する時は、普通にパスワードを入力すればログオンしていたユーザへ戻れます（普通にロックしていた時より、若干時間は要しますが）。
仮にディスプレイの電源が切られていても、ウィンドウの配置やサイズは元のままです。
これで「マメな人」にディスプレイ電源をオフにしてもらっても大丈夫です（…しかし、なんでここまでせにゃならんのだ…という気はする）。
以上、「手抜き Tips」でした。
まぁ「手抜き」とはいっても、「手を抜かず回避」（＝解決）しようとすると、恐らくディスプレイドライバに対応してもらうしか無いんですけどね、この問題。
----------
世の中、有徳の士というのはいらっしゃるもので、解決方法が公開されていました。
DisplayPort接続時のディスプレイのオンオフによるウィンドウの再配置について - 塵の雨日記
以下のレジストリを変更すると、ディスプレイを切断してもウィンドウの配置やサイズが崩れないとのこと。
物理ディスプレイ切断時に切り替わる仮想的なディスプレイがあって、その画面サイズがこのレジストリ値で指定できるのでしょう。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_（数字アルファベットの羅列）\00]
PrimSurfSize.cx = 横ピクセル数
PrimSurfSize.cy = 縦ピクセル数
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_（数字アルファベットの羅列）\00\00]
ActiveSize.cx = 横ピクセル数
ActiveSize.cy = 縦ピクセル数
この現象、Windows 10 では発生しませんが、やはりまだまだ Windows 7 や 8 の方もいらっしゃることですし、Afterfollow として追記しておきます。
ディスプレイの電源を切って入れ直すとデスクトップの各ウィンドウサイズが変わる - Microsoft コミュニティ
Windows 利用中にディスプレイの電源をオフにすると、何故かウィンドウの配置やサイズが崩れてしまう（画面左上方へ押し込められてしまう）現象。
どうも画面解像度の変更処理（ないしはそれに類似した処理）が走ってしまっているようなのですが、この現象、自分も困ってるんですよね。
翌日へ作業を持ち越すためにログオフしないでロックだけして帰る時、ディスプレイの電源をオフにできないのです。
放置しておけば省電力モードへ移行するのですが、それまでの間に「マメな人」がディスプレイの電源を切ってくれたりするわけで、そんな時は翌朝悲惨なことになります。
理屈で考えて「ディスプレイからの信号が無くなったからといって解像度を変える必要はなく、新たな信号がくるまで現状の解像度を維持すれば良いだけ」なのですから、この現象はディスプレイドライバの問題であると理解しています。
しかし「仕様」と考えて（＝諦めて）あまり深く突っ込んでいませんでしたが、そうか、VGA端子を使うという手もありましたか。
試しに VGA端子で（わざわざ VGAケーブルを探して）接続して試してみると…おぉ、自分の環境では再現しません。
この辺り、リンク先でも書いておられるように、VGA規格の旧さが奏功しているのでしょうね。
ともあれ、これでメデタシメデタシ…なわけ無いだろ！
CRTディスプレイが絶滅した今、何が悲しくて VGA なんぞ使わなくてはいけないのかと。
----------
そこで、この問題を（とりあえず）回避する「手抜き Tips」を紹介します。
要は、ディスプレイの電源をオフする際、予めディスプレイとログオン中ユーザとの "リンク" を切断しておけばよいのです。
「ディスプレイとログオン中ユーザとの "リンク" を切断」と言ってもどうするか。
ロック（Windowsキー + Lキー）だけでは不可です。前述のとおり再現してしまいます。ログオフすれば当然に切断できますが、それだと意味がありません（やれるならやってる）。
現行のクライアント向け Windows（Windows Vista ～ 8.1、そして恐らく 10 も）であれば、「Ctrlキー + Altキー + Delキー」のメニューを表示して、「ユーザの切り替え」を選択（Altキー + Wキー）します。これで切断されます（正しくは「コンソール・セッションでなくなる」と表現すればいいのかな）。
実際に別のユーザでログオンする必要はなく、この手順でログオン画面にするだけで可です。
復帰する時は、普通にパスワードを入力すればログオンしていたユーザへ戻れます（普通にロックしていた時より、若干時間は要しますが）。
仮にディスプレイの電源が切られていても、ウィンドウの配置やサイズは元のままです。
これで「マメな人」にディスプレイ電源をオフにしてもらっても大丈夫です（…しかし、なんでここまでせにゃならんのだ…という気はする）。
以上、「手抜き Tips」でした。
まぁ「手抜き」とはいっても、「手を抜かず回避」（＝解決）しようとすると、恐らくディスプレイドライバに対応してもらうしか無いんですけどね、この問題。
----------
Afterfollow 2016/10/03
世の中、有徳の士というのはいらっしゃるもので、解決方法が公開されていました。
DisplayPort接続時のディスプレイのオンオフによるウィンドウの再配置について - 塵の雨日記
以下のレジストリを変更すると、ディスプレイを切断してもウィンドウの配置やサイズが崩れないとのこと。
物理ディスプレイ切断時に切り替わる仮想的なディスプレイがあって、その画面サイズがこのレジストリ値で指定できるのでしょう。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_（数字アルファベットの羅列）\00]
PrimSurfSize.cx = 横ピクセル数
PrimSurfSize.cy = 縦ピクセル数
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_（数字アルファベットの羅列）\00\00]
ActiveSize.cx = 横ピクセル数
ActiveSize.cy = 縦ピクセル数
この現象、Windows 10 では発生しませんが、やはりまだまだ Windows 7 や 8 の方もいらっしゃることですし、Afterfollow として追記しておきます。
2015/08/18
Heartbleed 脆弱性への対応と、技術への理解
セキュリティ関連企業のホワイトペーパを読んでいたら、Heartbleed 脆弱性への対応で SSL証明書を入替えた際、秘密鍵を変更しないまま証明書を再発行している Webサーバーが多いらしい。
馬鹿な、有り得ないだろ。
事実だとすれば、大きく二重の不見識だと思う。
一つは、Heartbleed 脆弱性の内容（プロセスのメモリ内容が漏洩 ＝ 秘密鍵が漏洩）を理解しないまま、「SSL証明書を再発行しないといけない」という上っ面だけの対応をしてしまっていること。
もう一つは、そもそも SSL証明書を再発行（更新）する際は、新しい秘密鍵を使わなければいけないという大原則に反していること。
セキュリティ関連企業のホワイトペーパーである（多少なりと宣伝の色彩がある）ことを割引いて読まないといけないのだろうけれど、自身の経験でも、何も考えずに長い有効期限（複数年）の証明書を選択したり、あまつさえ CSR を使い廻したりするのを見てきているので、あながち誇張だとばかりも思えない。
どちらも、複数年にわたって「同じ秘密鍵を使い続ける」という事なので。特に後者（CSR の使い廻し）は、公開鍵基盤や公開鍵暗号の仕組を理解していたら絶対にしない選択だと思う。
「技術」というのは IT関連に限らず、詳細はともかく概要だけでも理解していないと安全に使うことすら叶わないのだと、改めて思うのです。
馬鹿な、有り得ないだろ。
事実だとすれば、大きく二重の不見識だと思う。
一つは、Heartbleed 脆弱性の内容（プロセスのメモリ内容が漏洩 ＝ 秘密鍵が漏洩）を理解しないまま、「SSL証明書を再発行しないといけない」という上っ面だけの対応をしてしまっていること。
もう一つは、そもそも SSL証明書を再発行（更新）する際は、新しい秘密鍵を使わなければいけないという大原則に反していること。
セキュリティ関連企業のホワイトペーパーである（多少なりと宣伝の色彩がある）ことを割引いて読まないといけないのだろうけれど、自身の経験でも、何も考えずに長い有効期限（複数年）の証明書を選択したり、あまつさえ CSR を使い廻したりするのを見てきているので、あながち誇張だとばかりも思えない。
どちらも、複数年にわたって「同じ秘密鍵を使い続ける」という事なので。特に後者（CSR の使い廻し）は、公開鍵基盤や公開鍵暗号の仕組を理解していたら絶対にしない選択だと思う。
「技術」というのは IT関連に限らず、詳細はともかく概要だけでも理解していないと安全に使うことすら叶わないのだと、改めて思うのです。
2015/06/19
OpenDKIM の評価は、ヘッダFrom（≠ envelope-From）に対して実施される
SendMail + OpenDKIM の構築をしていて、検証作業でハマりました。
教訓：
OpenDKIM の評価は、ヘッダFrom（≠ envelope-From）に対して実施される
設定が終わって、検証しようと telnet でポート 25 へ接続して手作業でメール送信したのですが、何故か全く署名されない。
？？？となりつつ、散々あっちを弄りこっちを弄りした後、ふと思い立って通常のローカルメーラから送信したところ…此は如何に、あっさり署名が付加されました。
カラクリは恐らくこうかと。
telnet にて手作業で送信した場合、明示的に記述しない限りヘッダ From は付加されません（まぁ当然です）。その場合、次の MTA へ配送される前に、MTA により envelope-From を使ってヘッダ From が補完されます。その為、通常は意識されません。
しかし、OpenDKIM の処理（というか SendMail INPUT_MAIL_FILTER の処理）は、このヘッダ From が補完前におこなわれるようなのです。
結果、空のヘッダ From が評価され、「署名対象外メール」と判定されていたのだと考えています。
その後、ヘッダ From が補完され、そのメールが届いていたので「ちゃんと対象の From だよなぁ…」と気がつくのが遅れました。
OpenDKIM の評価はヘッダ From に対して実施される（これもまぁ当然です）、と明示的に認識していれば、もう少し早く気がつくことができたと思うのですが…。
教訓：
OpenDKIM の評価は、ヘッダFrom（≠ envelope-From）に対して実施される
設定が終わって、検証しようと telnet でポート 25 へ接続して手作業でメール送信したのですが、何故か全く署名されない。
？？？となりつつ、散々あっちを弄りこっちを弄りした後、ふと思い立って通常のローカルメーラから送信したところ…此は如何に、あっさり署名が付加されました。
カラクリは恐らくこうかと。
telnet にて手作業で送信した場合、明示的に記述しない限りヘッダ From は付加されません（まぁ当然です）。その場合、次の MTA へ配送される前に、MTA により envelope-From を使ってヘッダ From が補完されます。その為、通常は意識されません。
しかし、OpenDKIM の処理（というか SendMail INPUT_MAIL_FILTER の処理）は、このヘッダ From が補完前におこなわれるようなのです。
結果、空のヘッダ From が評価され、「署名対象外メール」と判定されていたのだと考えています。
その後、ヘッダ From が補完され、そのメールが届いていたので「ちゃんと対象の From だよなぁ…」と気がつくのが遅れました。
OpenDKIM の評価はヘッダ From に対して実施される（これもまぁ当然です）、と明示的に認識していれば、もう少し早く気がつくことができたと思うのですが…。
2015/06/07
Excel データの改行コードを変換
謎仕様なのですが、Microsoft Excel のセル内改行コードは LF（0x0A）だったりします。
一方、Windows OS 標準の改行コードは、CR+LF（0x0D0A）です。
この辺りの相違にはきっと歴史的な経緯があるのでしょうが、具体的な事情は寡聞にして謎のままです。一説によると、Excel は当初 Mac 用（Mac の改行コードは LF）のアプリケーションとして開発された為だそうですが、真偽の程は？
確かなことは、この改行コードの相違が時としてトラブルの原因になることです。
Excel でデータを一括で入力して、それを他のシステムで利用するといったシーンで、改行コードの相違を意識せずに処理してしまうと、利用先システムで改行されずにベッタリ一行で表示されてしまったりします。
なので、そういう場合どこかで改行コードを変換する必要があります。
いろいろな段階で、いろいろな手法があり、「真面目」なやり方としたら Excel 上で VBScript を使ったり、データベース上で SQL を使ったりとかになるかと思います。
しかし、今回の方法はズバリ、相当にズボラな方法です。
必要な物は、テキストエディタ。
ただし、改行コードの自動変換をしてくれないとダメですので、「メモ帳」では NG です（ただし、これはこれで使い様が…後述）。
動作確認したのは「秀丸エディタ」ですが、「サクラエディタ」とかも同様に処理してくれるようです。
手順は以下のとおり。
ちなみに、Excel は 2010 ですが、他のバージョンでも問題ないものと思います。
以上で、見た目は変わりませんが、Excel 上のデータの改行コードは CR+LF になっています。
ただし、後から追加した改行については LF になりますのでご注意を。
ちゃんと改行コードが変換されたかの確認方法ですが、これは「メモ帳」を使ってズボラします。
「メモ帳」は LF のみの改行に対応していないので、貼り付けたデータが改行されていなければ LF ですし、改行されていれば CR+LF と判断できます。
試しに、手順1 のデータを（複数セルだと判りにくいので 1セルだけ）貼り付ければ改行されないでしょうし、手順6 のデータを貼り付ければ改行されるはずです。
なお、手順 3, 4 は省いても多分問題無いと思います。少なくとも、「秀丸エディタ」の場合は問題ありません。
ただ、保存するときに機種依存文字がチェックされますので（これも「秀丸エディタ」の場合は…ですが）、自分は一手間入れるようにしています。
一方、Windows OS 標準の改行コードは、CR+LF（0x0D0A）です。
この辺りの相違にはきっと歴史的な経緯があるのでしょうが、具体的な事情は寡聞にして謎のままです。一説によると、Excel は当初 Mac 用（Mac の改行コードは LF）のアプリケーションとして開発された為だそうですが、真偽の程は？
確かなことは、この改行コードの相違が時としてトラブルの原因になることです。
Excel でデータを一括で入力して、それを他のシステムで利用するといったシーンで、改行コードの相違を意識せずに処理してしまうと、利用先システムで改行されずにベッタリ一行で表示されてしまったりします。
なので、そういう場合どこかで改行コードを変換する必要があります。
いろいろな段階で、いろいろな手法があり、「真面目」なやり方としたら Excel 上で VBScript を使ったり、データベース上で SQL を使ったりとかになるかと思います。
しかし、今回の方法はズバリ、相当にズボラな方法です。
必要な物は、テキストエディタ。
ただし、改行コードの自動変換をしてくれないとダメですので、「メモ帳」では NG です（ただし、これはこれで使い様が…後述）。
動作確認したのは「秀丸エディタ」ですが、「サクラエディタ」とかも同様に処理してくれるようです。
手順は以下のとおり。
ちなみに、Excel は 2010 ですが、他のバージョンでも問題ないものと思います。
- Excel： 適宜範囲選択して Ctrl+C でコピー
- テキストエディタ： Ctrl+V で貼り付け
- テキストエディタ： [名前を付けて保存] （選択できるようなら、改行コード CR+LF を選択）
- テキストエディタ： 保存したファイルを開き直す
- テキストエディタ： 貼り付けた範囲を選択して Ctrl+C でコピー
- Excel： Ctrl+V で貼り付け
以上で、見た目は変わりませんが、Excel 上のデータの改行コードは CR+LF になっています。
ただし、後から追加した改行については LF になりますのでご注意を。
ちゃんと改行コードが変換されたかの確認方法ですが、これは「メモ帳」を使ってズボラします。
「メモ帳」は LF のみの改行に対応していないので、貼り付けたデータが改行されていなければ LF ですし、改行されていれば CR+LF と判断できます。
試しに、手順1 のデータを（複数セルだと判りにくいので 1セルだけ）貼り付ければ改行されないでしょうし、手順6 のデータを貼り付ければ改行されるはずです。
なお、手順 3, 4 は省いても多分問題無いと思います。少なくとも、「秀丸エディタ」の場合は問題ありません。
ただ、保存するときに機種依存文字がチェックされますので（これも「秀丸エディタ」の場合は…ですが）、自分は一手間入れるようにしています。
Windows の悪仕様 [F1] キーを無効化
[F1] キーで「ヘルプ」が開くのは Windows の悪仕様である…というのは、衆目一致するところだと思うのですが、バージョンを重ねても代々踏襲され続けていますよね。
多分、Windows 10 でも引継がれるんでないでしょうか。
これ、[F2] キーを使用する際によく押し間違えるんですよ。[F2] キーは、ファイル名の変更や、Excel セル値の変更で多用するキーです。
押し間違える都度、「ヘルプ」が開くわけです。しかも、マシンスペックによっては開くまでに相応の時間を要する上、その間操作できなくなり非常にストレスフルです。
そこで、OS のスキャンコードマップを変更して、[F1] キーを無効にしてしまいます。
これ、かれこれ 2、3年ほど前から設定していますが、意図せず開く「ヘルプ」に煩わされることもなくなり、非常に快適です。
この方法の問題点としては、OS レベルで完全にキーを無効にしてしまうので、[F1] キーが全く使えなくなるということがあります。
とはいえ幸か不幸か、ほとんどのアプリケーションで [F1] キーは「ヘルプ」に割当てられているため、今のところ困ったことはありません。ただ、一部特殊なアプリケーション（キーボードをフルに使うゲームとか）では問題が発生するかもしれません。まぁ私の場合は、ゲームをあまりしない人間なので。
さて、設定方法ですが、レジストリを変更します。
「『レジストリ』って何？」という方は、とんでもないところを編集してしまうとシステムに致命的なダメージを与えかねませんので、やらないほうが無難だと思います。なので、エディタの起ち上げ方等、作業の具体的手順については触れません。
ターゲットのレジストリキーは、以下になります。
OS 全体に適用する場合：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
ログオン中のユーザにのみ適用する場合：
[HKEY_CURRENT_USER\KeyBoard Layout]
いずれかのキーの下へ、以下の値を追加します。
名前： Scancode Map
種類： バイナリ値（REG_BINARY）
で、この値に入れるデータは次のとおり。
00 00 00 00 00 00 00 00 02 00 00 00 00 00 3B 00 00 00 00 00
これの意味するところは、以下のようになります。
00 00 00 00 ：ヘッダ（固定）
00 00 00 00 ：ヘッダ（固定）
02 00 00 00 ：設定の数（1） + 1（フッタ分）
00 00 3B 00 ：無効（0x0000） ← F1（0x003B）
00 00 00 00 ：フッタ（固定）
なので、別に「無効（0x0000）」としなくても、他のキーに割り当てることも可能です。
コードの一覧は、以下が参考になります。
Keyboard Scan Code Specification - Microsoft
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc
なお、レジストリ値に組込む際は、リトルエンディアンになることに留意してください。例えば、[右Alt] キーはコード 0xE038 ですが、レジストリ値へは 38 E0 となります。
コードは左右入換て使わないといけない、と覚えておけば良いかと思います。
ご参考まで、私の設定値を上げておきます。
00 00 00 00 ：ヘッダ（固定）
00 00 00 00 ：ヘッダ（固定）
04 00 00 00 ：設定の数（3） + 1（フッタ分）
5C E0 38 E0 ：右Windows（0xE05C） ← 右Alt（0xE038）
5D E0 1D E0 ：Application（0xE05D） ← 右Ctrl（0xE01D）
00 00 3B 00 ：無効（0x0000） ← F1（0x003B）
00 00 00 00 ：フッタ（固定）
多分、Windows 10 でも引継がれるんでないでしょうか。
これ、[F2] キーを使用する際によく押し間違えるんですよ。[F2] キーは、ファイル名の変更や、Excel セル値の変更で多用するキーです。
押し間違える都度、「ヘルプ」が開くわけです。しかも、マシンスペックによっては開くまでに相応の時間を要する上、その間操作できなくなり非常にストレスフルです。
そこで、OS のスキャンコードマップを変更して、[F1] キーを無効にしてしまいます。
これ、かれこれ 2、3年ほど前から設定していますが、意図せず開く「ヘルプ」に煩わされることもなくなり、非常に快適です。
この方法の問題点としては、OS レベルで完全にキーを無効にしてしまうので、[F1] キーが全く使えなくなるということがあります。
とはいえ幸か不幸か、ほとんどのアプリケーションで [F1] キーは「ヘルプ」に割当てられているため、今のところ困ったことはありません。ただ、一部特殊なアプリケーション（キーボードをフルに使うゲームとか）では問題が発生するかもしれません。まぁ私の場合は、ゲームをあまりしない人間なので。
さて、設定方法ですが、レジストリを変更します。
「『レジストリ』って何？」という方は、とんでもないところを編集してしまうとシステムに致命的なダメージを与えかねませんので、やらないほうが無難だと思います。なので、エディタの起ち上げ方等、作業の具体的手順については触れません。
ターゲットのレジストリキーは、以下になります。
OS 全体に適用する場合：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
ログオン中のユーザにのみ適用する場合：
[HKEY_CURRENT_USER\KeyBoard Layout]
いずれかのキーの下へ、以下の値を追加します。
名前： Scancode Map
種類： バイナリ値（REG_BINARY）
で、この値に入れるデータは次のとおり。
00 00 00 00 00 00 00 00 02 00 00 00 00 00 3B 00 00 00 00 00
これの意味するところは、以下のようになります。
00 00 00 00 ：ヘッダ（固定）
00 00 00 00 ：ヘッダ（固定）
02 00 00 00 ：設定の数（1） + 1（フッタ分）
00 00 3B 00 ：無効（0x0000） ← F1（0x003B）
00 00 00 00 ：フッタ（固定）
なので、別に「無効（0x0000）」としなくても、他のキーに割り当てることも可能です。
コードの一覧は、以下が参考になります。
Keyboard Scan Code Specification - Microsoft
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc
なお、レジストリ値に組込む際は、リトルエンディアンになることに留意してください。例えば、[右Alt] キーはコード 0xE038 ですが、レジストリ値へは 38 E0 となります。
コードは左右入換て使わないといけない、と覚えておけば良いかと思います。
ご参考まで、私の設定値を上げておきます。
00 00 00 00 ：ヘッダ（固定）
00 00 00 00 ：ヘッダ（固定）
04 00 00 00 ：設定の数（3） + 1（フッタ分）
5C E0 38 E0 ：右Windows（0xE05C） ← 右Alt（0xE038）
5D E0 1D E0 ：Application（0xE05D） ← 右Ctrl（0xE01D）
00 00 3B 00 ：無効（0x0000） ← F1（0x003B）
00 00 00 00 ：フッタ（固定）
2015/06/05
Web Form での IME制御を無効化
Web Form で自動的に IME（日本語変換）が on/off される、あの制御の話です。
あれ、正直非常に迷惑です。
多くの人がそうだと思うんですが、勝手に制御されずとも半ば無意識に左手が動いて IME の on/off を切り替えるんですよね。「あ、ここは日本語で入力しないと（無意識に IME on）」、「ここは英文字入力ね（無意識に IME off）」といった具合です（厳密に言えば、自分の場合は日本語入力が終わったら、直ちに IME を off にするんですが）。
なので、勝手に IME の制御をされると、言わずもがなですが途端におかしな事になってしまいます。
そこで、この IME の自動制御を、強制的に無効化します。
Internet Explorer 8 以降であれば、以下の方法で無効化できます（それより旧い Internet Explorer でもできるかもしれませんが、手元にないもので）。
まず、テキストエディタ（メモ帳とか）で以下のファイルを作り、拡張子「.css」（ファイル名は何でもいいです）で適当な場所へ配置します。
自分でしたら、%APPDATA%\Microsoft\Internet Explorer 辺りに配置しますが、間違って消さないような場所であれば、どこでも結構です。
---------- .css ココから
* {
ime-mode: auto !important;
}
---------- .css ココまで
そして、Internet Explorer の [ツール]-[インターネット オプション]-[全般]-[ユーザー補助] と開いて、[自分のスタイル シートでドキュメントの書式を設定する] チェックボックスを on にします。[参照] ボタンが有効になるので、ボタンを押して先に作成した「.css」ファイルを指定します。
あとは [OK] ボタンを押していって設定ダイアログを閉じれば完了です。
念のため、OS 再起動（おまじないです）。
これで、IME の制御を無視してくれるようになります。
現行バージョンの FireFox（Ver. 38）であれば、以下の方法で無効化できます（それより旧いバージョンに関しては…同上）。
Internet Explorer と同じ内容で、CSS ファイルを作ります。
ただしファイル名は「userContent.css」とします。
そのファイルを以下のフォルダへ配置します。
最後の「chrome」というフォルダは、最近の FireFox であれば存在していないと思いますので、その場合は自分でディレクトリを作ってください。
%APPDATA%\Mozilla\Firefox\Profiles\英数字.default\chrome\
以上で完了です。
念のため、OS 再起動（同上）。
これで、IME の制御を無視してくれるようになります。
Google Chrome の場合は、設定の必要がありません。
IME への制御を端から無視するようになっています。いえそもそも、どう頑張っても制御することができません。
この辺り意見が分かれるかもしれませんが、IME制御反対派としては viva Google Chrome!
あれ、正直非常に迷惑です。
多くの人がそうだと思うんですが、勝手に制御されずとも半ば無意識に左手が動いて IME の on/off を切り替えるんですよね。「あ、ここは日本語で入力しないと（無意識に IME on）」、「ここは英文字入力ね（無意識に IME off）」といった具合です（厳密に言えば、自分の場合は日本語入力が終わったら、直ちに IME を off にするんですが）。
なので、勝手に IME の制御をされると、言わずもがなですが途端におかしな事になってしまいます。
そこで、この IME の自動制御を、強制的に無効化します。
Internet Explorer
Internet Explorer 8 以降であれば、以下の方法で無効化できます（それより旧い Internet Explorer でもできるかもしれませんが、手元にないもので）。
まず、テキストエディタ（メモ帳とか）で以下のファイルを作り、拡張子「.css」（ファイル名は何でもいいです）で適当な場所へ配置します。
自分でしたら、%APPDATA%\Microsoft\Internet Explorer 辺りに配置しますが、間違って消さないような場所であれば、どこでも結構です。
---------- .css ココから
* {
ime-mode: auto !important;
}
---------- .css ココまで
そして、Internet Explorer の [ツール]-[インターネット オプション]-[全般]-[ユーザー補助] と開いて、[自分のスタイル シートでドキュメントの書式を設定する] チェックボックスを on にします。[参照] ボタンが有効になるので、ボタンを押して先に作成した「.css」ファイルを指定します。
あとは [OK] ボタンを押していって設定ダイアログを閉じれば完了です。
念のため、OS 再起動（おまじないです）。
これで、IME の制御を無視してくれるようになります。
Fire Fox
現行バージョンの FireFox（Ver. 38）であれば、以下の方法で無効化できます（それより旧いバージョンに関しては…同上）。
Internet Explorer と同じ内容で、CSS ファイルを作ります。
ただしファイル名は「userContent.css」とします。
そのファイルを以下のフォルダへ配置します。
最後の「chrome」というフォルダは、最近の FireFox であれば存在していないと思いますので、その場合は自分でディレクトリを作ってください。
%APPDATA%\Mozilla\Firefox\Profiles\英数字.default\chrome\
以上で完了です。
念のため、OS 再起動（同上）。
これで、IME の制御を無視してくれるようになります。
Google Chrome
Google Chrome の場合は、設定の必要がありません。
IME への制御を端から無視するようになっています。いえそもそも、どう頑張っても制御することができません。
この辺り意見が分かれるかもしれませんが、IME制御反対派としては viva Google Chrome!
登録:
投稿 (Atom)