３日間ハマっていました。

いやぁ～、久しぶりにハマりました。使っているデータベースは MySQL なんですが

スキーマを変更（alter）しようかとも思ったんですけど、動く状態のデータベースを壊すとまずいので、
utf8 で新しいスキーマを作り、バックアップを流し込みました。

・キーにしている文字列項目が長すぎる・・・にひっかりました。utf8 にすると１文字あたりのバイト数が増えるので・・・
・次に、キー全体の長さが長すぎる
文字列項目の長さを調節して何とかしました。
とりあえず「文字化け御免」という事で「Tchaikovsky. Sinfonía nº 5 en Mi m, Op. 64」を入れてみました
ちゃんとＤＢに書き込めたし表示もＯＫ。

テストに必要な最小限の「補助文字対策」をやって補助文字を入れてみると、ＤＢへの書込み時に「不正な文字」となってしまいました。
調べてみると「MySQL の utf8 は補助文字はサポートしない。補助文字を使うならば utf8mb4 を使え」だと。

で、ＤＢを作りなおすと、また「キーが長すぎる」
MySQL の utf8 は１文字あたり最大３バイト、utf8mb4 は最大４バイト。ちなみに、cp932 は１文字あたり２バイト。
また文字列項目の長さを調整してデータを入れなおしました。

さて、補助文字の入出力のテストなんですが、ここからハマりました。「不正な文字」になってしまうのです。
MySQL の文字コードは結構複雑で、クライアントの文字セット、接続の文字セット、サーバーの文字セット、結果の文字セットなどがあります。
これらが utf8mb4 を扱えなくてはならないのですが、一部の文字セットが utf8 のまま。utf8mb4 になってくれません。

MySQL の構成ファイルや、JDBC のパラメータをどう変更しても utf8 のまま。困ったねぇ。
仕方がない。プログラムでセットするか。という事で、【自分で作った】データベース接続クラスのソースを開けてみました。
そうしたら、なんと、自分で utf8 にセットしていたのです。これ、ＤＢの構成、JDBC の起動後なんで、構成ファイルや起動パラメータを変更しても「手応えなし」なのは当然でした。・・・そういえば・・・

何年か前に、MySQL がややこしい文字コードを扱うように変更された時、
・データベースは CP932
・Java はユニコード
なので、ＤＢ接続クラスに utf8 にセットする部分を追加したのを思い出しました。

ったく、しょ～もない。でも、ハマるのって、たいてい原因は「しょ～もない」事なんですよね。

以上、３日かかりました。疲れた。

現状は「限定された条件」付きですが、補助文字をＤＢに格納する、読み出して表示する、が出来るようになりました。
明日から、まだ手を付けていない部分のプログラムを修正する予定です。