web-dev-qa-db-ja.com

ファイルがPOSIXで定義されているテキストファイルであるためには、どのような条件を満たす必要がありますか?

POSIXはテキストファイルを次のように定義しています。

ゼロ以上の行に編成された文字を含むファイル。行にはNUL文字が含まれておらず、<改行>文字を含めて、長さが{LINE_MAX}バイトを超えることはできません。 POSIX.1-2017はテキストファイルとバイナリファイルを区別しませんが(ISO C標準を参照)、多くのユーティリティはテキストファイルを操作するときに予測可能な、または意味のある出力のみを生成します。このような制限のある標準ユーティリティは、STDINまたはINPUT FILESセクションで常に「テキストファイル」を指定します。

出典: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_4

ただし、不明確な点がいくつかあります。

  1. テキストファイルは通常のファイルである必要がありますか?上記の抜粋では、ファイルが通常のファイルでなければならないことを明示的に示していません

  2. ファイルに1文字と1文字のみ(つまり、改行で終わらない1文字)が含まれている場合、ファイルはテキストファイルと見なすことができますか?この質問はごちゃごちゃに聞こえるかもしれませんが、「1つ以上の文字」ではなく「文字」という単語を使用しています。他の人は同意しないかもしれませんが、「1つ以上の文字」を意味する場合は、明示的に言うべきだと思います

  3. 上記の抜粋では、「行」を参照しています。名前に線が含まれる4つの定義が見つかりました:「空の線」、「表示線」、「不完全な線」、「線」。 「Empty」、「Display」、「Incomplete」が省略されているため、「Line」を意味すると推測するべきでしょうか。または、これらの定義の4つすべてが、上記の抜粋の行と見なされていると見なされますか?

このテキストブロックの後に続くすべての質問は、「文字」が「1つ以上の文字」を意味すると推測することに依存します。

  1. ファイルが空の場合、1つ以上の文字が含まれていないためテキストファイルではないことを安全に推測できますか?

このテキストブロックの後に続くすべての質問は、上記の抜粋では行が「行」として定義されていること、および名前に「行」を含む他の3つの定義を除外する必要があると推測することに依存しています。

  1. 「ゼロ以上の行」の「ゼロ」は、改行で終了していない文字が1つ以上含まれている場合でも、ファイルがテキストファイルと見なされることを意味しますか?

  2. 「ゼロ以上の行」とは、単一の「行」(0以上の文字と終端の改行)がいったん作用すると、最後の行が「不完全な行」(1つ以上の非行)になることが違法になることを意味しますかファイルの最後の改行文字)?

  3. 「なし[行なし]の長さは{LINE_MAX}バイトを超えることができます(改行文字を含む)」ということは、テキストファイルの特定の「行」で許可される文字数に制限があることを意味します(余談ですが、 Ubuntu 18.04およびFreeBSD 11.1のLINE_MAXは「2048」です)?

22
Harold Fischer
  1. テキストファイルは通常のファイルである必要がありますか?上記の抜粋では、ファイルが通常のファイルでなければならないことを明示的に示していません

    番号;抜粋では、標準入力が潜在的なテキストファイルとして具体的に示されています。 makeなどの他の標準ユーティリティ、 特に使用キャラクタースペシャルファイル/dev/nullテキストファイルとして

  2. 1つの文字と1つの文字のみ(つまり、改行で終了していない単一の文字)が含まれている場合、ファイルはテキストファイルと見なすことができますか?

    その文字は<newline>である必要があります。そうでない場合、これは a line ではないため、そのファイルはテキストファイルではありません。正確にバイト0Aを含むファイルは、1行のテキストファイルです。空の行は有効な行です。

  3. 上記の抜粋では、「行」を参照しています。名前に線が含まれる4つの定義が見つかりました:「空の線」、「表示線」、「不完全な線」、「線」。 「空」、「表示」、「不完全」が省略されているため、「線」を意味していると推測すべきでしょうか。

    それは本当の意味での推論ではなく、単にそれが言っていることです。 Word "line"は文脈的に適切な定義 が与えられているので、それがそれについて語っています。

  4. ファイルが空の場合、1つ以上の文字が含まれていないためテキストファイルではないことを安全に推測できますか?

    空のファイルはゼロ(またはそれ以上)の行で構成されているため、テキストファイルです。

  5. 「ゼロ以上の行」の「ゼロ」は、改行で終了していない文字が1つ以上含まれている場合でも、ファイルがテキストファイルと見なされることを意味しますか?

    いいえ、これらの文字は行に編成されていません。

  6. 「ゼロ以上の行」とは、1つの「行」(0以上の文字と終端の改行)が効力を発揮すると、最後の行が「不完全な行」(1つ以上の非行)になることが違法になることを意味しますかファイルの最後の改行文字)?

    illegalではなく、単にテキストファイルではありません。代わりにテキストファイルを指定する必要があるユーティリティmayは、代わりにそのファイルが指定された場合に悪影響を及ぼします。

  7. 「なし[行なし]は、改行文字を含めて{LINE_MAX}バイトを超えることはできません」とは、テキストファイルの特定の「行」で使用できる文字数に制限があることを意味します

    はい。

この定義は、テキストベースのユーティリティ( たとえば、grep )が確実に受け入れるものにいくつかの境界を設定しようとしているだけで、それ以上のものはありません。彼らはより自由に物事を受け入れることも自由であり、実際にはかなり頻繁に受け入れます。固定サイズのバッファーを使用して行を処理したり、いっぱいになる前に改行が表示されると想定したりすることが許可されます。物事を読みすぎている可能性があります。

23
Michael Homer

POSIXで定義されているとおり:

はい、テキストファイルは(基本的に)です。

ゼロ以上の行に編成された文字を含むファイル。

この定義も含めると便利です。

.92文字列

最初のnullバイトで終了し、最初のnullバイトを含む連続した文字シーケンス。

.195不完全な行

ファイルの終わりにある、1つ以上の非<改行>文字のシーケンス。

.206行

ゼロ個以上の非<newline>文字のシーケンスと終了の<newline>文字。

.243改行文字(<newline>)

出力ストリーム内の文字は、印刷が次の行の先頭から開始されることを示しています。 C言語で「\ n」で指定された文字です。この文字が、次の行への移動を行うためにシステムによって出力デバイスに送信される正確なシーケンスであるかどうかは指定されていません。

.247 NUL

すべてのビットがゼロに設定された文字。

「テキストファイル」にはNULバイトが含まれないないことに注意してください


そう:

  1. テキストファイルは通常のファイルである必要がありますか?
    いいえ、必要はありません。 「テキストファイル」は、読み取ったときに何が含まれるかによって定義されます。ファイルに「0個以上の行」が含まれている場合、それはテキストファイルです。 /dev/stdinなどの一部のファイルには、一度に読み取られたときにテキストファイルが含まれ、次に読み取られたときは含まれない場合があります。
  2. 1つの文字と1つの文字のみが含まれている場合、ファイルはテキストファイルと見なすことができますか?
    いいえ、それは不完全な行です(3.195)。
    テキストファイルには、「不完全な行」だけが含まれます。
  3. 私はそれらが「線」を意味していると推測するべきですか?
    はい、そうするべきです。
  4. ファイルが空の場合、テキストファイルではないことを安全に推測できますか?
    いいえ、空のファイル(ゼロ文字)は有効な「テキストファイル」です。
    上から:…ゼロ以上の行…。ゼロ行(ゼロ文字)は有効な「テキストファイル」です。
  5. …改行で終了していない文字が1つ以上含まれている場合、テキストファイルと見なされますか?
    いいえ、「技術的には」「不完全な行」は有効な「行」ではありません。
  6. 「ゼロ以上の行」の「ゼロ」は、改行で終了していない文字が1つ以上含まれている場合でも、ファイルがテキストファイルと見なされることを意味しますか?
    いいえ、不完全な行は「行」ではありません。テキストファイルには、不完全な行がない必要があります。

  7. …テキストファイルの特定の「行」で使用できる文字数には制限があります…?
    はい、{LINE_MAX}bytes(文字ではなく)を超えないで、有効な「テキストファイル"。
    {LINE_MAX}の値は ファイル<limits.h> で指定されます
    (また読みます Cで感知できるラインバッファサイズ? ):

    {LINE_MAX}
    特に明記しない限り、ユーティリティがテキストファイルの処理として記述されている場合の、ユーティリティの入力行(標準入力または別のファイル)の最大長(バイト単位)。長さは、トレーリングのための部屋を含みます。
    許容可能な最小値:{_POSIX2_LINE_MAX}

    GNUベースのシステムの場合 設定制限なし(メモリを除く)

    マクロ:int LINE_MAX
    テキスト指向のPOSIX.2ユーティリティがサポートできる最大のテキスト行。 (これらのユーティリティのGNUバージョンを使用している場合、使用可能な仮想メモリによって課される制限を除いて実際の制限はありませんが、ライブラリがこれを通知する方法はありません。)

    posix_lim.hで2048と定義されているようです(少なくとも64ビットLinuxの場合GNUシステム):

    $ grep -ri 'POSIX2_LINE_MAX' /usr/include/ 
    
    /usr/include/x86_64-linux-gnu/bits/xopen_lim.h:#define NL_LANGMAX       _POSIX2_LINE_MAX
    /usr/include/x86_64-linux-gnu/bits/posix2_lim.h:#define _POSIX2_LINE_MAX                2048
    /usr/include/x86_64-linux-gnu/bits/posix2_lim.h:#define LINE_MAX                _POSIX2_LINE_MAX
    

    また、POSIX tility getconf を使用して見つけることもできます。

    $ getconf LINE_MAX
    2048
    

関連: テキストファイルが改行で終わる必要があるのはなぜですか?

7
Isaac