WCFおよびカスタムテキストエンコーディング - 乱雑なビジネス
-
27-10-2019 - |
質問
ここに本当に奇妙なWCFの問題があります...
くだらないサードパーティのWebサービスに接続しています。それを手に入れるのは悪夢でした。彼らの人たちは「ISO-8859-1」をテキストエンコードとして使用することを決めたので、カスタムWCFバインディングを作成する必要がありました(Web上のすべての人と同じようにUTF-8の代わりに)、そして他の設定も乱雑でした - そしてもちろんどこにも文書化されていません...
それはしばらくの間大丈夫に動作していますが、突然、私たちのデータのいくつかが戻ってきました。私たちは場所の名前を取り戻すことを期待しており、スイスにいることで、それらのいくつかはドイツのウムラウトを持っています。しかし、過去2、3か月間、私たちは突然戻ってきます
Hünibach
適切なものではなく
Hünibach
したがって、ü(u umlaut)が壊れています。
問題ありません。私は彼らが最終的にUTF-8に切り替えたと思いました、そして、私はカスタムバインディングをISO-8859-1ではなくテキストエンコーダーとしてUTF-8を使用するように変更しました - しかし、運はありません - いいえ私は取得しています:
例外:System.ServicEmodel.Security.MessagesEcurityException
HTTP要求は、クライアント認証スキーム「Basic」で禁止されていました。
何?????サービスは、使用するユーザー名/パスワードによって保護されています ClientCredentials
WCFの。エンコードをエンコードするテキストを変更すると、資格情報が台無しになります!?!?!変.....
OK-ISO-8859-1に戻り、応答ペイロードをUTF-8と解釈しようとしました - 再び運はありません:-( UTF-16、UTF-32、UTF-7の均一、Unicode、BigEndianCode-All無駄に。
それで、私はどのようにして私の適切なウムラウトを取り戻し、それでもその血まみれのサービスを呼ぶことができます...ソープイではうまく機能します、ところで.....
何か案は??私はあなたが私を投げるかもしれないストローを必死に把握しています!!
解決
戻っているデータを検査してみて、それを表すために使用している数値コードを確認してください。 Umlautは、他のキャラクターとコードを共有する8859-1のキャラクターの1つです。
2番目のパラを参照してください - http://en.wikipedia.org/wiki/%C3%9c#typography
他のヒント
実際、私はついにトラブルが何であるかを理解しました。
何らかの理由で、サンプルを変更します CustomTextEncoder
(WCF&WFサンプルでMicrosoftが提供)ISO-8859-1の代わりにUTF-8を使用する うまくいきません.
一方、カスタムバインディングからカスタムテキストエンコーダーをリッピングし、標準を使用するだけです TextMessageEncoder
WCFがGet Go(デフォルトでUTF-8を使用)から提供する うまくいきました.
なぜ私に聞かないでください....それは私が見つけた事実だけです.....