コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

ノート:プレーンテキスト

ページのコンテンツが他言語でサポートされていません。

統合関連

[編集]

テキストファイルとの統合の提案が成されております。

:バイナリまで統合してしまうと、1項が長すぎると思います。春風 2006年3月9日 (木) 05:37 (UTC)[返信]
  • (反対):en:Plain textでは、コンピュータファイルにおける「テキストファイル」(プレーンテキストファイル)とは違う内容が説明されています。テキストファイルには統合しないのが良いと思います。en:Binary and text filesにリンクさせるのは間違いと思われますので修正しました。Sina 2005年11月9日 (水) 14:49 (UTC)[返信]
  • (反対):テキストファイルというと、"text"という英語を直訳して考えると本来ならRTFやHTMLはもとより、Word形式なんかも含まれるべきだと思います。そう言った点からも「テキストファイル」の項を変更するか削除し、プレーンテキストはそのまま残した方が良いのではないでしょうか。あるいは、プレーンテキストとマルチスタイルテキストの本文をそのまま維持しつつ「テキストファイル」として統合し、現在の「テキストファイル」は削除するとか。春風 2006年3月9日 (木) 05:37 (UTC)[返信]
  • (賛成): Sinaさん・春風さんのご指摘について、英語での事情は知りませんが、日本では多くの場合「テキストファイル」と「プレーンテキストファイル」は同じ意味で使われていて、「テキストファイル」の方が一般的な用語であると考えています。夜飛さんご指摘の「ファイルシステムに依存したデータ群とはニュアンス的な違い」もテキストファイル中で説明できると思います。j8takagi 2006年9月16日 (土) 13:08 (UTC)[返信]
    • テキストテキストファイルは同じ意味でしょうか?疑問です。Sina 2006年9月16日 (土) 14:53 (UTC)[返信]
      • そういう疑問に対する回答ですと「テキストとテキストファイルは違う」「テキストだけで構成されたファイルがテキストファイル」ということになりますね。でも、現状の「プレーンテキスト」はむしろ(プレーン)テキストファイルの説明になっていると思います。冒頭で「ファイルフォーマット、または文字列の形式」と定義していますが、後者についてはほとんど説明がないです。j8takagi 2006年9月16日 (土) 15:10 (UTC)[返信]
    • では「プレーンテキスト」と「テキストファイル」は意味は違うものということでよろしいですよね? テキストについての説明と(テキスト)ファイルについての説明が混乱している部分は整理や加筆がなされるとよいと思います。でも「プレーンテキスト」と「テキストファイル」は同じものではないならば、別々の記事であってもよさそうに思います。Sina 2006年9月16日 (土) 15:32 (UTC)[返信]
      • 項目としての「プレーンテキスト」だけは残しておいて、現状の「プレーンテキスト」の内容をテキストファイルに統合することには反対しないわけですね。それでも良いと思います。ただ、この場合は「プレーンテキスト」とテキストの関係も考慮する必要はあると思います。j8takagi 2006年9月16日 (土) 15:45 (UTC)[返信]
    • 「現状の「プレーンテキスト」の内容をテキストファイルに統合」って、実質、記事の統合と同じように読めたのですが違いますか?内容を統合すべきとのお考えなのでしたら、何故に統合すべきなのか理由を確認したいです。テキストやファイル関連の記事は複数あり、どの記事名で何が記述されるべきかを考慮する必要があるという点はその通りだと思います。Sina 2006年9月16日 (土) 16:25 (UTC)[返信]
      • 「理由」はSinaさんご自身で書いているように、「テキストについての説明と(テキスト)ファイルについての説明が混乱している」からです。項目名を残して「内容の統合」するのは、Sinaさんのおっしゃる「整理」の一環だと思いますが。j8takagi 2006年9月16日 (土) 17:02 (UTC)[返信]
        • Sinaは「混乱している部分は整理すべき」とは書きましたが、「混乱している」かどうかは別ですよね?、また整理の一環として、統合が適切かつ唯一の手段というわけではないと思いまして、何か合理的なお考えがあるのかどうかお尋ねしたかったのですが。でも「統合には反対」であることをあらためてお伝えするのに留めて、再度ご意見を伺うのはひかえます。Sina 2006年9月16日 (土) 17:23 (UTC)[返信]
「テキストについての説明と(テキスト)ファイルについての説明が混乱している部分は整理や加筆がなされるとよいと思います。」は、「もし説明が混乱してるなら、加筆・整理しても良い」という意味ですか?「説明に混乱している部分があるので、加筆・整理すべし」という意味に解釈できてしまうのですが。
それはさておき「混乱」というとちょっとあいまいなので、現状は「『テキストファイル』と『プレーンテキスト』ではよく似た説明が重複して存在している」状態であると認識しています(カテゴリーが、「混乱 >> 重複」)。なので何らかの形で統合するのがよろしいかと。j8takagi 2006年9月16日 (土) 23:42 (UTC)[返信]

制御コードについてですが、MS-DOS辺りについてはEOF(End Of File)も有った、Windows辺りからファイルのバイト長で判断する流儀になった、MS-DOS辺りではファイル最終にEOFが無いと暴走するプログラムも多かった、と言う記憶がありますが違ったでしょうか。--Willpo 2005年9月20日 (火) 06:15 (UTC)[返信]

そういえばありました。書いておきます。春風 2006年3月9日 (木) 04:51 (UTC)[返信]

わたくしが知りたいのは、日本のコードのテキストについてプレーンと言いうる場合に、それがどこまでかということなのです。多分現在の「嚴密には~」からすると、それに宛たる範圍の國別コードセット内のことで、その最小セットのことと言えるのですが、日本では漢字が第四水準まで出て、その中にはエクステンションB該當のもある、つまりDOSとか95とか98でいじる場合に、そのなかが、HTMLでうまくした場合でないと見れなかったそういうテキストをわたくしはバイナリテキストと言ってたワケで、それをどういうのかということと、第二水準までは私の考えるところの日本のプレーンに收まってゐる、つまり電子メールでユニコード以外で送ることが出来る範囲内のコードの裸テキストのことなのか、というと、第三第四水準を日本コード設定で送るとどうなるかは、やったことが無いし、それはここの記事にこだわった記入者さんとそのまわりの方々自身から説明法を頂かなければ、動けない(たとえば、そのテキストのタイプが何と初行にASCIIで書くのが親切な習慣だとする場合に、どれをどう書いたものか?など) つまり、「日本コードのどこまでをプレーンと言いうるか。又JIS規格書にはiso10646入りも有る爲。該當ローカルDOSで見れればそれとの境目は何と?」ということで、16ビットコードまでがそれでもいいかなと思ってゐたら、ユニコードの32ビットにもJIS4などが飛び込んでゐるので、關連性把握の妥當性を論じて煮つめて頂きたく思います。--Benzo(Shohji Itoh) 2008年8月11日 (月) 22:26 (UTC)[返信]