コロナショックとアベノミクストレンドライン

  • 投稿日:
  • by
  • カテゴリ:

日経平均株価が過去最大の下げ幅ということで日足チャート。

20200313nikkeidaily.png

そして週足チャート。

20200313nikkeiweekly.png

最後に月足チャート。

20200313nikkeimonthly.png

2012年の衆議院解散以来続いてきたアベノミクスでのトレンドラインを割り込み半分くらいが失われた。チャート上は15,000円辺りまではありそうだが...

3月のメジャーSQにぶち当たったタイミングもよくなかった。SQに向かって突っ走ることがよくあるからね。清算値は17,052円 89銭とのこと。13日の米国はトランブ大統領が国家非常事態を宣言したことで大きく上げている。週明けも値動きが大きそうだ。

日本市場はSQを通過したことで、しばらくレンジかトライアングルを形成するような気がする。その答えは次のメジャーSQである6月頃だろうか。その頃には東京五輪の行方も決しているだろう。多分ね。

トレードステーションの分析テクニック

  • 投稿日:
  • by
  • カテゴリ:

 サイトが保守モードに入っているので今更なのですが、マネックス証券のトレードステーションに使用できる分析テクニックをアップデートしました。

 秒チャート(但し30秒だけ、状況によっては20秒くらいまで表示するかもしれない程度)、分足のみ適用可能なものをうっかり日足に切り換えるとエラーとなって分析テクニックが無効となるのを回避など。 また設定していたパスワードを解除したのでコードを閲覧できますが質疑は一切受け付けません。

 プチ、トレードステーションのグチ
 ホットリストの前日比(何故か左揃え)を右揃え表示に変更していて、決算だか何だか知らないけどその日は左揃えに変わり数字の前にゴミが付く。翌日左揃えのままなので右揃えに変えようとすると落ちる。しかたないので月に一度はホットリストを作り直す。実際はなぜか右揃えが定着しているホットリストウィンドウがあってコピーするのだが、コピーしたものはやはり翌月落ちる、新規で作っても同じ(新規はカラム合わせが面倒)、なんじゃこりゃ。ついでに前日比マイナスの表記もおかしい、デフォは"-"なのに右寄せするとなぜ"()"に変わる。フォーマットを数字にすれば"-"となるけど月一落ちるのは変わらない。
 チャートを選択するのにチャートの余白をクリックすると、ウィンドウの設定を表示する確率が高い(ver9.4では無かった気がするが)、なので表示意味のないウィンドウタイトルをチャートウィンドウで表示して、ウィンドウタイトルをクリックしチャートを選択しているが、たまにミスる。銘柄コードをドラッグ&ドロップできればそれほど気にしないが出来ないからイラっと......
 キリがないのだけどね

お問い合わせフォームにまつわるあれこれ

  • 投稿日:
  • by
  • カテゴリ:

 (この記事は要約するとGoogle reCAPTCHA v3を皆ちゃんと実装しているのかよ!というグチです)

 ひと月ちょっと前に、CS60新神戸を立ち上げるという相談がありました。早い話、ネット予約が出来るようにしたいということで、これについては早々に使えるソリューションを見つけました。

 問い合わせも必要だよねと、「お問い合わせフォーム」を設置するためにいくつか検索してみると、Googleフォームを利用する方法が見つかります。で、試すわけですが、送信者がGmailのアドレスだし回答のコピーを自動送信できるけど、これ求めているものとちょっと違う。さらに検索するとGoogle Apps Scriptと組み合わせると、問い合わせの内容を自動返信できるようになったので、まあこれでよいかなと一段落。と思ったのですが、運用するには不安な要素も。

  • フォームをメンテするときにうっかり操作ミスすると、既存問い合わせ済みのものが再送信される事故
  • フォームをサイトに設置したときに下部に「このコンテンツは Google が作成または承認したものではありません。」などという文言を表示、割り切ればよいことだけど
  • スパム対策はどうするの?Googleフォーム自体で自動送信するときは、画像選択のボット対策があるようだけど、それを無効にしてGoogle Apps Scriptで対抗する場合は無い?

 実際、Googleフォームで運用しているところも見られるので悪くはないと思うのですが、コントロールが難しいのがね。スプレッドシートへ自動転記されていくので記録として残すのに便利なのですけど。

 書込みフリーな「お問い合わせフォーム」というのはスパムメールの温床に繋がるので、スパム対策をどうしようかなと探していると、Google reCAPTCHAを使ったものが見かけられます。「私はロボットではありません」というやつもそれの一バージョンです。

 ベースとなるメールフォームは、フリー素材として配布されているものを流用。それにGoogle reCAPTCHA v2を設定(なぜv2を選んだかは直感)。それを組み込み色々試して使えそうかなと、各種ブラウザでの確認を始めたところ、Chromeだけ何故かうまくいきません。なぜかSubmitするボタンが無効になってしまう。さらにreCAPTCHA v2のチェックボックスではなく、Submitボタンやその近傍をくりっくしてもreCAPTCHA v2が反応する、なぜか画像選択がでまくる。といったことで散々な結果に。Android Chromeだと問題ないのに。

 reCAPTCHA v2を諦め、reCAPTCHA v3を実装に切り換え。この両者何が違うかというと、

  • v2はフォーム内に「私はロボットではありません」のチェックボックスが設置されるのに対し、v3は設置されない。ただブラウザ右下にreCAPTCHAのシールが常に貼られる
  • v2、v3ともにトークンという一定期間有効なデータを生成しサーバーへ送信。サーバー側でGoogleへ問い合わせ有効か否かを確認。異なるのはv3ではスコアという評価値が返ってくること。スコアが低いと怪しいやつという判断に繋がる

 さて、reCAPTCHA v3に切り換わっても、実装はほとんど変わらないと思いきやトークンの生成に落とし穴がありました。

 v2ではチェックボックスをチェックしてから再び要求されるまではトークンが有効なのでトークンの有効期間を意識する必要はないのですが、v3はページを表示してからトークンの管理が始まっていたのです。v3を記事にしてよく見掛けるのはページを表示したとき直後にトークンを取得、もう一つはフォームをSubmitするときにトークンを取得というパターン。

Goolgeのサンプルコードとして、次のコードを実行してねというのがあります。しかしv3の実装には落とし穴が待っていました。

  <script>
grecaptcha
.ready(function() {
grecaptcha
.execute('reCAPTCHA_site_key', {action: 'homepage'}).then(function(token) {
...
});
});
</script>
  • ページロード直後にgrecaptcha.execute()を実行しないと、サーバーチェックで "invalid-input-response" エラー
  • ページロード直後にgrecaptcha.execute()を実行しても、フォーム内にデータを埋め込まないとやはり"invalid-input-response" エラー
  • 定期的にgrecaptcha.execute()実行してトークンを再取得しないと、"timeout-or-duplicate" エラー。定期的というのは2分から3分の間の模様
  • 落とし穴ではないけどSubmit時にgrecaptcha.execute()しても、直近のgrecaptcha.execute()の結果とトークンが変わらなかった。推測するにGoogle reCAPTCHA v3はページを表示してから常に一定毎にトークンを更新する必要(かつページ内の埋め込みデータも更新)があって、更新しないとタイムアウト。頻繁にgrecaptcha.execute()しても一定期間はトークンが変わらないという特性がある模様

この落とし穴を確認するために、スコアが最低になるという状況も起きました。これらを検索してみたのですが日本語ページでは見つけられなくて、海外掲示板でこれに嵌りこんでいるのを見掛けました。日本語記事の多くがWordPressのContact Form 7というプラグインとの組み合わせなので個別運用で悩んでいる方は少ないのかもしれません。

あれこれコードを書いて、結局ページロード直後に実行およびsetIntervalによる定期実行に落ち着きました。

 せっかくなので、Googleフォーム風のチェックも出来るようにしたいと、フォームのページをサンプルから変更しています。jQueryを使うとこんなことが出来るんだねと感心しながらね。

 さてGoogle reCAPTCHA v3のスコア運用ですが、今は 0.5未満 で運用しようと考えています。ときどきスコアが悪くて送信しないという可能性があるのですが、スパムボット対策ということで配慮いただけたらと思います。(CS60新神戸を利用しようとする人でこれを見るのはほとんどいないと思いますが)

令にもいろいろあります

  • 投稿日:
  • by
  • カテゴリ:

20190401_reiwa.png

次の元号が発表されたわけですが、令という字を普段手書きする機会がほとんどなかったと思う。手書きでは楷書体だと思うのだけど、菅官房長官が掲げたものはどれなのだろうね。明朝にやや忖度?

20190401_reiwahapyo.png

明朝と楷書体や教科書では形が違うのですが、電算化というものの影響なのか、場所によっては、明朝の書き方じゃないと受け付けないところもあるらしい。普段身の回りには明朝かゴシックしかないしね。
ペン字は楷書体が基本だろうから、人によっては反発があるのかな。

違いについて、その内にバラエティ番組で取り上げられるのでしょうね。

ところで、「れいわ」を「令和」と素直に変換できた。IMEの予測変換をオフ、学習情報の消去をしても変換候補としてリストされる。実は先回りをして・・・なんてことがあるわけないか

と思ったけど、念のために...

Windows Vista ×
Windows 7 ×
Windows 8 〇
Windows 8.1 〇
Windows 10 バージョン1511 〇
Windows 10 バージョン1809 〇

Windows10では、今日初めてスリープから復帰させたPCでサインインする前にネットワーク接続を切ったので、どこかから引っ張ってきたということは無いはず。MSよ、どこから持ってきた?

発表されてすぐに検索したら"川岸令和"がヒットしたのだけど、それで登録されていた?

追記)手持ちのインストールイメージをVMWare Playerに試したら、Windows 8から入っていた。人名かな?

以前に次の記事を書いたのですが、所謂「おま環」だったようです。

メールの文字化け表示、Outlook2010は自己解決できないので、設定を見直してくれたらうれしい

私の場合、自宅でOfficeのOutlookを使い始めたのは2001年頃で、最初に作成したOutlook データファイルをそのまま使い続けています。どうやらそれが悪かったようで、当時のファイル形式は、「Outlook 97-2002 データ ファイル (*.pst)」というものです。

某サービスを検証していたところ、自動送信のメールがUTF-8でエンコードされていました。このことを某サービスへ問い合わせたところ、"今後の参考"というよくある返事を頂いたのですが、あらためて検索し直したところ、解決策に当たりました。

マイクロソフト コミュニティ:Outlook2013で受信メールが文字化けしてしまう。
意訳:Outlook データ ファイルを作り直せ
注)回答の中の、"送信メッセージで優先使用するエンコード方法 : 日本語 (シフトJIS) に変更"は、日本語 (JIS)の誤記かと

で、作成し直し某サービスのメールを受信しました。文字化けは解消!

ここまではよいのですが、代償が「仕分けルール」の破損でした。以前からワーニング状態でしたが "レジストリまたはインストールに・・・" というエラーで止めを刺してしまい、解決方法は仕分けルールの初期化か再インストール(あるいはOutlookのプロファイル作成し直し)。

次のページをみて「仕分けルール」の初期化と再作成が進行中です。

マイクロソフト コミュニティ:メール仕分けルールができなくなった。

「仕分けルール」が少ない人はしかたないなと実行できるのですが、多い人は・・使い続けるしかないかも。

もし実行する場合には、プロファイルのレジストリバックアップと、Outlook データファイルのバックアップさえあればなんとか元に戻すことは可能です。ここを参考にしてください。Outlook2013でも同様です。

Outlook 2010 を引っ越してみる

最後に、既に受信してしまった文字化けメールを新しいOutlookデータファイルへコピーしても文字化けは直りません、残念。

追記)馬渕さんのPCにも古いOutlookデータファイルがあって文字化けが起きてる。で、やってみたら、仕分けルールが初期化されるという事態があったものの事前に仕分けルールをエクスポートしていたおかげで事なきを得た。PCが2台あってサブで新しいファイルへ移行してから、メインへ移すということを行ったので一般的な環境とは違うかも。

半値八掛け五割引

  • 投稿日:
  • by
  • カテゴリ:

20190206_sanbio4592.gif

 数年に一度の下落だと思うので、チャートを残しておきます。IR一発で「半値八掛け二割引」を超える「半値八掛け五割引」に迫り、11710円から2440円へ叩き落されました。
IRが何かは、こちらをご覧ください。
http://kabumatome.doorblog.jp/archives/65935016.html
http://kabumatome.doorblog.jp/archives/65935357.html

日本株式の売買単位が10月1日をもって残された銘柄全てが100株に統一されるとのこと。

売買単位の統一について https://www.jpx.co.jp/news/1021/20180926-01.html

100株移行に伴って株式併合する銘柄は受け渡しが10月1日になる今日(9月26日)から100株単位となる。

日立製作所(6501)、東芝(6502)、富士通(6702)はそれぞれ株式併合したのだけど、

銘柄前日終値併合比率終値
日立製作所(6501) 777.3 5:1 3,893
東芝(6502) 331.0 10:1 3,345
富士通(6702) 826.2 10:1 8,214

併合比率で単位総数を2倍にした日立、と単位総数を変えない東芝・富士通という図があるのだけど、一般に見えるのは株価なわけで、東芝が優良銘柄の株価、富士通が値嵩銘柄の株価に見えたりするわけで、エッ?ソニーやトヨタより富士通のほうが高いの?となったりする。

よくわからないロジックで100株へ移行したみずほFG(8411)は低位株価(三井住友FG(8316)と同じようにすれば10倍の株価)を続けている。株式併合を選ばなかった三菱UFJ(8306)や野村(8604)なども中位株価だけどね。

100株統一って、各社の株主戦略によってずいぶんと株価を上下に動かしてしまったのだなと振り返ってしまった。

ちなみにETFは統一されていないので1/10/100とバラバラです。

追)100株に統一されるのは内国株、外国株は適用外のようで、出来高の大きい9399 ビートHDは1株単位なのだけど東証二部外国株所属。

Chrome様がせっつくので常時SSL化へ移行(途上

  • 投稿日:
  • by
  • カテゴリ:

最近のChromeブラウザは、非httpsなページを表示すると「こんなページを表示してよいの?(要約」といってくる

180905_chrome69_http.gif

URLがhttp://~だと「保護されていない通信」(少し前は「保護されていません」)を表示して、"このサイトは大丈夫!?"と心配してくれるわけなのだけど、Chromeブラウザの次期バージョン70では、さらに「保護されていない通信」となってエスカレーションするらしい。

daytradenet.com/breakscan.com(およびdiamondlifekobe.com他)を収容するサーバーは先月8月18日にサーバー更新を行い某社のVPSへ移行した。先代サーバーは2012年よりオンプレミス環境で運用してきた。昨年に保守期限をむかえサーバー更新をどうするかと検討を始めたところ、サーバー預託先がオンプレミス環境は縮小&現状維持との方針で新しいサーバーハードウェアに更新という話はなくなった。

サーバー更新話はしばらく燻った状態だったが、今年に入って"クレジット代行会社との一部通信はTLS1.0を廃止してTLS1.2に切り替えてね、それと1か月後だからよろしく"、いやそんな話は聞いていないのだが、"メールは半年前に送ったよね"(そんなメールは見ていないし、代行会社のお知らせにも無い)。世間的にTLS1.2へ移行する流れがあったので恐れてはいたのだけどね。切り替え部分は代替する手段があったのでサーバー更新までなんとかなった。
(TLS1.2については、各所でTLS1.0廃止が聞こえてくる。)

TLS1.2対応はサーバー更新せずとも暗号化通信に使用するライブラリ(OpenSSL)をアップデート(当時CentOS 5.7だったので、OpenSSLは0.9.8)すればよいのではとなるのだが、預託先からサーバーを新規インストールより大変。ということでこの機会にオンプレミスからクラウドへ移行することとなり、VPS選定/OS/常時SSLなどを決め、7月中旬より新環境での評価(色々アップデートされているので、旧環境をコピーしてきておしまいというわけにはいかない。PerlとMySQLでそこそこ変更が出た。)。そんなこんなでお盆明けの週末で切り替えになった。

さて常時SSL化(使うのはTLSなのだが慣用的にSSLというらしい)だが、最初はdiamondlifekobe.comから。独立しているから記事のURLをMovableTypeの検索/置換ツールでOK、と思っていたらCoolの記事引用があるのでそのままにしているとIE11で画像消失になるし、アドレスバーも混在コンテンツ扱い表示となるので、障害の少ない掲示板(パスワード入力もある)からhttpsへ移行、その後記事発行時に書き換える方法も分かったので、小さいサイトからhttpsへ移行。

ここまできてようやくdaytradenet.comの番(breakscan.comはUSMWを除き以前より済)。MovableTypeで構築している部分は変更ポイントが決まっているのでよいのだが、古いコンテンツはそのままhttpsでアクセスすると混在コンテンツ表示となる。HTMLのコードを眺めたら古いトラッキングツールが残っていた。今更ちまちま修正するのも面倒なので、表示するときに適宜削除・置換のCGIを作成して表示することにして、現在古いコンテンツを発掘している。その過程で知らない方の黒歴史と思しきものもあったが・・・

ということで、ほぼhttps化が進んだのだが、今月リリースされたChromeブラウザの69がちょっと困ったことをしてくれた(冒頭画像も同じ)。

前バージョンではアドレスバーにhttpsから全て表示していたものが、
180905_chrome68.gif

新バージョンではずいぶんすっきりしている。
180905_chrome69.gif

意訳すると、"鍵マークがあるんだから「https」に決まっているだろ。wwwどこ消えたかって?お約束の慣用的サブドメインなんて表示しなくてもおなじだよね。"と考えているかは知らないが、www無しとするのは考え物だと思う。(鍵マークは最終的に消えるらしい)

アドレスバーからコピーペーストすれば確かにhttpから始まるフルアドレスになるのだけど、アドレスバーを見て写すとか伝えるとかすると、見えないものは伝わらないということになる。Chromeブラウザはアドレスバーで「www.」を省略すると補完してくれたりするのだが、逆に「www.」無しで運用しているサイトではちょっと迷惑。

ということでChromeブラウザの今回の変更はちょっと気掛かり。

ちなみにhttpページでは、IEを除く、FirefoxやEdgeの各ブラウザでも「http://」を省略表示していた。
Firefox 52 esr版を使い続けていたので気が付かなかった。時代はいつのまに・・・

 

# 今回使用したSSL証明書はbreakscan.comを除くと、Let's Encryptを採用。有効期限は3か月だが無償利用でき、自動で更新できる仕組みが用意されている。これが無いと常時SSL化の普及はなかったと思う。ただ先代サーバーのように古いOS環境だと仕組みが利用できず管理に疲弊することになる。
有償のSSL証明書の利点はドメインシールが利用できたり、EV SSL証明書のようにアドレスバーが緑色になって企業名を表示するところだが、普通のブログサイトならLet's Encryptで問題ない。

 10年前に購入したNEC LCD3090WQXiのインバーターが劣化した模様で、スタンバイ状態から復帰して安定するまでの数10分間、バックライトが点滅したり数秒消灯したりし始めました。次に消えたら復活しないかも、トレード中に消えたままだったらどうしよう、ということで少し前から代替となるモニターを探していました。

現状に近いモニターはおよそ次のものになりますが、ドットピッチやドット数を考慮すると悩ましくなります。

  • 27インチ WQHD(2560x1440ドット)、ドットピッチ 0.233 mm
  • 27インチ UHD(3840x2160ドット)、ドットピッチ 0.155 mm
  • 27インチ 1920x1920ドット、ドットピッチ 0.248 mm
  • 29.8インチ WQXGA(2560x1600ドット)、ドットピッチ 0.251 mm ← 現使用中
  • 31.5インチ WQHD(2560x1440ドット)、ドットピッチ 0.272 mm
  • 31.5インチ UHD(3840x2160ドット)、ドットピッチ 0.181 mm
  • 32インチ UHD(3840x2160ドット)、ドットピッチ 0.184 mm
  • 37.5インチ 3840x1600ドット、ドットピッチ 0.229 mm

WQHDだと若干縦幅が不足、UHD(4K)だと150%に拡大しないと見難くなりそうです。それ以前にUHDモニターは接続端子がDP1.2あるいはHDMI2.0でないとならず(リフレッシュが60Hzにならない)、現グラフィックスカードがDVIとHDMI1.4のみなのでそれも買い替えなのかと、どれが評判なのかレビューを見て回っていました。WQXGAの少ない現行製品のひとつであるDell UP3017もDVI無しです。
地方都市ではレビューなどの評判を見て回るくらいしかできないんですね。近隣のヤマダ、ケーズ、コジマではデスクトップ一体型の展示がせいぜいでモニター単独の展示などゲーム用にちょこっとあるだけでした。

 WQXGAは製品数が少ないので中古品も見て回ったところ、Lenovo LT3053p というWQXGAモニターをソフマップの店頭情報に見つけ、電話確認で傷の状況や元箱付きで輸送時の心配が少ないこと、DVI端子があるのでそのまま入れ替え出来ることが決め手で購入に至りました。ソフマップの発送前確認でドット抜けがあるとの連絡がありましたが、受け取り後の確認で特に問題無いレベルでした。このLenovo LT3053pは発売当時Dell U3014と同レンジ帯でしたが国内の興味はUHDに移り始めていた時期で、国内のレビュー記事はほとんどありませんが海外に見つけました
値段ですが製造から5年経過で4万円弱でした。ヤフオクやメルカリでのDell U3014の実績は2万円台のようです。

20180703_LT3053p.jpg

画像がちょっと赤いですが、カラー調整のプリセットで赤みに合わせ、更にWindows10で夜間モードにセットしているからです。この「赤み」で表示する赤の調子はバランスが悪いようで眼にきつく、工場出荷調整済みのsRGBモードに夜間モードで落ち着いています。LCD3090WQXiではハードキャリブレーションでD50(白点を紙の白)に調整していたのですが、LT3053pにはハードキャリブレーション機能が無いので使えそうな組み合わせに落ち着きました。最近のモニターではペーパーモードやブルーライト低減などで色温度を低く合わせられますが、常時夜間モードを使うのも悪くない選択だと思います。

20180629_Nightmode.gif

 今回は同等性能での置き換えであったため表示する文字の大きさに変わりはなかったのですが、今まで23.8インチFHD(1920x1080ドット)だった人が27インチWQHDへ買い替えたりすると15%も文字が小さくなります。ドットピッチが大きく変わる買い替えとなる場合は、ウェブブラウザ上で文字の大きさがどうなるのか事前に確認されるのがよいかと思います。
IE11がカスタムで任意の倍率を設定できますから試してみてはと思います。ドットピッチは各製品の仕様表あるいはドットピッチ計算機で求められます。

 画面右側のモニターはEIZO L887の12年物で、CCFLバックライトの寿命である4万~6万時間の中値に入ってきてます。同等性能なんて絶滅しているので22インチWUXGAでドットピッチ合わせだけでもと思いましたがそれも絶滅寸前なんですね。これも壊れたら悩みそうです。

2019.3 自己解決しました。Outlook データファイルが (97-2002)形式だと文字化けします。

 (いまさらOutlook 2010の話題と突っ込まないでください。なにせ今までOutlook 2003を使い続けていましたので。)

 Outlook 2010(Outlook 2013も同様、おそらくはOutlook 2016も)で、メール形式がプレーンテキストかつエンコーディング形式がUTF--8のメールを受信すると文字化けで表示します。

エンコーディングをUTF-8で、メール形式がHTMLの場合(上段)とテキストの場合(下段) (メール原文はどこかのISPメッセージ)
20180402_mail_char.png

もし文字化けしていたら、大抵UTF-8で送られているので、手間を掛けると読めるようになります。

メッセージを個別に表示(プレビューで操作できない!)、メッセージタブ>アクション>その他のアクション>エンコード>日本語(自動選択)
20140402_chg_auto.png

日本語自動選択なのだから正しい表示に選択してくれると思いきややはり文字化け、同じ手順で最期をUnicode(UTF-8)でようやく読めるようになります。
20140402_chg_utf8.png
文字化けが直ったら保存

 

 それでは、メール形式がHTMLならエンコーディングはUTF-8で大丈夫だよね、と思いきやOutlook 2010はHTML形式のメールをまずはテキストで表示する機能を持ちます。

20180402_auto_text.png

このまま返信メッセージを作ると再びメール形式テキストでエンコーディングがUTF-8のメールが生産されてしまいます。ここでエンコードを日本語(JIS)に変える人は少ないです。

こうやって、なんだか文字化けが発生すると文句を言いながら、その当人が文字化けが起きうるメールを送信するのです。

 では、他のメールソフトはどうかというとOutlook 2003では起きていなかったので、馬渕さんから文字化けといわれても「頑張ってください。一応こちらは日本語JISで送るよう留意します。」でした。

返信時は、日本語(JIS)に変更
20180402_chg_jis.png

 手元にあるメールソフトではThunderbirdは、Text/UTF-8なメールの受信は問題ありません。もっとも送信時のデフォルトエンコードがUTF-8なので、Thunderbirdからのメールは文字化け表示が多いかもしれません。Windows 10のメールアプリはメール形式がHTMLだけのようなので、Outlook 2010で受信するとText/UTF-8なメールが生産される可能性が高くなります。

 こう書き連ねていますが、そもそもHTML形式を推し進めていたのはXP時代のOutlook Expressのデフォルト形式がHTMLだったかと思います。ところがスパムメールが問題になってくるとOutlookは受信時にまずテキストで表示しようとなりました。テキストなら怪しいドメイン名も表示されます(HTMLだと表示とリンクは別物にできます)。
マイクロソフトが文字化け表示の要因を作っているのに、自身で解決しないのはなんていうマッチポンプ。ところがWindows 10のメールアプリだと文字化けせずに表示できるのですから......

 という理由で、デイトレードネット宛てのメールは、テキスト形式(日本語(JIS))で送ってほしいのです。

 以下はOutlook 2010での設定ですが、HTML形式でメールを作成するならエンコードはUTF-8を選んでください。

20140402_set_text.png

20180402_set_jis.png

 ところで、何故「日本語(JIS)」(ISO-2022-JP)なのかといえば、電子メールシステムを日本に持ってきたときの時代背景(1980年代)があったとだけ述べておきます。