-2

名前の表示に関するレポートで問題が発生しています。私のアプリケーションでは、PHP、Perl、および BI Pentaho 用にさまざまなテクノロジを使用しています。

DBとしてMYSQLを使用しており、私のテーブルはCHARSET=utf8.

私のテーブルは、以下のように値が行に格納されていますが、これは間違っています

Row1 = Ãx—350
Row2 = Ñz–401

PHP と Perl は異なる組み込み関数を使用して、DB に保存されている上記の値を変換し、以下のように UI に表示されていますが、これは正しいです

Expected Row1 = Áx—350
Expected Row2 = Ñz–401

pentaho を使用しているレポートに来て、レポートにデータを表示する前に、ETL を使用してデータを変換しています。上記のDBに保存された値を変換するために、以下のようにJavaステップでデータを変換しようとしています

new java.lang.String(new java.lang.String(CODE).getBytes("Windows-1252"), "UTF-8")

しかし、値が正しく変換されていません。上記の 2 つの間違った値のうち、Row2 の値のみが正しく変換されていますが、最初のRow1は以下のように間違って変換されています。

Converted Row1 = �?x—350
Converted Row2 = Ñz–401

たとえば、Row1の値がÁx—350に適切に変換されるように、値を適切に変換する方法を提案してください。

以下のような小さな Java プログラムを作成して、 ×-350文字列を×-350に変換しました。

String input = "Ãx—350";
byte[] b1 = input.getBytes("Windows-1252");
System.out.println("Input Get Bytes = "+b1.toString());

String szUT8 = new String(b1, "UTF-8");
System.out.println("Input Encoded = " + szUT8);

上記のコードからの出力は次のとおりです

Input Get Bytes = [B@157ee3e5
Input Encoded = �?x—350-350—É1

出力が表示された場合、文字列が間違っており、実際に期待される出力はÁx—350です。

エンコーディング/デコーディングスキームを確認するために、オンラインで文字列をテストし、文字列× x-350 でテストしたところ、出力は予想どおり×x-350で、これは正しいものでした。

したがって、これから、適切なエンコード/デコードスキームを使用しているにもかかわらず、Javaコードが適切に変換できない理由、不足しているもの、または私のアプローチが間違っている理由を指摘してください。

4

1 に答える 1

0

ご覧のとおり、dbのCHARSET設定が utf-8 に設定されていても、そこにあるデータが utf-8 (または utf-8 でさえも) で適切にエンコードされているとは限りません。間違ったエンコーディング スキームを使用して一度にデコードされた文字が、次に間違ってエンコードされた文字化けを扱っているようです。これを修正することは、通常、過去のデコード/エンコード エラーを見つけ出し、元に戻すという面倒なプロセスです。

簡単に言うと、mojibake を使用している場合、過去にどのような変換が行われたかを知る (または把握できない) 場合を除き、自動変換を行うことはできません。

変換は、最初にデコードしてからエンコードすることです。Perl で変換するには:

my $string = "some windows-1252 string";

use Encode;
my $raw = decode('windows-1252',$string);
my $encoded = encode('utf-8',$raw);
于 2016-08-03T13:07:55.227 に答える