Unicode→UTF-16とか
Windowsの昔のツールだとUnicodeと呼ばれていた文字コードは、UTF-16だったりする。LEかBEかはBOMでわかるのだが、WindowsはUTF-16 LEのような形で保存していたりする。
UTF-8ではないので一応注意。
UnicodeにもBOMがあることが。
こちらはあってもあまり気にされていないかもだが、データを素で取り込もうとすると困った事になったりするので注意。
パスの扱いについて少し。
Windowsのファイルパスは実の所、UTF-16なんであるけども、シェル等を介する場合にUnicodeをうまく認識出来ないケースがある。わざわざShift-JISに変換して取り込もうとしたりする。
現在SASはS-JISで使われているケースが多いとは思うが、海外ではあまり遭遇しない事例でもあり、注意。
なお、zipファイルのアーカイバも文字エンコーディングに対応していないのがある。MacとWin間で化けるのがそれのせい。
SASからシェルを呼び出したりDDEを呼び出したりするのの限界について。
SASは生でインストールしている場合にXCMDが有効化されているのだが、例えばSAS Analytics UとかはNOXCMDのはず。
有効化されているとPIPEとかでコマンドの結果を得られたりするのだが、セキュリティ上の問題から生のディレクトリを参照出来たりしないよう殺されている。
よくよく考えれば当たり前の話なのであるが、子プロセス立ち上げられるのは良くないので、使わないに越した事はない。
なお、DDEを悪用してのExploitが出ていて、セキュリティ上問題があるなという認識がMSにもある。
XLSXエンジンについて
SAS/ACCESSS Intrerface to PC Filesでは、MSのエンジンを使ってEecelを読み書き出来るのだが、その場合にビット数の問題がよく発生していた。ビット数の違いで書き方変えなければいけないのもアレですし。
Excelをデータ格納場所として考えるなら、その縛りのないXLSXエンジンとか使うのも手。ただ、実際にはそんな事は期待出来ないんだけどね。
Excelを出力先として帳票出力、というのは、今後はあんまりやるべきではないと思っている。というか、SASからは何かのテンプレートに流し込む為のデータを作成し、帳票そのものの整形は別のツールでいいんじゃないかなと思うんだが。
SASのレイアウト作成ロジックはかなり気持ち悪いしコントロールが難しい。HTMLは帳票作成には向いていないし、XLSTとかはあんまり聞かんなあ。
結局、安定して今も使われているRTFがいいんだろうという事になっている・・・・・のだが、Texの復権があってもいいんじゃないかと個人的には思っている。いい加減、見た目とデータを分離してほしいんだ・・・・・・。
SASをDockerに入れたい
www.sas.com
ライセンス費用節約の為にあんまり意味のないSASサーバ接続をやめたいなと。
必要な時にDocker動かしてSAS実行させて、プログラムソースとかはgitで管理とかどうよ。
とか言っても、日本の会社のITってとにかくリソースが枯渇気味なので、こういう方向転換出来るのは何年後になるんだろうなあ。死ぬまでに変わるかしらん。
