linuxはファイルの文字コードをどうやって認識しているの？

Question

##質問

linuxが文字を理解する時の流れの仮説は正しいか？

【linuxが文字を理解する時の流れの仮説】（$LANGにutf-8が設定されている場合）

**１．**読み取ろうとするファイルの中身（バイナリデータ）を、環境変数$LANGに設定されている文字コード対応表と照らし合わせて文字変換する。

**２、**対応表には主な文字コードデータのBOM情報が含まれており、もしBOMが記載されていた場合はその文字コードで変換をし直す。（「Shift_JIS」という文字をutf-8で読み取ったときのデータは「432432(適当)」となるのでもし「432432」という文字がファイルの最初の方に書かれていたらShift_JIS対応表で変換し直す）

--BOMが記述されていた場合はここで終わり--

**3、**linuxにはある程度文字化けしているかを確認できる機能がついていて、読み取ったデータにBOMがなく更にutf8で変換してみたものの文字化けしていると判断された場合には他の文字コードでいくつか変換してみる。

**4、**変換した結果文字化けが最も無いと判断された文字コードでそのファイルを表示する。

##背景

私はqiitaの記事を読み、また自らの実験結果や経験とともにlinuxが文字を理解するときの流れについて一つの仮説を立てました。

qiita：テキストファイルの文字コードは中身で決まる。らしい。

Answer 1

Linuxはファイルの文字コードを判定しません。プログラムが、なんらかの指定に基づき、エンコーディングを仮定してファイルを読んで処理します。
環境変数LANGをどう使うかも、プログラム次第です。

BOMというのはUncode特有の物です。UTF-16、UTF-32に於いてのバイトオーダーを判断するための物です。

nkfは、出現文字のスコアをカウントして文字コードの自動判定を行います。
なので、複数のエンコーディングで解釈しても正当なファイルの場合は、誤判定があり得ます。

vimは、fileencodingsの設定に基づき、先頭から順にエンコーディングを仮定して解釈し、矛盾が生じれば、2番目、3番目、・・のエンコーディングを順番に仮定して解釈します。

Comments

[tacsheaven]

一応補足。UTF-8 にも BOM はあります（非推奨ですが、UTF-8 であることを明示するために使用されます）。
ちなみに Microsoft Excel は BOM 付きの UTF-8 でないと、UTF-8 と認識しない場合が多いです。なので CSV ファイルには BOM を付ける、というのが（ことにWebアプリでCSVエクスポートする時とか）ほぼお約束だったり……

[otn]

質問者はBOMについての誤解があるようなので、
Byte Order Mark の定義（目的）を述べたつもりです。
UTF-8に於いては、バイトオーダーが意味をなしませんので書きませんでした。
「UTF-8、UTF-16、UTF-32に於いてのバイトオーダーを判断するための物です。 」
と書いたら変でしょ？

[domidomi]

気になったらどうしても気になってしまうので変な疑問が湧きやすいのすが、それでも何度かご回答いただきありがとうございます。

linux自体は文字コードを判定していない、それぞれのプログラムが判定している、そのプログラムの判定の例（nkfやvimの文字コード判定方法）の情報を記述されていて一番腑に落ちました。

Answer 2

私の理解では、文字コードの判別を担っているのは個々のエディタであったりツールであったりです。「linuxが」行っているのではないと思います。どんなことが起こっているのかはそれぞれのツールのドキュメントを調べるべきでしょう。

Comments

[domidomi]

つまり上記qiitaのページではnkfライブラリが独自に文字コード判別機能を実装しているという解釈でしょうか？
nkfライブラリはどのような仕組みを使って文字コードを判定しているのでしょう？

文字コード対応表に優先順位がついていて、文字コード対応表の中に存在するバイナリ列がでてきた瞬間にその文字コードを返すという処理みたいな感じでしょうか？

[KojiDoi]

"文字コードデータのBOM情報"なんて言葉が出てくるところを見るとそもそも「文字コード」がよく理解できていないのではないかという気がします。

[domidomi]

回答ありがとうございました。

Answer 3

「文字コード判別」でぐぐろう

linuxにはある程度文字化けしているかを確認できる機能がついていて

そんなファンタジー機能を想定できるならなんでも可能になりますな。

Comments

[domidomi]

すみません「文字コード判別」から発展し色々調べてみたのですが、疑問は解決できませんでした。（調査力がたりず申し訳ないです）
管理領域にも文字コードは記載されておらず、ファイルの中身にも文字コード情報は存在していないとなるとどのようにファイルの文字コードを理解しているのでしょうか？

文字コード対応表に優先順位がついていて、文字コード対応表の中に存在するバイナリ列がでてきた瞬間にその文字コードを返すという処理みたいな感じですか？　

OS名　ソフト名　ファイル拡張子名　ミドルウェア　カーネル　文字コード　判別　方法　仕組み　文字コード名　バイナリ
等いろいろ組み合わせてぐぐってみましたが、なかなか腑に落ちません

Answer 4

1. ...環境変数$LANG

これはアプリが対応していれば、です。個別のテキストファイルには関与しません。
そもそも、文字コード対応表はどこにあるのでしょうか?　(従って、2. は意味無し)
[追記] 上記は不適切でした。 $LANGは、OS(OS Tool)を含めたアプリに対し、環境変数 $LANGが定義されている事を示すだけです。後はアプリ(シェルとかも含む)次第。一般には、メッセージとかの表示を変える事が多いと思いました。

3、linuxにはある程度文字化けしているかを確認

OS本体は、個々のファイルの中身に関与しません。

元々、Linux(Unix)では、個々のファイルは"単なるバイト列"。中が何かは、それを参照するアプリ(OS ツールも含む)による。従って、OSは関与しません。
個々のアプリの判断は、他の方も書かれていますが、そんなものでしょうか。(当然、設計者依存)
ファイルの文字コードと言いますが、常に一つに決定できるとは限りません。私が使っている古いエディタは自動判定をよく間違えます。以前、中国とか、欧州とかの人と仕事をした事がありますが、(管理が緩かったためか) コメントに各国語が混在。Unicode以前なので、そのコメントは化け化け、何語と判断できるか? (コンパイルが通ったので、そのまま)

おっと、半角英数字しか含まれないファイルは、Asciiか? 可能性は大ですが、
UTF-8 でも同じです。Shift-JISでもカナ漢字を使わなければ、ありです。 単なる余談でした。

[追記] 質問文に引きずられてしまいましたが、テキストファイルという概念は、Linux(Unix)にあるか? 上にも書きましたが、全てのファイルは、ただのバイト列。
また、一つのシステムには、複数のファイルがあります。それを 単なる環境変数の設定で、全て (例えば) UTF-8 と決めつける事はできません。また、複数の人が同時にアクセスするのに一つに決める事ばできません。

ただし、Mac とかWindowsだと話がちょっと違うかも。こちらは、ファイル属性を持てるし、拡張子と、アプリの関連付けもあります。

Comments

[domidomi]

回答ありがとうございます。ものすごく参考になりました。環境変数についてや、”linuxにおいてファイルは単なるバイト列”という情報は独学でやっている私にとって嬉しい情報でした。
古いエディターの誤判定があるという事実からそれぞれのソフトが文字コード解釈を担っている事もよくわかりましたし、関心のある情報をありがとうございました。

Answer 5

文字コードをパターン出現頻度から__確率的に__推定することは可能です。実際にそのようなライブラリはあります。Linuxがそれを使っているかどうかはわかりませんが。
そもそも文字コードは事前にお互いに取り決めてからやりとりするべきものです。

Comments

[退会済みユーザー]

エンコーディングによっては互換がきいたりしてあたかも推定できているように見えることがあるので、そういう部分で誤解があるような気もします。

[domidomi]

回答ありがとうございました。