ブラウザはtxtファイルを表示できる。インターネットには、Windows,Mac,UNIXが相互乗り入れしている。ブラウザは、その共通プラットホーム。柔軟でなくてはならない。
ＡＳＣＩＩコードのＴＥＸＴファイルは共通プラットホームのはすだった。ただ、
改行コードにどうしようもない歴史が刻み込まれている。ＨＴＭＬがなぜ必要だったかは、この改行コード障壁をタグで乗り越えるためだった。結果論なのだが、私はそう思っている。ＨＴＭＬはテキストの改行コードを無視する。<BR>,
<CENTER>、<TABLE>といった万国共通コードが改行の役割を担っている。
色々な改行のしかた
| ＯＳ | CR（carriage return「復帰」）
LF（line feed「行送り」） | ＡＳＣＩＩ
コード | ＥＳＣＡＰＥ
シーケンス |
| Windows | CR+LF | %0D%0A | \r\n |
| Mac | CR | %0D | \r |
| UNIX | LF | %0A | \n |
ＣＲ、ＬＦは英文タイプライターの用語。｢うちのタイプライターは便利ですよ｣と独自色で販売を競ったことがあったのだろう。と想像するしかないのだが、それと同じ事がパソコン市場で繰り広げられた。体験としてよく知っている。別の話しだが、ペーターかＶＨＳかという選択の時代もあった。スタンダードが確立されるまでは、いつも始まる独自色レース。永遠になくならない事と理解している。
テキストファイルは便利。ブラウザでも表示できる。ＨＴＭＬもテキスト
ファイルなのでプレーンテキストと区別して呼ぶ。エデイタで書いた文章をそのままブラウザで見ていただく。超特急で情報交換できる。Internet ExprorerはCR+LFでもCRだけLFだけでも改行して見られるようになっている。だから便利。ＵＮＩＸのテキストをもらって、改行がなくて見れないと悲鳴を上げる前にブラウザで見ればいいのです。
テキストファイルはもうひとつ重要な役割があった。データーファイルとしての利用。こちらもＸＭＬになるのは、もう時間の問題なのだが、データー区切りとしての改行は重要な問題。ブラウザもエデイターも改行コードが見られないの困ることがある。
数値地図2500のデーターはCR+LFがデーターの区切り。ＡｕｔｏＣＡＤはCRがデーターの区切り。javaScriptで変換スクリプトを書くと、この辺をクリヤにしておく必要がある。簡単なテキスデーターを作り、シンプルなソースで検証してみる。例えば、下のように。
| <![CDATA[
function getTXT(){
var msg=TXT.document.body.createTextRange().text;
msg=msg.substring(156,160);
leng=msg.length
msg+="****\r\n";
msg+="leng="+leng+"\r\n";
msg+="*"+msg.charAt(0)+escape(msg.charAt(1))
+escape(msg.charAt(2))
+msg.charAt(3)+"*\r\n";
msg+="0.00\r,0.00\n,0.00\r\n,0.00\r\n";
TXT.document.body.createTextRange().text=msg;
}]]>
|
これは、数値地図2500のデーターでCR+LFがデーターの区切りであることを確認したソース。escape()関数で%0D%0Aを可視化している。ＩＥはCR+LF,CR,LFシーケンスどれも改行される。それで錯覚するのだが、ＴＥＸＴファイルに保存し、エデイタでみると数珠繋ぎ。当然ＡｕｔｏＣＡＤＬＴは受付けない。さてどうするかといった段階で色々実験してみた。問題を可視化すれば解決の光が見えてくる。どうも、ＩＥはCR+LF,CR,LFシーケンスをＢＲタブで置き換えているようだ。文字列操作する時、CR+LFを正確に操作しないとＴＥＸＴＤＡＴＡファイルにとしては使えないので注意。
|
テキスト処理を主体とする UNIX の管理コマンド群では、Regular Expression、正規表現が駆使される。UNIX用のエデイタは対応しているのが当たり前。
例えば、ａ.ｃはａｂｃやａ９ｃを含めた表現。6*は6、66、666を含めた表現。
では、.＊はａｂｃも666も含めたすべての文字列の表現。.は「任意の一文字」。*は「直前の文字の 0 文字以上の連続」が定義だから、そうなる。
正規表現はテキストマッチには必須アイテム。主にＰｅｒｌで使われるが、javaScriptでも利用できる。検索、抽出、置き換えには/ＨＦ.＊￥ｎ/というように使う。これは、ＨＦで始り、最後が￥ｒ￥ｎ、中間はなんでもいい。といった定義となる。
|
<![CDATA[
FH,07MD614,(中略）-81000.0,-34000.0,-79500.0,-32000.0
L1108,0,33,3
1177.7,318.0
1175.7,418.2
1175.7,428.9
L1108,0,34,20
789.5,565.6
781.5,594.5
-----------
]]>
|
上の文字列を選別して下の文字列に変換するのが今回の作業。
3パターンしかない。2番目のパターンは/Ｌ.＊￥ｒ￥ｎ/。3番目は/.＊、.＊、.＊￥ｒ￥ｎ/と表現できる。目に見えない改行コードを確認する必要があったのは、その為。
|
<![CDATA[
-layer
M
33
3dpoly
1177.7,318.0,0.00
1175.7,418.2,0.00
1175.7,428.9,0.00
-layer
M
34
3dpoly
789.5,565.6,0.00
-----------
]]>
|
|
| <![CDATA[
function convrtG2500(){
var msg=TXT.document.body.createTextRange().text;
msg = msg.replace(/FH.*\r\n/, "" );
msg = msg.replace(/\r\n/g, ",0.00\r\n" );
var n=0;
var ARCno
var msg2
var n1,n2;
n=msg.indexOf("L",n)
n1=msg.indexOf(",",n+8);
n2=msg.indexOf("\n",n);
ARCno=msg.substring(n+8,n1);
msg2="-layer\r\nM\r\n"+ARCno+"\r\n";
msg2+="3dpoly\r\n";
msg=msg2+msg.substring(n2+1,msg.length);
n=msg2.length;
while ((n=msg.indexOf("L",n))!=-1){
n1=msg.indexOf(",",n+8);
n2=msg.indexOf("\n",n);
ARCno=msg.substring(n+8,n1);
msg2="\r\n-layer\r\nM\r\n"+ARCno+"\r\n";
msg2+="3dpoly\r\n";
msg=msg.substring(0,n)+msg2+msg.substring(n2+1,msg.length);
n=n2+msg2.length;
}
TXT.document.body.createTextRange().text=msg;
}
}]]>
|
msg = msg.replace(/FH.*\r\n/, "" );で一行目を削除している。2行目でＺに値0を一気にセットしている。
その後、Ｌ11.....の行をＡｕｔｏＣＡＤＬＴ用に書き換えている。うまくいったはずだ。従来ならテキストファイルから一行読んでは書き換えて保存するのだが、オブジェクト指向のjavaScript風にテキストファイル全体をメモリーに置き、文字オブジェクトとして操作している。
数値地図25000のＸＭＬデーターならＤＯＭに従い、すべてがnodeオブジェクトなので話はもっと簡単。しかし、膨大なnodeを一度にＰＣのメモリーに展開するのは、いかにも非現実的。僕のＰＣはフリーズしてしまった。
ＸＭＬは一般仕様書だからその通りにプログラムしても実用とは行かない。アプリケーション開発者の知恵と工夫で改良されてゆくのだろう。大型コンプユータのある政府センターならいいのだろうが、ＰＣユーザーＳＯＨＯにとっては、2003年の時点でＭＳＸＭＬは代価を払っても買いたい商品に育っていないと私は判断した。javaScriptでオブジェクト操作。これが立派な21世紀型データー処理だとおもうのだが。
|
2003.11.13
by Kon
|