2016-10-13 7 views
1

これまではmySQLデータにISO-8859-1を使用しましたが、今ではロシア語の注文を開始しているため、文字が表示されます。 (請求書を印刷しようとするとうまくいかない!)ロシア語のUTF8とmySQL - なぜ正しく動作しないのですか?

私はテーブルをUTF8に変換しようとしています。私のテーブル構造は非常に単純です:

DROP TABLE IF EXISTS `glinks_AdminSystemEBay`; 
CREATE TABLE IF NOT EXISTS `glinks_AdminSystemEBay` (
    `ebay_transaction_id` bigint(20) NOT NULL DEFAULT '0', 
    `paypal_trans_id_fk` varchar(200) DEFAULT NULL, 
    `payer_email` varchar(200) DEFAULT NULL, 
    `date_paid` varchar(200) DEFAULT NULL, 
    `shipping_paid` varchar(200) DEFAULT NULL, 
    `address` varchar(200) DEFAULT NULL, 
    `product_id_purchased` int(11) DEFAULT NULL, 
    `payment_amount` float DEFAULT NULL, 
    `total_amount` float DEFAULT NULL, 
    `been_added_to_system` int(11) DEFAULT NULL, 
    `sale_from` varchar(25) DEFAULT NULL, 
    `product_id` bigint(20) DEFAULT NULL, 
    `currency` varchar(10) DEFAULT NULL, 
    `paypal_fee` float DEFAULT NULL, 
    `units_sold` int(11) DEFAULT NULL, 
    `ebay_fees` float DEFAULT NULL, 
    `item_name` longtext, 
    `been_emailed` tinyint(4) NOT NULL DEFAULT '0' 
) ENGINE=MyISAM DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 

enter image description here

それにインポート、私はまだ壊れてしまった文字。私は、この記事に出くわした:

http://www.shawnolson.net/a/946/unicode_data_with_php_5_and_mysql_41.html

私が前に必要とされているSET NAMES 'utf8'を認識していませんでした。これは、今では(クエリの前にそれを実行している)部分

を「節約」という固定、あなたはそれが保存されますどのように見ることができます:

enter image description here

私が今抱えている問題は、バックデータを取得しています正しく!試験として

、私は単純にDBからレコードをつかんで、その後、ダンパーをしています:

print $IN->header; 
use Data::Dumper; 
print Dumper($invoice->{address}); 

私が得るすべては次のとおりです。

$VAR1 = 'Matveenkova ,??????? ??????, ?. 21, ????. 2, ??. 90, ??????, 117208, Russian Federation'; 

のように私は本当に困惑しています私が間違っていること!誰か光を当てることはできますか?

更新:この問題はGoogleのPDF生成ツール(DOMPDF)からのものです。

enter image description here

...しかし、PDFのバージョンが壊れている:それはHTML版も大丈夫です

enter image description here

私は彼らと一緒にバグレポートを提出し、彼らができるかどうかを確認しますヘルプ:)

答えて

2

あなたがDBD::mysqlを使用している場合は、

$dbh->{'mysql_enable_utf8'} = 1; 
を行います0

この属性は、DBD :: mysqlがデータベースに格納されている文字列をutf8とみなすべきかどうかを決定します。この機能のデフォルトはオフです。

このフラグが設定されていると、必要に応じて文字列型(char、varcharなど)から取得したデータにUTF-8フラグがオンになります。これにより、その文字列の文字セマンティクスが可能になります。また、データベース/テーブル/列がUTF8を使用するように構成されていることを確認する必要があります。詳細については、MySQLマニュアルの文字セットサポートに関する章を参照してください。http://dev.mysql.com/doc/refman/5.7/en/charset.html

さらに、このフラグをオンにすると、着信データをUTF-8として処理する必要があります。これは、connect()の呼び出しの一部として使用された場合にのみ有効です。接続後にフラグをオンにする場合は、SET NAMES utf8コマンドを発行して同じ効果を得る必要があります。

+0

お返事ありがとうございます。私は実際にこれを使用しています: '$ CONN {$ conn_key} = DBI-> connect($ dsn、$ self-> {connect} - > {login}、$ self-> {connect} - > {password} RaiseError => $ self - > {connect} - > {RaiseError}、PrintError => $ self - > {connect} - > {PrintError}、AutoCommit => 1、mysql_enable_utf8 => 1}) 'それは動作していないようです。この第三者のものを使用する代わりに、 "適切な" DBIモジュールを提供する価値があるのだろうかと思います。 –

+0

あなたはすでに 'mysql_enable_utf8'を渡しています。それは正しいように見える。 Data :: Dumperが正しく処理していない可能性がありますか?よく分かりません。これを試してください: 'use utf8; Data :: Dumper :: AutoEncodeを使用します。 print eDumper($請求書 - > {住所}); ' –

+1

ありがとうございます。興味深いことに、いくつかのデバッグを追加し、アドレスが正しく設定されているように見えます:アドレス:Matveenkova、Сумской、д。 21、корп。 2、кв。 90、Москва、xxxx、ロシア連邦。問題は、実際のテンプレートパーサーにあるようです。私は掘り続けるでしょう# –

1

いいので、非常に多くのデバッグ(Chankeyに感謝)の後、私は最終的にそれを固定しました。

問題はデータベースではありません。使用していたPDF作成者が問題でした。基本的に、私がやっていた:eBayのAPIから

  • 保存データをDB
  • DB
  • から選択データベースには、(HTMLテンプレートに基づいて)PDF版を作成し、請求書
  • のHTMLテンプレートを作成します。 DOMPDFを使用して

少し見渡すと、私はDOMPDFでロシア語で問題を抱えている人々の他の投稿に出会った。私が見つかりました:

DOMPDF problem with Cyrillic characters

最終的な解決策、私はDOMPDFの最新バージョンを使用していたことを確認しました、その後、HTMLページに、私は確信してI *そしてDejaVu *フォントを使用するなどしなければなりませんでした、これはロシア語をサポートするためです。

html { font-family : DejaVu Sans, Helvetica, sans-serif; overflow: auto; } 

Phew、うれしいthatsソート! :)

関連する問題