ADOで取得した結果が文字化けする (ID:122194)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 >>既にデータが破損していますので、完全には復元できません。 > 上記の記述によれば、データ破損しているということなのでしょうか？ 今回のデータについては、化けてはいますが、破損はしていません。 ですが、元データによっては、「破損する可能性がある」という事です。 私は、Sybaseの事は全くわかりませんので、具体的な対処方法は わかりませんが……ご自身で環境設定を行う自信が無いのであれば、 Sybaseに詳しい方に、設定を依頼した方が良いかもしれませんよ。 === 以下、蛇足情報 === VB6の使うUnicodeは、UCS-2相当のデータなので、本来は、 [UTF-8のバイナリ]……DB ↓ (DB/ADOの文字コード変換処理)……★UTF-8 → UCS-2 変換 ↓ [UCS-2のバイナリ]……VB(文字列型の内部形式) という流れで変換が行われています。 (さらにこの後、UCS-2→Shift_JIS変換がありますが) そしてこの場合、UTF-8の「東京」という文字列は、バイナリとしては DB: E6 9D B1 E4 BA AC VB: 71 67 AC 4E OS: 93 8C 8B 9E のように変換される事が望まれます。 ところが今回は、90,139,113,255,160,131,108,255、すなわち、 16進数で 5A,8B,71,FF,A0,83,6C,FF というデータとして渡っています。 # これを、UCS-2として文字列化した物が「譚ア莠ャ」(ア,ャは、半角カナ) です。 この現在の状況を見ると、上記 ★ の部分が、Shift_JIS → UCS-2 変換に なってしまっているようです。すなわち、UTF-8のバイナリが、Shift_JIS と みなされて変換されているというわけです。 無変換ならば、まだ手の打ちようはあったのですが、間違った変換が 行われている以上、データが破損する可能性があるわけです。 そもそも、Shift_JISにはバイナリとして使える範囲が決まっています。 具体的には、 1バイト文字／制御コード: 00-1F, 20-7E, A1-DF, 7E 2バイト文字の1バイト目: 81-9F, E0-EF 2バイト文字の2バイト目: 40-7E, 80-FC という範囲として定義されます。 今回使った『(UTF-8)東京』のバイナリは、E6 9D B1 E4 BA AC でしたが、 この場合、Shift_JIS の定義では、幸いにも [E6 9D] [B1] [E4 BA] [AC] という並びで処理され、データの欠損はありませんでした。 具体的には、Chr(&HE69D) & Chr(&HB1) & Chr(&HE4BA) & Chr(&HAC) の文字列 すなわち『(Shift_JIS)譚ア莠ャ』のデータとして処理され、さらにそれが Unicode変換され、『(UCS-2)譚ア莠ャ』の5A,8B,71,FF,A0,83,6C,FF として VB に渡されているのが、現在の状況です。 しかし、これが「東京」以外の文字だったらどうなるでしょう。 たとえば、DB側が『(UTF-8)β版』という文字列だったとしましょう。 この場合のバイナリは、CE B2 E7 89 88 の 「5バイト」で表されます。 そしてこれを Shift_JIS と誤認して変換した場合、 [CE] [B2] [E7 89] [破損] となってしまいます。 最後の 88 は、全角文字の2バイト目となるべきデータなので、 S = Chr(&HCE) & Chr(&HB2) & Chr(&HE789) & Chr(&H88) の変換で、「最後の文字が破損」してしまい、正しく文字列化できません。 すなわち、『(Shift_JIS)ホイ迚?』(ホ,イは半角カナ、?は不定値)となります。 しかも今回は、さらに Unicode 変換までされてから VB に渡るのですから、 最終的には『(UCS-2)ホイ迚?』の 8E FF 72 FF DA 8F ?? ?? となります。 すでに破損してしまった ?? ?? の部分は、もはや復元不可能です。 もし、残っている 8E FF 72 FF DA 8F の部分だけ UTF-8 に戻したとしても、 最終的に生き残るのは、CE B2 E7 89 という「4 バイト」のバイナリだけですし、 その4バイトを UTF-8 の文字列に戻そうとしても、完全に戻るのは 最初の2バイト『β』だけです。これではデータベースとしては致命的です。 もし、欠損の可能性が無い範囲の文字しか使われていなかったとしても、 データの格納時には、この逆の変換作業を行わなければなりませんよね。 この時も、同様の理由でデータの破損が起こりえますので、利用できる文字は さらに限定されてしまいます。なので、化けた後に対処するのは無意味でしょうね。