UPD： すべてをutf-8で記述するのが正しいことを知っています。 さらに、 私の個人的なプロジェクト、または私が最初から注文するプロジェクトでは、すべてがこのエンコーディングにのみあり、問題はまったく発生しません。 したがって、コメントで10回目には、ユニコードに関するバナリティーを記述する必要はありません。 私はそれを知っています。 不可能な場合に関する質問
UPD2：カルマに感謝、トピックは移動しました
歴史的に、私のフレームワークは異なるエンコーディング（utf-8、windows-1251、koi8-r）のシステムで動作するだけでなく、多くの場合混合状態（データベースはutf-8にデータを送信し、クライアントはwindows-1251で受信する必要があります）ファイルはkoi8-rにあり、クライアントはutf-8で受信し、サイトコンテンツはkoi8-rで提供されますが、RSSはutf-8などで提供されます）。
ある瞬間まで、すべてが完璧でした：
1. PHPコード内のすべてのテキストはutf-8にありますが、システムをロードすると、テキストはシステムの内部エンコードに変換されます。 例：
class ... function title（）{return ec（ "Test"）; }
ここで、ec（）はutf8-> internal_charsetをエンコードする関数です
2.テキストに対するすべての操作（upper / lower / substr /など）は、サーバーの内部エンコードで実行されます。
3.出力の場合、変換はinternal_charset-> output_charsetです。
4.ユーザーファイルからデータをロードするとき、files_charset-> internal_charsetがトランスコードされます
5.データベースからデータをロードするとき、db_charset-> internal_charsetがトランスコードされます。
6. utf-8のすべてのSmartyテンプレートは、ダウンロード時にinternal_charsetにトランスコードされます。
純粋なPHPのテンプレートが必要になるまで、すべてがうまくいきました。 さて、ロジックで、すべてが明確です。 クラスはデータブロックを準備します。 レンダリング時に、システムはそれらをスコープにアンパックし、目的のテンプレートにinclude（）を作成して、出力をインターセプトします。 その後、結果を使用します。
そして、ここに最初のギャグがあります。 簡単にするために、特定の例を考えてみましょう。
システムのエンコーディングであるinternal_encodingをkoi8-rとします。 PHPテンプレート、utf-8のための均一性。 変換を行わないと、混乱がすぐに判明します。utf-8では、koi8-rデータのテキストがPHPテキストに挿入されます。
それから私は明らかなことをしましたが、その時は私にとっては間違った決定をしました。 internal_encodingは常にutf-8であることを自発的に受け入れました。 利点は明らかでした。内部は常にメインテンプレートと同じであるため、ec（ ""）関数は必要ありません。 Smartyでは、{file ...}または{include ...}で、独自のタイプのxfileの代わりに：//ファイル[とりわけローダーがトランスコーディングを行ったローダー]、通常のファイルを使用でき、PHPテンプレートはコメントなしで挿入されます。 そして、一般的に、何らかの形で統一された世界に住んでいるのは素晴らしいことです:)
松葉杖がどこに来たかは明らかですか？ internal_charset！= PHPシステムロケール。 strtolower / strtoupper / substrは機能しません...
そして今、私は岐路に立っています。 そして、これをどのように掻き集めることができるかについてアドバイスを求めます:)
私が正面から見る最初のオプション。 今、私は彼らのために状況を台無しにしています。 システムコーディングの概念を紹介します。 つまり システムロケール。 すべてのstrtolower（）をu_lower（）に変更します。ここで、フレームワークの内部エンコードからシステム1にiconvを作成し、次にstrtolowerを使用して内部に戻します。 長所 -フレームワークの統一されたエンコーディングが残っています。 ec（）はまだ必要ありません。 バグのあるmb_stringなどがあるシステムでは、さらに微調整が可能です。 短所 -標準の代わりに関数を使用します。 追加のプロセッサ負荷。 小さいですが、ループのどこか深いところにある場合は？
2番目のオプション。 internal_charsetは常にシステムロケールに等しく、一般的な場合はutf-8と等しくありません。 PHPテンプレートは、システム上の他のすべてのものと同様に、utf-8にあります。 PHPテンプレートをロードするとき、それに供給されるデータは内部からutf-8に事前にエンコードされます。 キャプチャされた出力は、utf-8から内部にトランスコードされます。 長所 -システムはオーバーヘッドなしで標準のPHP関数を使用できます。 短所 -テンプレートから直接提供されていない他のデータを参照する場合、テンプレートで再コーディングが必要です（たとえば、$ titleを再コーディングできますが、$アイテム[0]-> title（）は既にシステムエンコーディングになっています）。 システムエンコーディングからutf-8への変換関数を使用する必要があります。 つまり メインデータをそのまま表示できる場合：
こんにちは、<？= $ Title？>、内部データは次のように出力する必要があります
購入<？Dc（$アイテム->タイトル（））？>ここで、dc（）は内部変換-> utf-8を実行します。 また、これは、特にループ内にある場合には、一種のオーバーヘッドでもあります。
私の頭には他のオプションがありましたが、今ではそれが飛び出しましたが、それは絶対に狂っています:)
私は2番目に傾いています。 それでも、UnicodeはUnicodeですが、システム内のシステムエンコーディングに住んでいる方が良いでしょう。 システムでutf8を有効にできます-すばらしい。 いいえ-選択する必要はありません...さらに、2番目のオプションを実装するときは、完成したコードの最小限を書き換える必要があります。
外から見た目を新しくすれば、もっとエレガントなソリューションが得られるでしょうか？