NLS_CHARACTERSET = US7ASCIIのOracleデータベースがあります。 フィールドを含むテーブルに挿入して、そのカラムにCHR(176)という値を入れることができました（degrees symbol）。US7ASCIIの文字セットがある場合、なぜ非ASCII文字を格納するのですか？
その文字はUS7ASCIIでサポートされていないようです。
なぜデータベースでその値がその列に格納されるのですか？
データベースでは、Oracleが文字セット変換を処理するため、その値を格納できます。
詳細情報はここで見つけることができます：Special Characters in Oracle
それは正しいのですが、彼は '°'ではなく '？'になってはいけませんか？ –
オペレーティングシステムの文字セットによってはそれは変わりませんか？私は、表示されるものがOSの言語/文字セットに依存するという信念の下にいました。 – solllodolllo
接続エンコードをどこにも設定しないと、おそらくこれは最後のフォールバックレイヤーです（分かりません）。しかしキャラクターをサーバー上に物理的に保管することができない場合、オラクルが最初に存在するキャラクターを特定する方法はありません。 –
次の条件が両方とも真であるので、それは動作します：
US7ASCIIに設定されている値が可能。このような場合、各データは変換せずに1つずつ書き込まれ/読み出されます。つまり、送信するバイトは正確にデータベースに書き込まれます。クライアント側でNLS_LANGを設定していない可能性がありますが、デフォルトではAMERICAN_AMERICA.US7ASCIIに設定されています。
US7ASCIIは、7ビットエンコーディングです。私は純粋なASCIIアプリケーション（見つけるのはかなり難しいかもしれない）は、8ビットアーキテクチャに格納されている第8ビットを無視すると仮定します。他の文字セット、例えば。 AL32UTF8各バイト値を許可しません。この場合、そのような文字はプレースホルダーに置き換えられます。 ¿または?。
クライアントの文字セットをUS7ASCIIに設定すると、正しくない可能性があります。アプリケーションで使用されている文字セットに正しく設定すると、°が置き換えられます。
コマンドchcpでSQL * Plusのコンソール・コード・ページをチェックする場合は、resp。 locale charmap。 sqlplusを起動する前に、それに応じて環境変数NLS_LANGを設定してください。
'US7ASCII'は['DEGREE SIGN'（U + 00B0）]をサポートしていない7ビットエンコーディングであるため、何か別のものがあるはずです（http://www.fileformat.info/info/unicode /char/00b0/index.htm）ので、リターン時に疑問符（？）を得るべきでしょうか（あるいは別の代替文字かもしれません）。グローバリゼーション・サポート・ガイドについては、Googleを使用することができます。奇妙な。 –
[単一言語シナリオでのキャラクタ・セット変換]（https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch2charset.htm#sthref165）：「ターゲット・キャラクタ・セットにたとえば、サーバーがUS7ASCIIを使用し、ドイツ語クライアントがWE8ISO8859P1を使用する場合、ドイツ語の文字「ß」は「？」に置き換えられ、「ä」は「a」に置き換えられます" –
この回答を参照してください：https://stackoverflow.com/questions/36710360/difference-between-nls-nchar-characterset-abd-nls-characterset-for-oracle/36712457#36712457 –