Q&A
破損とはどういう状態でしょう？当該データがまったくデータが受け取れない(NULL?)、当該データだけ全体的に文字化けしている、一定の長さで切られてしまう
MYSQL← PHP ←(PDO ODBC)← unixODBC ←dblib← FreeTDS ← MSSQL
という手順で外部のMSSQLサーバから手元のAWSサーバ(EC2 amazon linux・RDS）へデータの変換を行いたいのですが、だいたいのデータは取得ができているものの
一部の長い日本語文字列がPHPのスクリプトで取得した時点で
破損してしまう状況に悩んでいます。
tsqlにてFreeTDSを直接たたいた時点では正常な取得が行われているのですが
isqlにてunixODBCを叩いたところ、このタイミングで破損が発生している模様で
おそらく先方のsjisデータをUTF8変換する際に参照先のカラム型とバイト数が違うので
アウトになってしまっているのかと思い、接続の方法を変更すべく
pdo_dblibへの変更を試みたのですが
checking for re2c... no
configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers.
checking for gawk... gawk
checking for PDO_DBLIB support via FreeTDS... yes, shared
configure: error: Cannot find FreeTDS in known installation directories
と必要なライブラリが見つからずこちらも上手くいかずとまってしまっています。
今後のメンテナンスの都合上、PHPでの取得という条件を排除できない場合
EC2上で上記のような問題が解決できるアイデアをお持ちの方はいらっしゃいませんでしょうか。
ご質問ありがとうございます。PHPに到達した時点で破損対象のデータはNULL扱となってしまっているのですが、unixODBCの時点では本来正しい文字列が「リーダー(10人以下)」といったものが「リーダー(10?」とコンソール上では表示されている状態となっておりますため、一定の長さで切られているものと推察をしております。
回答2件
0
もし、SQLServer側を触れるなら、SQLServer側にCSVを出力するストアドプロシージャを仕込む。
FreeTDSを通じて、ストアドプロシージャを叩く。
出来上がったCSVを吸い上げる。
という方法でいかがでしょうか？
投稿2016/10/06 07:13
総合スコア295
0
文字コードの変換をPHPで行うのであればなんとでもなりそうですが
ご自身でコントロールできる範囲で解決はできないような気がします
受け取った瞬間に壊れてるんですよね？（ちがったらごめんなさい）
先方で文字コード変換しないという仕様は実現可能なのでしょうか？
投稿2016/09/30 04:16
編集2016/09/30 04:31総合スコア114829
あなたの回答
tips
プレビュー
