ファイルのやり取りができないサーバーからクリップボードを経由してファイルを取り込む方法
我社においては、自席のパソコン（以下「自席PC」。）は、直接インターネットに繋がっていない。20年近く前に入社して以降、システム部門が、便利さと安全さの間で、あの手この手で対策を練りながら、インターネットへの接続方法が変化してきたが、現在は、いわゆる「仮想アプリケーション」（以下「仮想アプリ」。）という形のブラウザを起動しないと、各種ウェブサイトを閲覧できない。
仮想アプリというのは、正直、あまり聞き慣れない言葉だったが、似た言葉として「仮想デスクトップ」（以下「仮想DT」。）というのは聞いたことがあった。これは、ざっくり言うと、自席PC からネットワークで繋がったサーバー（単なるパソコンの場合もある。）にキー入力などを送り、同時に、その結果の画面を自席PC側へ表示するようなもので、もう少し具体的に書けば、CPUやハードディスクはサーバー側の資源を使い、マウス、キーボード、ディスプレイは、自席PC を使う利用の仕方なのだ（まあ、古い人間なら、ホストコンピュータとダム端末の関係と言ったが分かりやすいかもしれない。）。
では、仮想アプリというのがどんなものかというと、これもざっくり言うと、その仮想DT内で、とあるアプリケーション（以下「アプリ」。）が動作している場合に、そのアプリだけを表示するようなものと言えるだろう。具体的には、起動しても仮想DT のように、サーバー側のデスクトップ画面が表示されることはなく、自席PC には、単にアプリのみが表示される。なので、一見すると、１つのアプリとして自席PC で動作しているようにも見えるのだが、実は、これもサーバー側で動作しているのだ。
ということで、我社においては、この仮想アプリとして、サーバー側のブラウザを起動することで初めて、各種ウェブサイトが閲覧できるようになっている。
○仮想アプリ利用のメリットとデメリット
・メリット
仮想アプリを利用したウェブサイト閲覧のメリットとしては、サーバー側の性能さえ強化しておけば、自席PC の性能に力を入れる必要はない、ということが挙げられるだろう。また、いわゆる画面が転送されるだけなので、仮にウェブサイトを閲覧しただけで感染するようなウィルスと遭遇したとしても、自席PC がウィルスに感染することはない、ということも挙げられる。当然に、サーバー側がウィルスに感染する可能性も考えられるが、逆にいえば、サーバー側さえ対策を強化しておけばいいのである。
・デメリット
デメリットとしては、当然に、サーバーがダウンしたら、サーバーに繋がっているパソコン全体が影響を受ける、というのもあるが、もっと身近なところでは、各種ウェブサイトからファイルをダウンロードしたとしても、その保存先が「サーバー側」となり、自席PC へ直接保存されないことが挙げられる。
そして、そのサーバー側にあるファイルを自席PC へ取り込む方法が、実は単純ではない。本来、ネットワークは繋がっているので、技術的な話としては、（サーバー側が Windows であれば、）ファイル共有の設定さえされていれば、いわゆるファイル単位でコピペが可能だと思う。また、（サーバー側が Windows でなくても、）やや古い技術にはなるが、サーバー側に FTPサーバーが立ててくれていれば、やり取りはまだやりやすいだろう。
しかし、そもそもセキュリティ強化のために、仮想アプリを使わせているのだからだろうか、運用的な制限をかけているのか、関係のポートが開いていないのか――とにかく、自席PC からは、サーバー側のファイルを取り込むことができない。
○正規の手続きによるサーバー側ファイルの取り込み
ということで、サーバー側のファイルを取り込むための正規の手続きとしては、①サーバー側から「専用のサイト」（以下「中間サーバー」。）に目的のファイルをアップロードし、②その中間サーバーで、「ファイルがウィルスなどに感染していないこと」の確認があったあと、③自席PC から中間サーバーにアクセスし、ダウンロードすることで取り込むようになっている。要は、中間サーバーを経由しないと、自席PC へファイルを取り込めないのだ。
確かに、利便性と安全性はトレードオフの関係があり、簡単に取り込めるようにしたら安全性が損なわれるのは理解できる。しかし、この一連の流れは、それなりに煩雑で、かなりの便利さが損なわれているのだ！
そして、プログラム実行ファイル（以下「exeファイル」。）は、上記の正規の手続きを踏んでも、取り込めないようだ。私の友人情報によれば、以前は、拡張子を偽装したりして（懐かしい！）、取り込めていたようだが、そのうち、その手段も封じられたようだ。
ということで、この辺をどうにか簡略できないか、正規の手続きを回避してファイルを取り込めないか――と調査していたところ、次に示す方法で回避できることが分かったので、あくまで技術的な話として、ここに記しておくものである。
なお、この記事は、あくまで、技術的な資料として残しているだけであり、実際に、正規の手続きを回避することを勧める趣旨の記事ではない。また、この方法により、なんらかの損害が発生したとしても、私は一切の責任を負いかねる。自己責任ということで、予めご了承いただきたい。
○正規の手続きによらないサーバー側ファイルの取り込み
ということで、早速、正規の手続きを回避したファイルの取り込みについて説明に入るのだが、まず、その前提として、自席PC と仮想アプリ間において、（テキスト形式の）クリップボードが共有されている必要がある。
ただ、この機能は、例えば、自席PC での作業中に検索したい言葉があった際に、仮想アプリのブラウザの検索バーに貼り付けたりするという使い方を考えても、そう簡単にはなくせない機能だろう。また、その他、クリップボードが共有されている理由は、単にテキストデータのやり取り程度であれば、ウィルス感染の危険が少ない、という考えもあるかもしれない。
・テキストファイル編
ということで、このクリップボード共有の機能を最大限に活かし、①サーバー側で取り込みたいテキストファイルを開き、②「すべて選択」し、③それをクリップボードへコピーし、④自席PC側で空のテキストファイルを開き、⑤クリップボードから貼り付け、⑥それを保存すれば、中間サーバーを経由することなく、結果、テキストファイルとして取り込むのと同じことができる。
ちなみに、この技は、仮想アプリのブラウザのブックマークをバックアップする方法として、実際にシステム部門から案内があったのと同様の方法だ。つまりは、単にテキストファイルを取り込むだけであれば、正規の手続きを回避できるということなのである。
注意としては、利用するテキストエディタ等によっては、文字コードを適切に設定しないと、文字コードが変換されて取り込まれる可能性があることだ。この辺を何も考えずに、バイナリレベルで一致させて取り込みたい場合は、後述の「バイナリファイル編」で示す方法で取り込めばよい。
また、ファイルサイズが極端に大きく、クリップボードの上限を超えるような場合は、このコピペ作業を複数回繰り返せばよい。
余談だが、応用編として、表計算ソフトで作成した簡易な表程度であれば、クリップボード経由で、そのまま表形式で貼り付けることができた。その仕組みとしては、要は、クリップボードの中身が、単に、「値」と「タブ文字」で構成されたテキストデータであり、貼り付け先で「タブ文字で区切られたデータ」として捉えられたからだと考える。よって、セルの色や罫線などは取り込めないことに注意したい。また、同様に、ワープロソフトで作成したテキスト部分も取り込める。これも同様に、書式などは取り込めないが、取り急ぎ、テキストデータのみで充分の場合は、このクリップボードを経由したデータのやり取りは、機動性も悪くないと言えるだろう。
・バイナリファイル編
では、取り込みたいファイルがバイナリファイルの場合――例えば、ワープロソフト、表計算ソフト、プレゼンテーションソフトなどで作成した電子文書や exeファイルの場合――は、どのようにしたら取り込めるのだろうか。当然に、テキストデータでないことから、テキストエディタで開くことができず（ファイルの中身をテキストのみで表すことができず）、上記の方法では取り込めない。
単純に考えれば、同様に、サーバー側と自席PC側で、それぞれバイナリエディタで開き、バイナリ文字としてではなく、バイナリ文字の文字コード（0x00～0xFF）でクリップボードを経由して貼り付ければ可能なのかもしれない。しかし、それを試すには、サーバー側にバイナリエディタを取り込む必要があり、バイナリエディタが exeファイルであることから、正規の方法ではサーバー側に取り込めない。
そこで、バイナリファイルを一旦テキストファイルに変換ができれば、上記「テキストファイル編」と同様の方法で取り込めるのではないかと考えた。――そう。そこで出てくるのが Base64 変換である。
○Base64 変換とは？
私が初めて電子メールに触れたのは、約30年前――その頃は、まだ、ワークステーションサーバーに Telnet でログインしてメールを閲覧するというようなテキストベースのものだった。その際、受信したメールに添付ファイルがあった場合は、本文中に Base64 という文字と、その後に続く文字化けのような文字、しかし整列された文字をよく見ていた。なので、私と同世代には馴染みがあるものかもしれないが、取り急ぎ、Base64 の詳細は、次を参照されたい。
要は、この変換は、テキストで表示できないバイナリデータをテキストデータに変換するものなのだが、その代償としてサイズが増えてしまう変換なのである。サイズが増えるといっても、３割程度のようなので、通信回線も速く、保存容量も増えた現代に置いては、そんなに大きな問題でもないだろう。
繰り返しになるが、この Base64 変換を用いれば、バイナリデータがテキストデータに変換されるので、上記「テキストファイル編」と同様の方法でファイルが取り込めるようになるのだ。
○Base64 変換をする方法
問題は、この Base64 に変換するための手段であるが……今や、この程度の変換であれば、スクリプトで記述できる程度になっていた。時代も進んだものだ。スクリプト自体は、ネットを検索すれば、いくつかヒットするし、今や懐かしい Vector にも VBScript で置いてあった。
そして、スクリプトというのは、当然に、テキストで記述されるものなので、スクリプトファイル自体も、簡単にサーバー側とやり取りができる、ということなのである。
よって、これらの情報と手段を駆使すれば、バイナリファイルだって取り込めるようになるのだ！ ただし、前提として、サーバー側で問題なくスクリプトファイルの実行ができる環境がある必要があるのだが……。
○正規の手続きによらないサーバー側のバイナリファイルの取り込み
ということで、上記までをまとめると、次の方法を取ることで、サーバー側からバイナリファイルを取り込むことができる。
① Base64 エンコード機能を備えたスクリプトファイルを、サーバー側に用意する。サーバー側でインターネットからダウンロードするか、クリップボードを経由して自席PC からサーバー側に取り込むか、ゼロから自身で作るか……するとよい。
② サーバー側にある自席PC に取り込みたいバイナリファイルを、①のスクリプトを使って Base64 にエンコードする。
③ ②のファイルを、クリップボードを経由して自席PC に取り込む。具体的には、上記「テキストファイル編」の方法による。
④ ③のファイルを、自席PC において、Base64 からデコードするスクリプトファイルを使って、バイナリファイルに戻す。
言葉で書くとどうしてもややこしくなってしまうが、実際にやってみると、正規の手続きを踏むよりも、簡単に済む場合もある。特に、小さいファイル１つだけを取り込みたい場合などは、この方法が本領を発揮する。
あとは、中間サーバーを経由しない形でのやり取りであるため、監視されているような気分を味わうことなく、妙な達成感を味わいながらファイルを取り込むことができる。クリップボードが監視されていれば同じことではあるが、現時点において、未だシステム部門からお咎めをいただいたことはない。
○今回の所感
システム利用において、何らかの制限があると、それを突破したくなるのは、もはや私の性なのかもしれないが、こんな性質を本業に活かせてないのが悲しくもある。
ちなみに、私も以前、我社のシステム部門にいたことがあるので分かるのだが、このように、中途半端にシステムに詳しい社員というのが、一番厄介だったりもする（笑）。
あと、参考までに、我社では、そもそも自席PC において、何の制限もなく外部メディアである USBメモリなどを刺し放題なので、実は、こんな苦労をすることなく、自宅でダウンロードしたデータを USBメモリを使って、自席PC に取り込むことができる。なので、個人的には、この中間サーバーの意味も、あまりないのではないか？ くらいに思っているのだが……。
その他の関連事項としては、仮にクリップボードさえ共有できないような環境であっても、もし QRコード作成ができる環境なら、その作成したそのコードをスマホなどで読み取り、テキストデータで持ち出すこともできるだろう。これも、やり取りの記録が残らないデータ取り出し方法と言えるだろうか。
なお、繰り返しになるが、この記事は、正規の手続きを回避することを勧める趣旨の記事ではないし、この方法により、なんらかの損害が発生したとしても、私は一切の責任を負いかねる。あくまで、自己責任ということで、ご了承いただきたい。
この記事が気に入ったらサポートをしてみませんか？