.Net系はUnicodeになっているので、.Netの世界でクローズしているシステムではbyte単位を意識することは殆ど無くなりました。
詳細は確認してないのですが,Accessは以前からUnicodeだったと記憶してます。そのおかげで,文字長はbyte単位でなく文字単位で扱えました。
相談が持ち込まれました。
Accessシステム(にしては大きなクラサバシステム)がパンク寸前になったのでオラクルDBのクラサバ・システムにアップサイジングすることになった。
プログラム開発は順調に進んでいるが、おかしな動作で落ちる。データコンバージョンで多くのデータが桁落ちする。見て欲しい。
??? 桁落ちするということで想像したのは、受け手のオラクルがUnicodeになっていないのかな?
案の定、SJISになっていました。 オラクルも最近新規導入したものだったので,なぜSJISにしたのかと問うと、「デフォルトのまま設定したよ」と返事。
知らぬとは恐ろしい事だが、そんなレベルでオラクルの運用ができるのかなという不安感一杯。
導入したばかりだったら、もう一度、導入し直したほうが良いと薦めたのですが、それはできないとのこと。
「となると、コードで対処するしかない。DBにIOする際には SJISコードでのbyte単位での長さチェックを組み込んで回避するしかないなぁ」...と返事したところ
100本近いプログラムの手直しと画面上のTextBoxの入力文字長制約の部分の書き換えを、人海戦術で行ったとのこと、その分そっくり赤字なったと伝え聞きました。
不必要な工数と費用が発生したようですが、この時、Oracleの定義をし直すか,項目毎にコード体系指定(可能なら) するほうが良いように思います。
よくよく聞いてみると、PM/SE部隊は実装経験がなく,業務分析のみ行う上流工程専門の部隊だそうです、そんな知識レベルでいいの?
オープン系の開発で,設計から施工まで行っている我が身から見たら、このような分業体制がモタラス不整合はやらなくて済む無駄な工数に思えてなりません。
自分で無意味な仕事を作ってコストを高くしてるように感じます。
汎用機系の人は、EBCDICコードが多いせいなのか、文字コードの意識がまた違っています。
SJISコードでいう,半角と全角の混在は不可能で,全角文字列の前には 開始マーク,終了時には終了マークが付きます。
仕組みで見ればJISコードに近いかもしれません。汎用機の画面では,全角項目,半角項目は明確に別れていて,別物になります。
汎用機で運用されているDB2はBCDICでコードで設定されていることが多くて、Webサーバーと連携するときのインターフェースが大変だと聞いたりもします。
汎用機の人たちには、SJISコード世界の話が通じ難い場合が多々あります。ましてUnicode/EUCなど尚更です。汎用機の世界と、オープン系の世界と、Office系の世界の人々の間のの通訳人になった気になったりします。
ユーザーからみたら同じIT関連の人なのに、IT業界内部がこんなに分裂した世界構成でいいのかと不安になったりします。
IT業界全体で基礎知識を共有できたら、作業のかなりの部分が無くなり、開発コストが格段に変わってくるものと思うのですが夢なんでしょうかね。