文字列をbase64、ASCII、hex（両方の方法）などのさまざまなエンコーディングに変換するperlスクリプトがあります。今、私はそれのためにajaxフロントエンドを書いています、そして私の質問は; 送信された文字列のエンコーディングの検出を自動化したい場合は、サーバーに送信する前にjavascriptで送信された文字列に対して正規表現検索を実行する方が効率的ですか、それともperlスクリプトが把握できるようにする方が高速です。どんな種類の文字列を出しますか？
明確にするために、私はこれら2つのどちらが優れているかを尋ねています。
また
このタイプの処理を実行する必要がある特定の経験則はありますか？また、より良い（より速い）実装は何だと思いますか？
サーバー上のデータを検証する必要があります。限目。それ以外の場合は、2ビットの「ハッカー」がbase64文字列と、JavaScriptが16進数であると見なすタグを渡すとすぐに、未知の海域に出航します。
これを考えると、クライアント側でもエンコーディングを検出するかどうかはあなた次第です。これには、データが無効な方法でエンコードされている場合はサーバーにデータをまったく送信しない、または検出されたエンコードをユーザーに通知して、あいまいな場合（16進数など）の場合は修正できるため、いくつかの潜在的な利点があります。数字はbase64文字セットのサブセットであるため、任意の16進文字列がbase64になる可能性があります）。エンコーディングがクライアントによってサーバーに渡された場合でも、サーバーは受信したエンコーディング指定子の健全性をチェックし、対応するデータに不適切な場合はそれを無視する（または要求を完全に拒否する）準備をする必要があることを覚えておいてください。
これは規模によって異なります。
これを実行するクライアント要求が多数ある場合は、クライアント側で実行する方が間違いなく「高速」です（たとえば、Ajax呼び出しの前のJSで）。サーバー側に配置すると、サーバーがそれらすべての要求を処理するためです。サーバーのCPUリソースをめぐって競合しますが、クライアント側では、クライアントごとに1つの検出のみを実行します。
同時リクエストが非常に少ないと予想される場合、Perlの正規表現の実装はJavaScriptよりも優れている/高速である可能性が高く（ただし、これをバックアップするための統計はありません）、おそらくサーバーの方が優れているため、Perlでの実行はおそらくわずかに高速ですCPU。
しかし、処理全体がどちらの側でもそれほど長くはかからないことを考えると、サーバー側のマージンがそれほど大きくなるとは思わないので、それ以降はクライアント側のチェックを行うことをお勧めします（最初の段落のとおり）スケーリングが向上します。
2つのパフォーマンスの違いが非常に重要な場合は、実際に両方を実装し、予測される平均と予測される最大のクライアント負荷の両方でベンチマークを実行する必要があります。