0

すべての意図と目的が同じである2つの中小規模のファイル（2k）があります。2 番目のファイルは、最初のファイルが複製され、バックスラッシュがスラッシュに置き換えられた結果です。新しいファイルは 80 バイト (または 1 行あたり 1 バイト) 大きくなります。

単純なバッチ スクリプトを使用してこれを行いましたが、最初は、スクリプトが意図せずにスペースやその他のアーティファクトを追加したのではないかと考えました。あるいは、拡張機能が異なるという事実が関係しているのかもしれません (一方にはtmp拡張機能があり、もう一方にはlst拡張機能があります)。

エディターから、新しいファイルのすべてのスラッシュをバックスラッシュに置き換え、拡張子を変更せずに保存しました。

そして、ねえ、何だと思いますか？ ファイルは再び同じサイズになりました。

さて、これが偶然のまぐれとして取り消される前に、最初のファイルと同じ方法で作成された他の 3 つのファイルのペア (つまり、6 つのファイル) で同じ動作が見られます。これらはすべて、ファイル内の行ごとに 1 バイト大きくなります。最大で約12kバイト、最小で約2kバイトです。

cmd.exeWindows 7シェルを使用しているWindowsボックスを使用しているため、エスケープとは何の関係もないと思います。

また、もう一つ。私は次のことを試しました： 

  echo \\\\\ >> a.txt
  echo ///// >> b.txt

サイズが一致したファイル (7 バイト)

この動作について誰か説明がありますか？

4

2 に答える 2

2

改行の種類 (Windows/Mac/Unix) を表示するNotepad++などのエディターでファイルを開くことをお勧めします。ファイル サイズが 1 行あたり 1 バイト異なる場合、これが問題である可能性が高くなります。

Notepad++ は行末を小さな CR/LF 記号として表示し ([表示] -> [記号を表示] -> [行末を表示])、Windows/Mac/Unix の行末を変換します ([編集] -> [EOL 変換])。

Unix と Mac の両方のシステムは通常、行末が 1 バイト (Mac: CR、Unix: LF) のファイルを保存します。Windows は 2 バイト (CR LF) を使用します。

バッチ スクリプトが使用するプログラムによっては、システムが純粋な Windows ボックスであっても、これが発生する場合があります。エディターを使用しても違いが得られない理由は、通常、エディターはファイルの元の行末を維持するためです。

于 2013-08-20T15:14:12.733 に答える
0

わかった。私はちょうどそれを解決しました。@schnaaderは私を正しい方向に向けました。実際には、スラッシュやバックスラッシュとは何の関係もありません。

何が起こったのかというと、私のスクリプトが各行の末尾に 1 文字の空白を追加したことです。スラッシュを元に戻した後、ファイルが再び同じサイズになったのは、以前検索して置き換えたエディター (Komodo Edit) が、ファイルの保存時に末尾の空白を自動的にトリミングするように設定されているためです。

面白い。

于 2013-08-20T15:20:33.163 に答える