0

実際にリソースをUTF-8形式でDBに保存しました。しかし、今、それらすべてをUTF-16に変換したい場合。ドイツ語は1/4のようないくつかの文字を持っているので。今、私はそれらを避けたいです。ステートメントに従ってみましたが、結果文字列にいくつかのボックスがあります。

> select convert('Inhalt hinzufügen','AL16UTF16LE','AL32UTF8') from dual
  result : it is not allowing me to copy paste it :(. But result is coming properly except boxes in middle of each character

別のアプローチはありますか？

SELECT *
  FROM v$nls_parameters
 WHERE parameter LIKE '%CHARACTERSET';

データベースの文字セットがWE8MSWIN1252であり、国別の文字セットがAL32UTF16であることを示します。

この関数を使用しDUMPて、テーブルに実際に格納されているデータを表示すると、次のようになります。

SELECT dump( your_column, 1016 ), your_column
  FROM your_table
 WHERE some_key_column = <<value that gives you the row you're interested in>>

Typ = 1 Len = 54 CharacterSet = WE8MSWIN1252：4d、c3、b6,63,68,74,65,6e、20,53,69,65,20,64,69,65,73,65,20,5a、 65,69,6c、65,20,77,69‌、72,6b、6c、69,63,68,20,65,6e、64,67、c3、bc、6c、74,69,67,20 、6c、c3、b6,73,63,68,65,6e、3f、MöchtenSiediese Zeile wirklichendgültiglöschen？

4

1 に答える 1

1

データベースの文字セットは WE8MSWIN1252 であるため、データが実際に UTF-8 として保存されていないことを願っています。実際のデータが CHAR、VARCHAR2、または CLOB 列に格納されている場合、データは Windows-1252 文字セットを使用して格納されているか、データが正しく格納されていません。実際に UTF-8 データをデータベースに保存するように NLS 環境を正しく構成していない可能性がありますが、ここではそうではないことを願っています。

関数の出力に基づいてDUMP、データの 3 番目の位置に格納されると予想される文字は何ですか? 0xB6 は、データベースに実際に格納されているデータで、Windows-1252 文字セットの段落記号 ¶ にマップされます。これが予期した文字でないと仮定すると、データベースに格納されているデータが破損しているように見えます。

データはどの言語で書かれていますか? 保存するすべての文字がWindows-1252 文字セットに含まれていますか?

データの保存方法を変更しようとしていますか? または、別の文字セットでデータを取得しようとしていますか?

データベース文字セットが AL32UTF8、各国語文字セットが AL32UTF16 で、UTF-16 を使用してデータベースにデータを格納する場合、データを NVARCHAR2 または NCLOB 列に移動する必要があります。

データをデータベースに UTF-8 形式で保存しようとしているが、UTF-16 でクライアントに送信しようとしている場合は、クライアントの NLS 設定を構成することで自動的に実行できます。正確な方法は、クライアントがデータベースにアクセスする方法 (JDBC、ODBC など) によって異なります。

于 2011-08-17T14:08:51.940 に答える