cp50220, cp50221, cp50222 は MultiByteToMultiByte() / WideCharToMultiByte() で変換すべきではありません。

Outlook Express の ISO-2022-JP (cp50220) は、NEC選定IBM拡張漢字を使用しますが、MultiByteToMultiByte() / WideCharToMultiByte() は、JIS X 0212 補助漢字を使ってしまいます。

Outlook Express と同じ変換を行いたいのなら、MLANG.DLL の ConvertINetMultiByteToUnicode(), ConvertINetUnicodeToMultiByte() などで cp50220 の変換をするようにしましょう。

libiconv 1.13 のリリースに伴い cp932 関連パッチをアップデートしました。

libiconv 1.13
直接ダウンロード
http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.tar.gz
GNU Project
http://www.gnu.org/software/libiconv/
SourceForge.net
http://sourceforge.net/projects/libiconv
bug-gnu-libiconv -- Bug reports for GNU libiconv
http://lists.gnu.org/mailman/listinfo/bug-gnu-libiconv

cp932 パッチ
直接ダウンロード
http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.13-cp932.patch.gz
説明ページ
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.13-cp932-patch.html

cp932-devel パッチ
直接ダウンロード
http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.13-cp932-devel.patch.gz
説明ページ
なし

ja-1 パッチ
直接ダウンロード
http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.13-ja-1.patch.gz
説明ページ
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.13-ja-patch.html
※ libiconv-1.13-ja-1.patch.gz では、環境変数 CHARSET_ALIAS の追加されません。必要な場合は、ご連絡ください。

参考
文字コード掲示板

opengl2772 さんからのご指摘、ご要望により、libiconv-1.12-ja-1.patch.gz の Shifft_JIS-MS の typo 修正と EUC-JIS-2004, Shift_JIS-2004, ISO-2022-JP-2004 のエイリアス追加を行った ja パッチを作成しました。

ja-4 パッチ

• 直接ダウンロード
  http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.12-ja-4.patch.gz
  md5 5c666dc2622fda5650aafe0931cff412
• 説明ページ - パッチの当て方など
  http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.12-ja-patch.html

libiconv-1.12-ja-4.patch.gz は libiconv-1.12 に対するパッチです。

libiconv-1.12 は次の場所から取得してください。

libiconv 1.12

• 直接ダウンロード
  http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.12.tar.gz
• GNU Project
  http://www.gnu.org/software/libiconv/

参考

• libiconv 日本語エンコーディングパッチの謎: ナマズのブログ
• [解決] libiconv 日本語エンコーディングパッチの謎: ナマズのブログ
• GNU libiconv に EUC-JIS-2004, Shift_JIS-2004, ISO-2022-JP-2004 追加: ナマズのブログ
• ActivePerl 用 Text-Iconv PPM 更新のお知らせ: ナマズのブログ
• 文字コード掲示板

libiconv 1.12 のリリースに伴い cp932 関連パッチをアップデートしました。

libiconv 1.12
直接ダウンロード
http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.12.tar.gz
GNU Project
http://www.gnu.org/software/libiconv/
SourceForge.net
http://sourceforge.net/projects/libiconv
bug-gnu-libiconv -- Bug reports for GNU libiconv
http://lists.gnu.org/mailman/listinfo/bug-gnu-libiconv

cp932 パッチ
直接ダウンロード
http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.12-cp932.patch.gz
説明ページ
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.12-cp932-patch.html
FreeBSD ports
http://www.freebsd.org/cgi/cvsweb.cgi/ports/converters/libiconv/

cp932-devel パッチ
直接ダウンロード
http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.12-cp932-devel.patch.gz
説明ページ
なし
MacPorts
http://svn.macports.org/repository/macports/trunk/dports/textproc/libiconv/
※ libiconv 本家へのマージされやすいようにと考えて必要最低限度のパッチとして作りましたが本家には採用されず MacPorts の方に採用されたようです。

ja-1 パッチ
直接ダウンロード
http://www2d.biglobe.ne.jp/~msyk/software/libiconv/libiconv-1.12-ja-1.patch.gz
説明ページ
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.12-ja-patch.html

参考
MLog > [installer 1339] Libiconv-1.12 (with Japanese patch)
Samba - RCC System Wiki (FreeBSD ports での libiconv のインストール等)
Beginning OS X 10.5/備忘録 > cp932fix を有効にするには (MacPorts を使った libiconv のインストール方法)
だめだめ日記 > libiconv が EUCJP-MS のサポートをやめた理由を御存知ないですか?
文字コード掲示板

IE7と補助漢字（「森鴎外」と「森鷗外」）: WEBプログラミング NOW!

<<補助漢字をサポートしているアプリケーションは、実際のところ少ない。>>
この補助漢字（JIS X 0212-1990）は、天下の秀丸エディタがver. 6.0になってやっとサポートするようになったことからも分かりますように、サポートしているアプリケーションは、現在のところ少ないです。

例えば、Firefoxではサポートしていますが、IEではIE7になってもサポートされていません。せっかく秀丸エディタでEUC-JPの補助漢字をサポートするようになっても、IEでは文字化けします。「繫がる」が「恕ﾘがる」にIEでは文字化けします。明治の文豪・「森鷗外」は「森乗ｽ外」に文字化けします。

IE で EUC-JP ページの「森鷗外」を表示させると「鷗」が「乗ｽ」に化けるメカニズムを考えてみましょう。

前提知識

IE のように、国際化されたソフトウェアでは、内部処理を Unicode でして、各種エンコーディングと Unicode の変換を行うことで、多種多様なエンコーディングに対応しています。その際、Windows では、エンコーディング変換を API で、あらかじめ用意しています。個々のエンコーディングは、コードページで指定し、シフトJIS、日本語EUC、7ビットJISコードの、それぞれのコードページは、932、51932、50220(50221,50222) となっています。

IE に限らず、Windows 用の国際化されているソフトウェアは、Windows が用意している API を使うようにする事により、自前でエンコーディング変換を用意せずにすみます。しかし、Windows の変換 API で指定するコードページでサポートされていない文字、今回の場合であれば、コードページ51932 (以後、CP51932 とします) でサポートされていない JIS X 0212-1990 補助漢字は、正しく変換できないという事になります。

CP51932 と Unicode との変換の実現方法

各種の実験により、Windows では、次のような変換を行っていると推測されます。(Windows2000 Professional で確認)

CP51932 → Unicode

1. 文字列をアルゴリズム的変換で EUC から SJIS に変換
2. CP932 から Unicode に変換

Unicode → CP51932

1. Unicode から CP932 に変換
2. IBM拡張文字(115区〜119区) の文字を NEC選定IBM拡張文字 (89区〜92区) の文字に置換
3. アルゴリズム的変換により、SJIS から EUC に変換

「鷗」が「乗ｽ」に化けるメカニズム

問題となっているのは、EUC-JP のページで、「鷗」を JIS X 0212 補助漢字を使って、\x8F\xEC\xBF で表現し、それを IE で表示すると、「乗ｽ」に化けて表示されるというケースです。

IE は内部処理を Unicode で行っているため、EUC を CP51932 → Unicode 変換しています。「CP51932 と Unicode との変換の実現方法」で示した方法を実際に適用してみます。

1. \x8F\xEC\xBF をアルゴリズム的変換で EUC から SJIS に変換します。
   • この際、Windows では、JIS X 0208 の94(区)×94(点)の範囲外のコードポイントは、変換されずに SJIS 文字列の中に残るような変換をします。
   • その事を踏まえると、\x8F はそのまま残し、次のように変換されます。
   • \x8F → \x8F
   • \xEC\xBF → \xE6\xBD
2. \x8F\xE6\xBD を CP932 から Unicode に変換
   • \x8F\xE6 → U+4E57 (乗)
   • \xBD → U+FF7D (ｽ)

「鷗」が「乗ｽ」に化けました!

ポイントは、アルゴリズム的変換で EUC から SJIS に変換する際に、変換できないコードポイントを他の文字に置換するなどの処理をせずに、SJIS 文字列の中に残してしまっている事です。

Unicode → CP51932 の変換でも同様の処理をしているため、U+E000〜U+E757 のユーザー定義文字を変換すると、EUC 文字列中に SJIS のコードポイントでユーザー定義文字が紛れてしまうという問題がありますのでご注意ください。

eucJP-ms と cp51932 は、両方とも、EUC-JP をWindows標準キャラクタセットの文字を扱えるようにしたもので、それぞれ次のような拡張が行われています。

eucJP-ms は、オープン・グループ / 日本ベンダ協議会 が定義したもので、EUC-JP のコードセット1 (JIS X 0208) に、13区 NEC特殊文字と 85区〜94区には、ユーザー定義文字を追加し、コードセット3 (JIS X 0212 補助漢字) では、JIS X 0212 で定義されている文字は、JIS X 0212 のコードポイントを用い、足りない文字を 83区〜84区に追加、85区〜94区にユーザー定義文字を追加しています。

一方、cp51932 は、マイクロソフトが定義したもので、EUC-JP のコードセット1 (JIS X 0208) に、13区 NEC特殊文字と 89区〜92区には、NEC選定IBM拡張文字を追加して、コードセット3のJIS X 0212 は用いません。
また、ユーザー定義文字は、コードセット3は使わないため、コード領域が足りず扱えないということになります。

注意点としては、ユーザー定義文字を扱えるかどうかという事と、JIS X 0208 の 85区〜94区のコード割り当てが eucJP-ms と cp51932 とで異なるという事です。cp51932 の文字列を eucJP-ms によって UTF-8 などに変換してもエラーにはなりませんが、NEC選定IBM拡張文字が、ユーザー定義文字に化けてしまいますので御注意ください。

以上のように、eucJP-ms は、Windows で使われている cp51932 とは、異なるものなので、いわゆる機種依存文字を EUC-JP 符号化方式で処理する場合は、細心の注意を払って使用するようにする必要があります。

Windows の API で、cp51932 の文字コード変換する場合は、MultiByteToWideChar(), WideCharToMultiByte() ではなく、MLANG.DLL の ConvertINetMultiByteToUnicode(), ConvertINetUnicodeToMultiByte() でなければ、変換できません。

http://kaoriya.net/
cp932 は、ユーザ定義文字には未対応、NEC選定IBM拡張文字優先。
euc-jp は、cp51932 になっているようです。

libiconv-1.10-ja-1.patch.gzでの環境変数 CHARSET_ALIAS は、vim 対応のために実装したので具体的にvimの日本語文字コード処理の問題点と回避方法という事で、例を示すべきだったのかも。

http://tmtm.org/cgi-bin/w3ml/sylpheed-jp/msg/3166
ありがとうございます。

Unicode 化されたソフトの多くが、実用面から Windows 機種依存文字対応を行なっていく事で、Windows 以外の OS でも文字化けしなくなりますね。

Unicode は、確かにデメリットがあるかもしれませんが、このようなメリットもあり上手く付き合って行きたいものです。

なるせさんのテスト結果 で NetBSD 2.0.2 Citrus iconv の cp932, euc-jp-ms の変換に不具合のあることが判明しましたので、パッチを作成しました。
あらたに、euc-jp, euc-jp-ms の JIS X 0201 片仮名に関して UCS からの変換に不具合があったので、一緒になおしておきました。

元になるソース
ftp://ftp.jp.netbsd.org/pub/NetBSD/NetBSD-2.0.2/source/sets/src.tgz
ftp://ftp.jp.netbsd.org/pub/NetBSD/NetBSD-2.0.2/source/sets/sharesrc.tgz

パッチ
http://www2d.biglobe.ne.jp/~msyk/software/citrus/netbsd-2.0.2-csmapper.patch
http://www2d.biglobe.ne.jp/~msyk/software/citrus/netbsd-2.0.2-ja-enc.patch

パッチのあてかた
cd /tmp
ファイルをダウンロード
cd /
tar ztvf /tmp/src.tgz src/lib/libc/citrus src/lib/i18n_module
tar zxvf /tmp/sharesrc.tgz src/share/i18n/csmapper
cd /usr/src
patch -p0 < /tmp/netbsd-2.0.2-csmapper.patch
patch -p0 < /tmp/netbsd-2.0.0-ja-enc.patch


メイク&インストール
cd /usr/src/lib/i18n_module/MSKanji
make USETOOLS=no dependall install
cd ../EUC
make USETOOLS=no dependall install
cd /usr/src/share/i18n/csmapper
make USETOOLS=no dependall install


なるせさんの blog で、Citrus iconv のテスト結果が出ていたので、CVS からソースをとってきて、調べてみています。

CP932関連ファイル
src/share/i18n/esdb/CP/CP932.src
src/lib/libc/citrus/modules/citrus_mskanji.c
src/share/i18n/csmapper/CP/mapper.dir.CP.src
src/share/i18n/csmapper/JIS/JISX0208@MS%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0208@MS.src
src/share/i18n/csmapper/CP/CP932EXT%UCS.src
src/share/i18n/csmapper/CP/UCS%CP932EXT.src
src/share/i18n/csmapper/JIS/JISX0208VDC@NEC%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0208VDC@NEC.src

EUC-JP-MS関連ファイル
src/share/i18n/esdb/EUC/EUC-JP-MS.src
src/lib/libc/citrus/modules/citrus_euc.c
src/share/i18n/csmapper/JIS/mapper.dir.JIS.src
src/share/i18n/csmapper/JIS/JISX0208@MS%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0208@MS.src
src/share/i18n/csmapper/JIS/JISX0208VDC@NEC%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0208VDC@NEC.src
src/share/i18n/csmapper/JIS/JISX0208UDC%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0208UDC.src
src/share/i18n/csmapper/JIS/JISX0212@MS%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0212@MS.src
src/share/i18n/csmapper/JIS/JISX0212VDC@IBM%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0212VDC@IBM.src
src/share/i18n/csmapper/JIS/JISX0212UDC%UCS.src
src/share/i18n/csmapper/JIS/UCS%JISX0212UDC.src

とりあえず、調べるべきと思われるファイルを列挙しておきます。

参考資料
Citrus iconv の実装
http://citrus.bsdclub.org/doc/iconv-article-rev2.pdf

MacOS X 標準のメールソフトで、丸付き数字などを本文に入れて送信してみたら…

Mime-Version: 1.0 (Apple Message framework v623)
Content-Transfer-Encoding: base64
Message-Id: <3cd44e3c2d7d79b71d911dbcbdfeead6@mtg.biglobe.ne.jp>
Content-Type: text/plain; charset=CP932; format=flowed
To: =?ISO-2022-JP?B?GyRCPzk7MxsoQiAbJEI+LUc3GyhC?= <msyk@mtg.biglobe.ne.jp>
From: =?ISO-2022-JP?B?GyRCPzk7MxsoQiAbJEI+LUc3GyhC?= <msyk@mtg.biglobe.ne.jp>
Subject: =?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=
Date: Thu, 13 Oct 2005 04:26:39 +0900
X-Mailer: Apple Mail (2.623)

う〜ん、やるなら charset=Windows-31J でしょう。
Thunderbird では文字化けする。

現状報告。
Windows標準文字セット+JIS X 0212 と Unicode とのマッピングテーブルを1本化して、CP932、CP51932、EUCJP-MS に対応させてみました。
しかし、同じマッピングテーブルが CP932.so、CP51932.so、EUCJPMS.so に個別に含まれてしまっているので、サイズ的には意味なし。
マッピングテーブルを共有ライブラリ化する必要あり。
Samba の configure を libtool 化する必要もあるかもしれません。
といった所。

Fedora Core 3 では、Evolution ではなく Sylpheed という国産のメールソフトを使うことにしました。

機種依存文字対応という事で調べてみましたが、Windows と互換性のあるのは NEC特殊文字だけで、NEC選定IBM拡張文字を受け取ると、Unicode の Private Use Area (ユーザー定義文字がマッピングされている領域) に変換するようになっていました。

ISO-2022-JP⇔UTF-8 の変換を EUC-JP-MS 経由で変換しているためで、ここを CP932 経由で変換するようにして、CP932→ISO-2022-JP の変換で、IBM拡張文字をNEC選定IBM拡張文字に置換する事で、Windows 互換にして使ってみています。

Windows 用のメールソフトでも、IBM拡張文字をNEC選定IBM拡張文字に置換せずに ISO-2022-JP に変換してしまい、8ビットコードが出現する酷いコードを送信しているソフトもあるので、そういったソフトからのメールは文字化けしますけれども。

送信時に、機種依存文字 (JIS X 0208 外字) のチェックをして UTF-8 メールで送信するなどの事ができるといいかも。

文字コードの確認をせずに Fedora Core 3 標準のメールソフト Evolution で送信したら UTF-8 で送信されてしまい、某メーリングリストでご迷惑をおかけしてしまいました。

デフォルトのエンコーディングを ISOー2022ーJPに変更しましたが、サブジェクトだけはUTF-8 + BASE64 Q エンコード になってしまう。

ISO-2022-JP(RFC1468)は、いろいろと面倒なところがあるので、UTF-8 に移行するのは賛成ですが、有無を言わさずに UTF-8 になってしまうのは、困りますネ。

もはやインターネットメールは、一部の技術者が使うものから社会のインフラとして活用されてきているので、極力文字化けがおきないような工夫を技術的に施していく必要があるハズです。

たとえば、はじめてメールを送る場合は、相手がどのようなOSを使い、メールソフトを使っているかわからないのですから、日本であれば ISO-2022-JP でメールを送信するようにします。そして、メールを送信する際には、メールのヘッダーに自分が UTFー8 メールを受け取れるかの許可フラグのようなものを付加しておくります。UTF-8 許可フラグがついているメールを受け取った相手だけに、UTF-8 を送信するという事にするという事で、人の手をわずらわせる事なく、自動的に UTFー8 メールへの移行が行なわれるようになる事が期待できます。

あくまでも、これは一例で、穴があるでしょう。しかし、いいかげん、使う側に人間に専門的な知識がなければ正しく使うことが出来ないという現状が放置されている事は、好ましい状態とは言えません。

MTA どうしが ESMTP によって8ビット透過かチェックしているように、MUA どうしが UTF-8 Ready であるかのチェックするようにしてくれませんかね。

glibc-2.3.5 に対して ISO-2022-JP-MS と CP51932 の追加を行なうパッチを次の場所に置いておきます。

http://www2d.biglobe.ne.jp/~msyk/software/glibc/current/

一応、アルファ版ということで、お願いいたします。
要望やバグ報告をいただけると嬉しいです。

CP932, CP51932, CP5022[0-2], eucJP-ms, ISO-2022-JP-MS でのベンダ定義文字、ユーザー定義文字のマッピングを図で現わしてみました。

細かなところでは、IBM拡張文字→NEC撰定IBM拡張文字の変換で、大文字のローマ数字等は、NEC特殊文字へ変換されるなどが示されていませんが、おおまかなイメージとしては、こんな感じです。

といっても、もうすこし説明が必要かと思いますが、説明はおいおい付け加えていき、とりあえず図だけ公開しておきます。

Solaris へ Samba 3.0 をインストールするためには、libiconv にパッチをあててインストールが必要になりますが、パッチがあたらないとか、実行時に libiconv.so がみつからないなどのトラブルがあるようです。

あくまでも参考ですが、次のような手順を踏んでインストールにチャレンジしてみてください。

GNU patch のインストール

PATH=/usr/sfw/bin:/usr/ccs/bin:$PATH
export PATH
wget http://ftp.gnu.org/pub/gnu/patch/patch-2.5.4.tar.gz
gzip -dc patch-2.5.4.tar.gz | tar xvf -
cd patch-2.5.4
./configure
make
su
make install
exit
cd ..
PATH=/usr/local/bin:$PATH
export PATH

GNU libiconv のインストール

wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.10.tar.gz
wget http://www2d.biglobe.ne.jp/%7Emsyk/software/libiconv/libiconv-1.10-ja-1.patch.gz
gzip -dc libiconv-1.10.tar.gz | tar xvf -
cd libiconv-1.10
gzip -dc ../libiconv-1.10-ja-1.patch.gz | patch -p1
./configure
make
su
make install
exit
cd ..

Samba のインストール

wget ftp://ftp.ring.gr.jp/pub/net/samba/samba-3.0.20a.tar.gz
gzip -dc samba-3.0.20a.tar.gz | tar xvf -
cd samba-3.0.20a/source
LDFLAGS=-Wl,-R/usr/local/lib
export LDFLAGS
./configure --with-libiconv=/usr/local
make
su
make install
exit
cd ../..

FreeBSD や Solaris で Samba 3.0 を使う場合、パッチをあてた libiconv が必要でなおかつ、共有ライブラリの検索パスが適切に設定されている必要があるという所でつまづく人は多いみたい。

Linux での情報ばかりで、FreeBSD や Solaris での、そのものズバリの情報がなかなかみつからない事に対して不満があるようですが、UNIX系のOSは、そもそも細かな違いがあるもので、その違いを乗り越えて使うのは、ユーザーの責任というところがあったと思います。

そうはいっても、UNIX系のOSも以前に比べて、利用し易くなりオープンソースソフトウェアを利用する人の裾野が拡がって来ていると考える事ができるので、configure 一発で済むようにして、メイク&インストールは簡単にできるようにしておいた方がいいのでしょうね。

という事で、Samba の configure で iconv(3) での変換をチェックして、iconv(3) での変換が Samba では使えないと判断した場合は、Samba の方で文字コード変換するようにしてしまおうと考えています。

これが実現できれば、システムの iconv(3) に libiconv を使っている FreeBSD や eucJP-ms の変換が、eucJP-ascii のようになってしまっている Solaris では、iconv(3) を使わずに、Samba の方で適切な変換を行なえるようになります。

Samba 3.0 のコードを修正することなく、CP932、EUCJPーMS charset モジュール追加、aclocal.m4、configure.in、Makefile.in の修正だけで対応できそうです。

glibc にも、ISO-2022-JP-MS と CP51932 の追加実装してみました。
ISO-2022-JP-MS への出力で、余計なエスケープシーケンスが出力されて make tests でエラーになってしまうという問題があり、原因調査をしています。

9/26 追記 (10/1 コメント欄より移動)

不具合の原因判明。 ISO-2022-JP-2 をサポートするために複雑化していた iso-2022-jp.c からいらない部分を取り除いて、ISOー2022-JP-MS 用に使っていたのですが、不要なコードの除去が不完全だったようで、それが悪さしていました。 /usr/lib/gconv/gconv-modules を修正して iconvconfig コマンドでキャッシュファイルを更新してやることで、Fedora Core 3 標準装備のメールソフト Evolution で丸付き数字が表示されるようになりました。

libiconv 1.10 ja パッチを出したばかりですが、ja-1 パッチとして次の修正を行なったパッチを公開しました。
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.10-ja-patch.html

(1) ISO-2022-JP-MS の JIS X 0201 片仮名(半角カナ)の処理に不具合があり修正。
(2) 環境変数 CHARSET_ALIAS の導入

MinGW用
libiconv-1.10-ja-1-mingwPORT.tar.bz2

wget をインストールしておき次のようにしてメイク・インストールが可能です。

$ tar jxvf libiconv-1.10-ja-1-mingwPORT.tar.bz2
$ cd libiconv-1.10-ja/mingwPORT
$ sh ./mingwPORT.sh
質問には、すべて y を入力 (Enterキーを押して行くだけで良い)

動作確認

$ printf "\x81\x60" | iconv -f sjis -t ucs-2le | od -tx2
0000000 301c
0000002

$ CHARSET_ALIAS="Shift_JIS=WINDOWS-932:EUC-JP=WINDOWS-51932:ISO-2022-JP=ISO-2022-JP-MS"
$ export CHARSET_ALIAS
$ printf "\x81\x60" | iconv -f sjis -t ucs-2le | od -tx2
0000000 ff5e
0000002