< | >

(htaccess 作成) リダイレクトのために
  • (2021-03-22 12:25:44)

コピペだけでダメなとき


ドメインの引越してリダイレクトを設定する際、「.htaccess」ファイルにお世話になる。

リダイレクトの記述方法はサンプルがネット内に多数でているので、コピペでさくっと作成できる。しかし、ちょっと複雑な条件をつけるとなると、記述の仕方を勉強することになる。

今日はそれではまったので記録。


どこにhtaccessの公式マニュアルはあるのか?


第一に「htaccessって何だ?」という疑問から。

ボクはリダイレクト用の標準化されたルールと思っていた。RFCで決められたルールのような。調べてみると、Apache Webサーバの設定ファイルだった。

ということはApache開発者によって決められ記述方法があるのだろう。

htaccessのサンプルを解説してくれているページは多いが、ほとんどキモの部分の抽出であり、包括的な解説ページが探し出せなかった。

Apacheの巨大なドキュメンテーションの中にあると推測されるが、そういう複雑・長文なドキュメントとなると、ボクのような素人が見ても時間の無駄かもしれない。


断片的に集めた情報


下記はhtaccessについいて解説してくれている親切な人々のサイトを回って収集してきたもの:

####################################
# htaccess のファイル形式 →
# ファイル名 → 「.htaccess」にする
# 文字コード → 「UTF-8」(BOMなし)
# 改行コード → 「LF」または「CR+LF」でも動作する
# 日本語を記述するなら文字コードはUTF-8で
# 改行コードもLinuxなのでLFが良い。CRLFでも動く
# コメント → #から行末まで
# パーミッション → (604)
# .htaccessの最後の行は改行を入れる
# [L] URLの書き換え処理を終了し以降のRewriteRuleを適用しない

# 条件式の形状は「RewriteCond A B C」。Cはパターン/オプション
# 「A = B」かつ C条件で trueを返す場合、条件に一致
# Cを指定しない場合は「A = B」の場合trueを返す
#

# RewriteEngine On → リダイレクト機能ON(有効範囲はたぶん[L]まで)
# RewriteCond → 条件(condition)
# RewriteRule → 書換ルール。書換は部分は「https://」から始める
# %{HTTP_HOST} → ドメイン部分。お尻の「/」部分は含まない
# %{REQUEST_URI}→ リクエストされたurlのドメイン以降。「/」含む
# .* → 0文字以上の任意の文字列
# ^(.*)$ → 最初から最後までの文字列。RewriteRule内では%{REQUEST_URI}
# %1 → 後方参照、RewriteCond内で、1番目の括弧内文字列、2番目文字列なら「%2」
# $1 → 後方参照、RewriteRule内で、1番目の括弧内文字列、2番目文字列なら「$2」

# [NC] → 大文字と小文字を区別しない
# !^www\. → 「!」否定、「^」先頭、「\」エスケープ、「$」末尾
# テスト環境でOKでも環境違うとNGという場合がある
# 記述ミスがあると設置したディレクトリ以下が全て500エラーになる
#
< | >

知らない連中が他人の名刺をクラウドに? 名刺は完全廃止にせねば
  • (2021-03-22 09:16:44)

知らない人の勤務先変更のおしらせ


「株式会社○○の△△さんの勤務先が変更されました」

というメールが来た。

「誰の話?」が第一印象。

まったく知らない人の勤務先変更のおしらせである、不要である。


「名刺アプリEight」とは?


思わせぶりな釣り型スパムかと思えば、宛先として私のフルネームが書かれていた。

ということは私個人を特定して、送ってきたメールということになる。

発信元は「名刺アプリ Eight 」。

「名刺アプリEight」?


Sansanか・・


調べると、クラウド名刺管理サービスの Sansan株式会社のサービスらしい。

テレビCMを派手に流していたあの会社か。

CMを見て、危ないな、と感じたものである。

危惧した通り、自分も巻き込まれていたとは・・


他人の名刺登録は止めようよ


以前どこかで名刺交換した人が、勝手に私の情報を Sansan にアップロードしたということらしい。

もしかしたら、名刺交換さえしてもらず、展示会などの入場登録のために差し出した名刺かもしれない。

いや、待てよ、道端に落ちていた名刺が拾われ、Sansan のクラウドに登録されたのかもしれない。

はなはだ迷惑な話である。


名刺も個人情報


仮にどこかで、実際に名刺交換したとしても、もう記憶がないくらい縁のない関係、赤の他人である。

そんな人が他人の個人情報を得体の知れない第三者サービスに登録するというのもどうか。

迷惑である。


名刺を廃棄にすることにした


過去5年くらい、私は名刺を持ち歩かないし、人にあまり渡さないようにしていたが、今後は完全に渡さない方がよいと感じた。

というか名刺はもはや廃棄処分である。

軽くネット公開する人々の存在と、それを利用して商売する人々の出現は想定されていた、もっと早く決めておけばよかった。


< | >

秀丸、デフォルト文字コードをutf-8に?
  • (2021-03-15 06:52:07)

utf-8変換してもShift_JISに戻るトラブル


Shift_JISのファイルをutf-8に変更したのに、再度秀丸で開くとShift_JISに戻っているトラブルに遭遇した。

「あれ、おかしいな、さっきutfにしたのになぜ?」というhtmlファイルにがあって面食らった。

調べると秀丸に限らず、多くのテキストエディターが半角英数字だけのファイルは文字コードの自動判別ができない事実をさきほど知ったのだ。

今日のブログのテーマはこの問題から始まった。


技術者はなぜ「メモ帳」や「vi」を使うのか?


長年、テキストエディターとして「秀丸」にお世話になっている。

Windowsに付属する「メモ帳」だと発狂しそうなくらい不便だと感じる。

以前働いていた会社で、そこの技術者に「なぜ『メモ帳』を使うのか?」と聞いたら「Windows標準だから」と言われた。標準だから、どんな環境であっても「メモ帳」なら付いている点がメリットらしい。

様々な顧客の様々な環境のシステムを開発していた人の現実的な事情だった。ひどく納得した。

Unix系の技術者なら「vi」か。ボクにはとうていマネできないが、あんな不便なものを、取り憑かれたようなスピードでキーボードをたたく姿には独特な空気が漂う。

「vi」は「メモ帳」と違って慣れると速いらしい。まあ、彼らはキーボードに対して高度な適応力があるようで、どんなエディターであっても爆速でたたけるようだ。


Shift_JIS・utf-8混在状態


秀丸に長年お世話になっている私だが、面倒くさいなと感じることが文字コード。どうしてここまで、日本語の文字コードはぐちゃぐちゃ? と今さら思っても、どうにもこうにも。

ボクは開発者でもコーダーでもないが、たまにhtmlを書く。現在のネット内ではutf-8がデフォルトであるが、Windowsでは長い間、Shift_JIS だった。

ボクが作成したファイルはShift_JIS の山であるが、ネットでは utf-8 であることが求められることも多い。それで、ボクのPC内は Shift_JIS と utf-8 ファイルの混在状態となっている。

秀丸のデフォルトコードはShift_JISである。


UTF-8が標準になろうとしている


Windows10の「May 2019 Update」以降、「メモ帳」のデフォルトコードはutf-8になったそうである。

これはPC作業を行う人々にとって、象徴的な事件かもしれない。今後、世界はutf-8で一本化されていくのだろう。

で、ボクの秀丸もデフォルトコードをutf-8に変更するかどうか、今日考えるのがこのブログ。

今後作成する新規作成ファイルは問題なかろう。が、 Shift_JIS・utf-8の混在している現在のファイル群への影響は?・・あまりクリアにイメージできない。別にかまわないか。

秀丸はどちらのコードであっても自動判別でファイルを開いてくれる。ただし、半角英数字の文字しかないファイルは判別できず、自動的にデフォルト設定のコードになる。


デフォルトutf-8でどんな問題?


思いつかない。もしかしたら秀丸マクロが動作しなくなるとか?

秀丸以外ではutf-8に対応していない古いソフトやアプリはそう多くないと思うが、今ひとつイメージできない。

まあ、とりあえず秀丸の文字コードをutf-8にしてみて、実際の影響を見てみるか?


< | >

Fire Stick、すごいネット終端装置
  • (2021-03-05 06:51:40)

Amazon Fire TV Stick


以前からヒットしていた商品だが、昨年からのコロナ巣ごもり需要で、さらに売れているとか。

理由は覚えていないが、数年前ボクも購入した。

Amazon Prime Videoを見たかったのかな?

(結局、Amazon Video はボクには不要だったけど)


テレビはもはやテレビ局番組の端末ではない


今はYoutubeをテレビで見るためにときどき利用している。

テレビ局の番組は退屈・不自然で、テレビ自体をほとんど見ない現状、Youtubeは我が家のよいエンタメになっている。


スマホ画面をwi-fiでテレビ表示?


で、最近スマホの画面をテレビに投影させることができる「ミラーリング」という技術があることを知って試したら、即できた。

感動したね。

技術じゃなくて、発想に。


先見の明


久々、Fire Stickの設定画面など見て、Fire Stickを開発しようと考えた人に、先見の明があったなと感じた。

Amazonの中の人のアイデアか、それともAmazonに売り込みに行ったのか、事情は知らんが。


既存のテレビを使うという発想


既存のテレビのHDMIポートに直接、Androidデバイスをつないで、インターネットの終端装置をテレビにしちゃうという発想。


音声操作


ボクは自分の音声をAmazonに渡すことがイヤなので使わないけど、音声操作という点も新しかったし、音声操作は今後の操作方法の主流になる。


後からなら誰でも思いつく


Fire Stickという現物を見た後では誰でも思いつくが、最初に思いついて速攻で開発した人の業績だろう。

スマホが、デジタルデバイスの代表的インターフェースになって10年、その表示部分は小さい。

なので、自宅でくつろいでいるときはでっかいテレビで見たいと思うこともある。

そんなわずかなニッチな需要は確かにある。


ニッチでも世界規模ならビッグ


ニッチであっても世界市場で売れるとなれば、ビッグビジネスである。

Fire Stickはスマホが制覇した世界市場でも、ニッチな分野で、ビジネスチャンスが残されていることを示唆する、案外、すごいデバイスだった。

同時に、衛星放送も短命だったな、という気持ちにさせられる。


< | >

ルール違反メアドに対するドコモの立派な説明
  • (2021-03-04 10:31:59)
お客さんより電話で問い合わせがあった。

数回メールでおしらせしている内容に関してだったので、メール届いてませんか?と聞いてみると届いていないとのこと。

エラーもないし、原因は不明。

その人のメアドを眺めると、ドコモで、変なアドレスだった

「○○○.@docomo.ne.jp」

これが原因かどうか、わからないけど、「@」の直前に「ドット」はよくないんじゃないかな、と思った。

「@直前のドットや連続ドットは禁止」はかなり前から言われていた。

ドコモが iモードをリリースした20年くらい前、その直後から、RFC違反を指摘する人がいたよううに記憶している。

ドコモさんも無責任だなとその時は思っただけで終わった。

ボクはRFCを読んだことがないので、偉そうなことは言えない。

しかし、メアドをユーザーに対して発行するサービスをしている企業なら、「インターネットの規則であるRFC」は読んで、それに準拠したメールアドレスを発行すべきではなかろうか。

今回、お客さんからの問合せで、「ドコモはまだRFC違反を訂正してないの?」と呆れて、どうなっているか、ドコモのサイトを見に行ったら、こうあった:

2009年以前よりドコモのメールサービス(@docomo.ne.jp)をご利用いただいているお客さまのなかにはRFC違反アドレスを利用している可能性があります

この文面から判断するに、2010年以降、ドコモはRFC違反を認め、訂正したようだ。

逆に言えば、10年も放置してたのか、と再度呆れる。

そして、それまでの顧客で、RFC違反メアド保持者に変更を呼びかけている。

しかしね、それまで自分たちのミスかメンツか、わからないが、放置してきた結果、RFC違反状態になっている顧客に対して、

「お客さまのなかにはRFC違反アドレスの可能性があります」と客に責任があるような言い方が・・・さすが一流大企業様である。



search
layout
admin

[▲page top]