Oracle 8i で、無理やり JA16EUCTILDE (や JA16SJISTILDE) を使う方法

Oracle Database と戯れていると、チルダが文字化けするときがあります。 (Oracle に限らないけど)

例えば接続先のサーバのデータベース自体のキャラクタセットが JA16EUCTILDE とかになっているのに、クライアント側からは JA16EUC で接続する場合です。

こんな状況は、なにも考えずにサーバ側だけ Oracle 8i から Oracle 10g とかにアップグレードしてしまうと発生します。
(たぶん。詳しく知らない。誰だよ、やったやつ…)

こういう時はクライアント側でも同じ JA16EUCTILDE を使う必要があるのですが、残念ながら Oracle 8i には JA16EUCTILDE (や JA16SJISTILDE) がありません。
文字化けを解消したかったら、クライアントのバージョンを(9i以降に)上げるしか無いのです。

しかし現実には、クライアントのバージョンを上げることができませんでした…。
(データベース側のキャラクタセットを変更/調整するのは、もっとできない)

…そんな状況で見つけた黒魔術です。

ここでの環境は Oracle 8.1.7 です。

lx0boot.nlt

VERSION=2.1.0.0.0

CHARACTER_SET

"JA16EUCTILDE"  837

lx20345.nlt

VERSION = 2.1.0.0.0

DEFINE character_set

  name = "JA16EUCTILDE"
  id = 837
  base_char_set = 830

  character_data = {
     0xa1c1 : 0xff5e,
  }

ENDDEFINE character_set

上記のファイルを作業ディレクトリに用意します。

さらに ${ORA_NLS33} にある lx0boot.nlb lx1boot.nlb lx2033e.nlb lx6033e.nlb を作業ディレクトリにコピーしてきます。
(逆に *.nlt を ${ORA_NLS33} に置いて、直接書き換えることもできるけど、怖いので…)

そしておもむろに以下のコマンドを実行します。

% lxinst oranls=. sysdir=. destdir=.

NLS Data Installation Utility: Version 3.4.1.0.0 - Production

Copyright (c) Oracle Corporation 1993, 1995, 1996, 1997, 1999, 2000. All rights reserved.

CORE    8.1.7.0.0       Production


Generating binary object and installation boot files...
LXI-WARN-00510: In lx20345.nlt at line 10, unicode 0xff5e out of private use range
LXI-WARN-00512: In lx20345.nlt at line 10, character 0xa1c1 is remapped

Merging installation and system boot files...


NLSRTL Object installation successfully completed

そしてできあがった lx0boot.nlb lx1boot.nlb lx20345.nlb lx60345.nlb を ${ORA_NLS33} に書き戻すと NLS_LANG で JA16EUCTILDE が使えるようになります。
(lx?boot.nlb は上書きされるので、バックアップはとっておきましょう)

同様にして JA16SJISTILDE も作れると思います。

自己責任でどうぞ。