netowl

> perlって、文字コードとCR　と LF　とか、くだらなすぎて、考えたくもありません。

Perl（Perl 5）の問題ではなくて、
サーバのOSが、UNIX互換(POSIX互換)OSの、GNU/Linux だからですよ。
LF が困るのであれば スターサーバーでは無理です。

文字コードは Shift_JIS でもいまのところは動くでしょうが、
UTF-8 は言語に依存しない世界標準です。PHP や Python に行こうが、どこでも大概は UTF-8 に移行しています。言語の壁で設計を変えなくちゃいけないなんて開発する方ももう勘弁ですので。

いまどきは Windows 10 の時代ですから、Windowsですら UTF-8 の時代です。

古いフィーチャーフォンでなければ、 UTF-8 で支障ないはずです。
それどころかいまや emoji すら標準化された時代です。

Perl にしても Perl 6 まで出ましたけどね。

余談ですが、
昔のフィーチャーフォン（ガラケー）を使い続けるのはもう無理がきていますし、危険でもあります。

TLS(旧SSL)の、バージョンもそうですが、
SHA1証明書の問題で、更新不可能な端末では閲覧不可能なウェブサイトが増えています。たとえばAmazon.co.jpとかも無理です。

Let's Encrypt をみてもわかるように、とりわけ米国の無差別盗聴（PRISM）騒動を期に、どこもかしこも TLS 暗号化通信が一般的になりました。
ということは、昔のフィーチャーフォンでは、普通にウェブを見ることも無理になってきているということです。
もちろん、暗号化されていないウェブサイトを閲覧することのセキュリティ面での懸念も、いまどきインターネットは犯罪でも何でも荒れていますから、大いにあります。

携帯端末メーカー各社とキャリア各社は、サポート期間を区切って新機種を出して商売の種にしています。
サポート期間が切れてOSやブラウザなどが更新されないインターネット端末を使うこと自体も、セキュリティ的にリスクがあります。

回答になっていないのでスルーしていただいて構わないんですが、ネットオウルのサーバーで新規に旧い環境向けの暗号化されたサイトは作れないと思います。

Let's EncryptもSNIですので、TLS1.2とSNIに対応しているブラウザが動作する環境でしかダメということになります。
現在はスターサーバーしか新規に申し込めないのでそれに加えてHTTP/2にも対応している環境ということになります。

ガラケー（？）のみからの閲覧に特化したサイトを作成するのであれば、サイトの暗号化をしないという選択肢もあります。
が、PCやスマートフォンなど他の機器での閲覧を想定している場合にはそうはいかないでしょう。
何らかの入力画面があるサイトが暗号化されていない時に警告を出すブラウザが増えています。
Chromeは暗号化されていないサイト全てに対して「安全ではない」という表示を出すようになりました。

また、最近のChromeにはエンコード機能が入っていません。
（拡張機能を探して入れる人はごく少数でしょう。）
iPhoneの場合には、OSの制約でFirefoxでもエンコード機能が入っていないようです。
文字化けした時に直す手段のないブラウザのことを考えるとshift_jisは使わないほうがいいように思います。



『ネットオウル』【重要】「ファイルマネージャ」「WEBメール」「phpMyAdmin」「お客様が運用中のWebサイト」における TLS1.0/1.1 の無効化について
https://www.netowl.jp/news_detail.php?view_id=2072

『スターサーバー』『ミニバード』『ファイアバード』『クローバー』「オプション独自SSL」における「固定IPアドレスオプション」の新規受付終了のお知らせ
https://www.netowl.jp/news_detail.php?view_id=2020

『スターサーバー』『ミニバード』『ファイアバード』『クローバー』有名ブランドの独自SSLが990円（税抜）から利用可能に！「オプション独自SSL」における「SNI SSL」への対応のお知らせ
https://www.netowl.jp/news_detail.php?view_id=2019

ま、こちらも無視していただいて構わないのですが、

> それに加えてHTTP/2にも対応している環境

HTTP/2 は、最初はHTTP/11で接続してから、サーバー・ブラウザの両方が HTTP/2 に対応しているかどうかをネゴシエイトして、双方が対応しているときだけ、プロトコルを HTTP/2 に切り替える仕組みだったはずなので、HTTP/2対応は必須条件ではなかったはず。

> LF が困るのであれば スターサーバーでは無理です。

自分は使ったことはないですが、
#!/usr/bin/perl --
と余分な--を追加してやれば、改行コードの問題は避けられた気がします。
まあ、FTPでアップロードするときにASCIIモードでするのが、王道なことには変わりません。

> いまどきは Windows 10 の時代ですから、Windowsですら UTF-8 の時代です。

Windows2000の頃から、Windowsは 内部コードはUTF16だったし、Windowsのメモ帳がUTF8で保存するときに、本来不要なBOMを追加しているのは、マイクロソフトの邪悪なエンコーディングと区別するための便宜的なもので、間違った過去をひきずると将来に悪影響を及ぼすことのいい見本です。

ちなみに、Shift_JIS というエンコードは、今でこそJISの一部分ですが、Shift_JISが全盛だったころは、JIS規格ですらなく、単なる独自エンコーディングの一つにすぎなかった。
日本語の第3、第4水準に該当するエンコーディングの SJIS版は、名前こそJIS規格書に現れるものの、まだJIS規格ではないし、将来もJIS規格になることはない。

> 文字コードとCR　と LF　とか、くだらなすぎて、考えたくもありません。

[表示]を[表\示]と書かないと不具合のでるエンコーディングを「考えたくもない」なら理解できますけれど...