namelesscity.hatenadiary.com
SASユーザー総会でも誰ぞの発表ありましたが。
XPORT形式の地獄。
なので、SAS V5 TRANSPORT FILEの形式だと、トランスエンコーディングの情報がないんですよねー。
SAS 9とかで見ると、エンコーディングがDefaultとか付いてます。Defaultって何ぞやというと、情報がないので現在のセッションのエンコードを無理矢理当てはめますねというくらいにしか意味はないです。
海外データの実際、あれこれ。
SASの世界の話、ですが。
欧米は大体wlatin-1。
だいたいはそうです。UTF-8であってもおおよそはコード値は同じ。
但し、Windowsでの拡張については問題があり、‡とかは位置が異なったりします。
wlatin-1、正確には、Windows-1252といいます。
Windows-1252 - Wikipedia
古来から使われている標準的な仕様としてのlatin-1ではないです。8x、9x辺りが埋まっているのが特徴。
ISO/IEC 8859-1 - Wikipedia
稀にlatin-9とかもあるらしいですが、SASの世界で多いかは知らないです。扱った事はないです。
日本の場合、SJISとEUC-JPが混ざる。
Win系のOSだとSJISなのですが、UNIX系ではEUC-JP。
SJIS、正確には、CP932とか言います。
EUC-JPはそのまんまですね。
ただ、SolarisとかはSJISだった記憶があります。本当のレガシーなデータは、つまり結構日本語環境でも文字コード混ざります。
中国語・韓国語は取り扱ってない。
まず、英語版（wlatin-1）で扱われている事が殆どだと思います。
autodetect&transcodingの方法論
発表へのツッコミみたいになるのちょっとイヤですが。
- 変換表みたいなのを作成し
- 変換表に従って実行
みたいな二段階にした方がいいかと思うのと、
- 文字コード変換のバリデーションも自動化した方がいい
です。
自分が実装したのは、「とりあえず○→UTF8変換、そこからUTF-8→○変換」を、想定しているwlatin-1やsjisの分だけ実行して、「実行が異常終了」「proc compareでの比較確認」という感じでやりました。
autodetectのロジックは作るのが面倒でかつ「フォルダ単位でのエンコーディングは普通同一」というような知見を突っ込んだ方が楽だったので。
なお、個人的には、「そろそろHTAヤバいんじゃないかな」とは思うんですが（そろそろWin10）、他、デフォルトで使えそうなのが結局Excel VBAとかだとちょっと悲しいですよね。
けど、Electronとか面倒くさそうだしなあ・・・・・・あの適当さを代替するものって、ナカナカないですよねえ・・・・・
他
文字コード変換後の実際の長さの検出
最初に、CVPMULT=3とかにしておいて、後で実際の長さに詰める、という事は全然出来るのですが、SASデータセットの場合、油断するとMEMLABELが削れたりFORMATが削れたりするので注意です。SDTMとかはFORMAT要らんですが。
ただ、変換再度あるので面倒だし、COMPRESSオプション使った方が幸せなんじゃないかと思います。
ラベルの変換、変数名やテーブル名の変換
ラベルの最大長が256バイトの為、SJISでダラダラ付けられたラベルは変換すると切れると思った方がいいです。
まあSDTMの場合には変数名やテーブル名の問題も発生しませんが、これ拡張使ってダブルバイトの変数名とか付けてると、これもまた切れます。
