「C言語/ファイル入出力」の版間の差分

::英語で、本や文章を書く読むことを read （リード）という。 rとは、その read の 頭文字r のこと。

::英語で、追記（ついき）や付録（ふろく）の加することを アペンディクスド appendixappend という。 aとは、その appendixappend の 頭文字a のこと。

fclose は、ファイルを閉じる命令関数である。クローズしている最中のファイルは、プログラミングによる読み書きなどの操作をできない。

:\ユーザー名\syntaxhighlightsource\repos\プロジェクト名\プロジェクト名

のアドレパスのフォルダにある。

VisualStudio 2019 をインストールしたとき、既に syntaxhighlightsource というフォルダのある場合を除けば、普通は インストール時に syntaxhighlightsource という visual studio のプログラミング用のフォルダが自動作成されているので、そこのフォルダを探せばいい。

:（なお、「fprintf」とはC言語の専門用語であり、日常英語には無い用語である。読みは、日本では慣習的に「エフ・プリントエフ」とでも読む。）

fprintf の冒頭のfは、ファイル関係であることをあらわしている。最後のfは、もともとC言語には「printf」（プリントエフ）という関数があり、（最後のfは）ファイルとは無関係）Format の f。

<code>fp1 = fopen("test1.txt", "r");</code> のような命令関数で読み込みに失敗した場合、つまり、普通なら読み込み対象のファイルが無い場合は、

そもそも、命令関数<code>fp1 = fopen("test1.txt", "r");</code>の実行直後は、

ついつい、ファイルを開けなかった場合などには、「この命令FILE構造体へのポインタは用済みだから、すぐファイルを閉じよう（×）」って発想で、むりやりブロック中でクローズしようと思いたくなります。

また、そのもしそもオープンに失敗したファイルをクローズしようとし、fp1 が NULL なので if 文が通った場合ので、fclose(NULL)が実行時にエラーになりまを引き起こすことは自明。

また、もしもオープンに失敗したファイルをクローズしようとした場合、Linuxでも実行時にエラはセグメンテーションホルトになります。

いっぽう、次のように改善して、読み込み失敗後のクローズ命令を除去すれば、エラセグメンテーションホルトにならず、実行できます。

同様に、elseブロック内でクローズした場合でも、さらに「ここではない」の場所でもう一度クローズしてしまうと、これもエラセグメンテーションホルトになります。

しかし、読み込みモードでは、対象のファイルが無い場合には、けっ実行形式は開こうとしてC言語コンパたファイラはルを作成しません。

Windowsの場合、システム内部の文字コードには原則的にUnicodeを使っているのだが、しかし例外的にコマンソール画面（DOSドプロンプト画面）ではマイクロソフト独自規格の文字コードを使っている。

マイクロソフト社は、これをアメリカ標準規格のANSIと呼んでいるが<ref>マイクロソフトは、CP932を「ANSI」とは自称しておらず、[https://docs.microsoft.com/ja-jp/host-integration-server/core/ansi-oem-code-page-support-snanls-1 ANSI/OEM Code Page Support (SNANLS)]の一環として、'''ANSI/OEM - Japanese Shift-JIS'''の名称でサポートしている。この節は、この誤解に基づいて編集されていることに注意する必要がある。</ref>、実は、中身は米国の行政府の定める本物の1バイト文字のANSIでなく、マイクロソフト独自規格の自称「ANSI」である。おそらく、マイクロソフト独自規格の自称「ANSI」は、日本語などの2バイト文字の表示機能を含むので、自称「ANSI」も2バイト以上の文字であろうと考えられている。

いちおう、現在ではShift-JISは日本工業規格になっているが、実際のWindowsでの文字コードの実装では、Windows用に独自にアレンジされたものを使っており、厳密には区別のためCP932という文字コード名で、技術者は呼ぶ。（[[w:Microsoftコードページ932]]）

マイクロソフト社が、そのように、コマンソール（DOSドプロンプト）の機能を調整しているからである。

コマンソール画面ドプロンプトで表示する場合、読み取るテキストファイルの文字コードは自称「ANSI」形式にしておけばいい。アクセサリ「メモ帳」の標準コードは「ANSI」（マイクロソフト自称）になっているので、特に変更する必要は無い。

もし、単に、あるテキストファイルを読み取ってコマンソール画面ドプロンプトで表示するだけの場合なら、むしろUnicodeは、使ってはならない(少なくとも初心者は)。

ただし、コマンソール画面ドプロンプト以外のGUIアプリケーションの作成では（Windows API というのを使うと、GUIアプリを作れる）、文字表示の関数がANSI形式に対応しておらず Unicode 対応になっている場合もある。最終的に現代のプログラマが作るアプリケーションのほとんどはGUIアプリであるので、Windowsシステム内部の文字コードがANSIとUnicodeに不統一になっているのは、これは深刻な問題である。

もっとも、Windowsのコマンソール画面ドプロンプトに表示する場合、そのような言語指定なく、表示できる。

Fedora28の場合、読み取り対象のテキストファイルの文字コードを何に変えても、コマンソール画面ドプロンプトで正しく表示される。

なお、Linuxでよく標準的に付属してくるGCCコンパイラ glibc には、fopenのワイド文字バージョン( wfopen のような関数)は無い。