最近の開発では、データのimportやexportの機能を付けて大量の入出力を処理しますよね。
で、exportはもちろんcsv形式それもtab区切りにすればデータ内にカンマが存在しても問題なく、excelでも何でも使って利用してくださいな・・・ってことです。（データ内にtabがいるハズもないように作ってありますから）
問題はimportなんですなぁ。相手がシステムであればキレイなcsvを吐き出してくれたりしますが、問題はexcelから吐き出したcsvなのです。（タブ区切りであろうがカンマ区切りであろうが）
セル内改行なんぞというワープロちっくなレイアウトのシートでは、吐き出すと行の途中で改行されちゃいます。その実態であるLF(chr[10])を置換から「Ctrl J」で指定することで回避できるとのことですが、これで致命的な途中改行はなくなりますが、吐き出してみるとソコココに区切りじゃないタブが連打されていたりします。（どうやらコイツらはセル内改行とは無関係な感じですが）
で、clean関数を使ってやればOKなのですが、これは関数なので定型業務ではマクロか何か噛ませてやらないと、運用担当者が大変になっちゃいそうですね。
ここまでヒィーヒィー言いながらも、進めて行っても、さらに、出力ファイルをチェックすると・・・。文字列部分がダブルクォーテーションで囲まれていたり、いなかったり？意地になって色々テストしてみました。
そしたらね。フツーの文字列はそのまま出力されるんですが、文字列の中に怪しいヤツ（例えば「,」「”」がいると、勝手にダブルクォーテーションで囲んでくれているようです。
データを活かすなら取り込み時の処理で囲まれてたらハズすようなコーディングをしなければいけませんね。データの整合がさほどシビアでなければexcelのうちに「、」「”」に置換するとかね。いずれにしても手間です。
もう、ウンザリですね。
イエね。あるでしょ「機種依存文字」。
もちろん以前から「気をつけなさいよ」とか、自分から使わないように意識してましたよ。
で、最近はEUC-JPからUTF-8の環境になり、何やらイイ感じになってきましたヨネ。
特にご提供システムのimportデータにイワユル「丸囲み数字」（①②とかね）がありまして、しかしこれがimportされると1,2とかになってしまうんですよ。アレ？osのdefaultもD/Bの文字コードも「UTF-8」なのに何故？
import生データをjavaから表示させても①だし、D/Bのテーブルにsql文で入れても①で入るし・・・。ってことはHibernate?。JDBC?。
で、結論は.
対象となるEntityクラスのsetterでご丁寧にJava.text.Normalizerを噛ませていたコトが原因でした。変な文字入れられちゃ困ると思って噛ませたのですが、Normalizerさんの仰る通り、①は変な文字でこれって１ってコトでしょ。
色々調べていると、Normalizerは比較するときに使うベキで、データは忠実に・・・・と。納得＆反省でした。
基本となるモジュールから、必要に応じた機能モジュールを拡張展開するようなヤリクチで開発を進めております。
で、運用サーバーにセットアップの際には、フル機能が動作する開発サーバーから、採用された機能分を選択的にセッティングすることになります。
っま、データベースに関しては、余分なデータはムシロ邪魔なので、初期化されたdbにテーブル作成やら外部制約やらのsql文をモジュール毎にファイルに作っておくことで、対応できますね。（システムの初期操作のための操作者は、システムに初期設定機能として、ワンクリックで生成できるようにしました）
で、システム本体、特に各コンフィグレーションも可能な限りモジュール毎に管理したいなぁ・・・と、納品完成間際のこのタイミングで、軽い気持ちで始めたら、案の定ハマッてしましました。
web.xmlやapplicationContext.xml系は、複数のファイルに分けられそうな部分を別立てにして、難なく完成。しかしハマッたのはhibernateの設定ファイルでした。といっても、分割自体が問題なのではなく、クラスの継承構造をどのように実装するか？の方法論みたいなコトで、「丁か？」「半か？」の２択しか許して貰えないhibernate君のイジワルが起因したモノでした。
mightyでは、管理する事象は大きく分けて３つです。記録の元帳に相当する、いわゆるマスター。そしてあらゆる記録（出来事）であるイベント。さらにそのイベントに関連した付随情報であるタグ（関連マスタも含む）で成り立っております。
で、この一元化されたイベント・タグにより、最大の特徴である「串刺し機能」が実装されますので、クラス構造もテーブル構造もかなり細分化されております。つまり継承のレベルが深かったり、同一構造の別クラスが多数見受けられたり・・です。
あ、今となっては、この点がキモでした。
hibernateの参考になるサイトに良く書かれているような３つの方針で、table-per-subclassを使ってマッピングしておったのですが、同一構造の別クラス・・・って、言われてみれば無駄なダミーフィールドを持たない理想的なtable-per-class-hierarchyってコトになるんですね（今に思えば）。
そろそろ核心部分ですが、table-per-subclassではマッピング定義でjoined-subclassがシバシバ採用されます。っま、追加されるデータの入ったtableと項目を足してゆく訳ですよね。対してtable-per-class-hierarchyではsubclassを使った記述でホイホイと兄弟分クラスをマッピングできちゃいます。で結果的に紛らわしいのは、このsubclassであってもjoinという記述を使えば、同じように追加されるtableと項目で子供クラスをマッピングできるんですね。ですがこのjoin君はあくまでもオマケ的なのでしょうか？SetやListが書けない。きっとcomponentを間にカマシて使えば何とかなりそうですが、そうするとクラス自体に手を加えなければならず・・・イヤです。
この地獄の混乱時点でのアセリまくった私の選択肢は以下の２つ
- joined-subclassでtable指定無しで動かないか？
- subclassでSetやListなどコレクションを入れられないか？
かなり前から、同一class定義内にjoined-subclassとsubclassは同居できないということは、書いてあり、知っており、もちろん避けていました。
仕様的にはjoined-subclassのパターンだし、discriminatorも不要だし、subclassで逃げるには工数かかりそうだし、よし、やはりjoined-subclassで行こう！！！！
結果、どうやってtable指定無しで動かしたのか？
はい、兄弟全員、親からはjoined-subclassしてますが、兄弟間では何もせずに、まったく同じ項目定義を重複して記述してあります。
ああ、カッコ悪い。
手が空いたら、hibernate関連の最新を調べたりして、このキモチ悪いのを解消しましょうね。＞自分