サーバーはPHP5で、HTML文字セットはlatin1（iso-8859-1）です。通常の形式のPOST要求では、たとえばemダッシュ（–）などの「特殊」文字に問題はありません。よくわかりませんが、動作します。おそらく、charコード150でブラウザに表現可能な文字が存在するためです（これは、サーバー上のPHPで文字通りのemダッシュを使用して表示されるものですord）。
これで、アプリケーションはajaxを介してある種のプレビューメカニズムも提供します。テキストがサーバーに送信され、プレビュー用の完全なHTMLが返送されます。ただし、ajax経由で送信された場合の通常の文字コード150 emダッシュ文字（GETおよびPOSTでテスト済み）は、さらに次のように変化します%E2%80%93。これはすでにapacheログに表示されています。
http://www.tachyonsoft.com/uc0020.htmなど、私が見つけたさまざまな情報源によると、これはem dashのUTF8バイト表現であり、現在の知識では、JavaScriptがすべてをUnicodeで処理します。
ただし、私のアプリ内では、latin1のすべてが必要です。簡単に言うと、通常のPOSTリクエストでそのemダッシュがcharコード150として与えられたのと同じように、翻訳されたUTF8表現にもそれが必要になります。
utf8_decode(...)サーバー上のPHPを使用して、どちらかまたは両方でデコードしようとすると、この文字を表すiconv('UTF-8', 'iso-8859-1', ...)通常の文字が表示されるため、失敗しました?（そして、iconvも通知をスローします：入力文字列で不正な文字が検出されました） 。
私の目標は自動化された解決策を見つけることですが、この場合、私は超賢くなりたいと思っていますか？
他の人が、事前定義された入力/出力セットに手動で置き換えるだけであることがわかりました。でもそれはいつも私がキャラクターを失うことができるという感覚を私に与えます。
注意深い読者は、私がUnicodeと文字の変換に関することの完全な影響/複雑さを理解するのに遅れていることに気付くでしょう、そして私は間違いなく全体として、そして単に手動のマッピングを理解することを好みます。
シングルバイト文字の必要性に関するDelandsの質問に基づいて更新します。
真実は、私はそれが必要かどうかわかりません。現在、サーバーにデータを渡して戻すには2つの方法があります。
クライアントlatin1->通常のPOSTリクエスト->サーバー上のlatin1、latin1で完全なページを送り返します。文字はOKです。
クライアントlatin1->ajaxリクエスト（取得または投稿）->latin1はutf8に変換されます->utf8をlatin1に変換し直そうとします->latin1HTMLフラグメントをクライアントに送信してインラインで表示します->特殊文字は失敗します
utf8-> latin1からの変換は、上記のutf8_decode / iconで説明したように機能しないため、2番目の方法は失敗します。
私の最終的な目標は、ユーザーが入力したデータのプレビューを表示することです。HTMLレンダリングやその他のデータ評価を行うには、サーバーのラウンドトリップが必要です。
ソリューション
アランの答えは解決策です。これは後ろのようにlatin1扱われwindows-1252、これはWord（少なくともここでは私の2007年）がブラウザとの間で何かをコピーして貼り付けるときに使用するようにも見えます。
さらに興味深いリンク（Alans wikipediaの記事から）は、HTML5構文へのリンクです。
8.2.2.2：ユーザーエージェントは、少なくともUTF-8およびWindows-1252エンコーディングをサポートする必要がありますが、それ以上をサポートする場合もあります。
..。
ユーザーエージェントが次の表の最初の列に示されているエンコーディングを使用してコンテンツをUnicode文字に変換するか、Unicode文字をバイトに変換する場合、代わりに同じ行の2番目の列のセルに示されているエンコーディングを使用する必要があります。 。このエンコーディングエイリアシングのためにバイトまたはバイトシーケンスが異なる方法で処理される場合、互換性のために誤って解釈されたと言われます。
..。
入力エンコーディング：ISO-8859-1- >置換エンコーディング：windows-1252