Debian ベースの LAMP インストールで PHP アプリをホストしています。パフォーマンス、管理、および管理に関しては、すべて問題ありません。しかし、やや新しい開発者 (私たちはまだ高校生です) であるため、Western Charsets の文字エンコーディングでいくつかの問題に遭遇しました。
多くの調査を行った結果、オンラインの情報はやや混乱しているという結論に達しました。これは、Windows-1252 が ANSI であり、ISO-8859-1 と完全に互換性があることを示しています。
とにかく、Windows-1252(1/3/4) と ISO-8859-1 の違いは何ですか? とにかく、ANSIはどこでこれに入るのですか?
クライアントが意図した方法ですべての情報を取得し、途中で文字を失わないようにするために、Debian サーバー (およびワークステーション) でどのエンコーディングを使用する必要がありますか?
私はこれにもっとウェブのような方法で答えたいと思います。それに答えるためには、少し歴史が必要です。Joel Spolskyは、すべての開発者が Unicode 文字エンコーディングについて最低限知っておくべきことについて、非常に優れた紹介記事を書きました。looongこれは多少の答えになるので、ここで我慢してください。:)
歴史として、そこからのいくつかの引用を示します: (Joel に感謝します! :) )
重要な唯一の文字はアクセントのない古き良き英字であり、32 から 127 までの数字を使用してすべての文字を表すことができる ASCII と呼ばれるコードがありました。スペースは 32、文字「A」は 65 などでした。これは便利に 7 ビットで格納できます。当時のほとんどのコンピューターは 8 ビット バイトを使用していたので、考えられるすべての ASCII 文字を格納できるだけでなく、1 ビットを余裕を持って使用することができました。
そして、あなたが英語を話す人であると仮定すると、すべてが良かった. バイトには最大 8 ビットの余地があるため、多くの人が「128 ～ 255 のコードを自分の目的に使用できる」と考えるようになりました。問題は、多くの人が同時にこの考えを持っていて、128 から 255 までの空間で何をどこに置くべきかについて独自の考えを持っていたことです。
そのため、「OEM 文字セット」が PC とともに配布されましたが、これらはまだすべて異なり、互換性がありませんでした。そして、私たちの現代的な驚きに - それはすべて大丈夫でした! 当時はまだインターネットがなく、ロケールが異なるシステム間でファイルを交換することはめったにありませんでした。
ジョエルは次のように続けます。
実際、人々がアメリカ国外で PC を購入し始めるとすぐに、あらゆる種類のさまざまな OEM キャラクター セットが考案され、それぞれの目的のために上位 128 のキャラクターが使用されました。最終的に、この OEM の自由は ANSI 標準に成文化されました。ANSI 標準では、ASCII とほとんど同じである 128 未満で何をするかについて誰もが合意していましたが、住んでいる場所に応じて、128 以上の文字を処理するさまざまな方法がありました。これらの異なるシステムはコード ページと呼ばれていました。
そして、最終的に「Windows コード ページ」はこうして誕生しました。それらは、実際には DOS コード ページによって「親」にされていました。そして、ユニコードが誕生しました！:)そしてUTF-8は「Unicodeコードポイントの文字列を格納するための別のシステム」であり、実際には「0〜127のすべてのコードポイントが1バイトに格納され」、 ASCIIと同じです。Unicode と UTF-8 の詳細についてはこれ以上説明しませんが、一般的にBOM、エンディアン、および文字エンコーディングについては読んでおく必要があります。
「ANSI の陰謀」について、Microsoft は実際に、用語集でWindows-1252 の誤ったラベル付けを認めています。
いわゆる Windows 文字セット (正確には WinLatin1、または Windows コード ページ 1252) は、これらの位置の一部を印刷可能な文字に使用します。したがって、Windows の文字セットは ISO 8859-1 と同一ではありません。Windows 文字セットは「ANSI 文字セット」と呼ばれることがよくありますが、これは深刻な誤解を招きます。ANSI によって承認されていません。
そのため、 Windows 文字セットを参照するときの ANSI は ANSI 認定ではありません。:)
Jukkaが指摘したように（クレジットは素晴らしい答えのためにあなたに行きます）
Windows-1252 ISO Latin 1。文字エンコーディングとして ISO-8859-1 とも呼ばれ、コード範囲 0x80 から 0x9F は ISO-8859-1 (いわゆる C1 コントロール) の制御文字用に予約されています。 -1252 では、印刷可能な文字 (ほとんどが句読点) に割り当てられているコードもあれば、未定義のままになっているコードもあります。
ただし、私の個人的な意見と技術的な理解では、Windows-1252 と ISO-8859-1 はどちらもWeb エンコーディングではありません。：） そう：
Web ページの場合、コンテンツのエンコーディングとして UTF-8 を使用してください。そのため、データを UTF-8 として保存し、 HTTP ヘッダーで「吐き出す」: Content-Type: text/html; charset=utf-8.
HTML content-type メタタグと呼ばれるものもあります
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
。ブラウザがこのタグに遭遇したときに実際に行うことは、宣言されたエンコーディングでドキュメントを再解釈できるように、HTML ドキュメントの最初からやり直すことです。これは、'Content-type' ヘッダーがない場合にのみ発生します。
システムのユーザーがシステムから生成されたファイルを必要とする場合は、他の特定のエンコーディングを使用してください。たとえば、一部の欧米ユーザーは、Excel で生成されたファイル、または Windows-1252 の CSV を必要とする場合があります。この場合は、そのロケールでテキストをエンコードしてから fs に保存し、ダウンロード可能なファイルとして提供します。
HTTP の設計で注意すべきことがもう 1 つあります。コンテンツ エンコーディングの配布メカニズムは次のように機能する必要があります。
I.クライアントは、'Accept' および 'Accept-Charset'リクエスト ヘッダーを介して、特定のコンテンツ タイプとエンコーディングで Web ページをリクエストします。
Ⅱ．次に、サーバー (または Web アプリケーション) は、そのエンコーディングと文字セットにトランスコードされたコンテンツを返します。
これは、ほとんどの最新の Web アプリでは当てはまりません。Web アプリケーションがコンテンツを UTF-8 として提供する (クライアントを強制する) と、実際にはどうなるでしょうか。これが機能するのは、ブラウザーが実際に期待したものではなく、応答ヘッダーに基づいて受信したドキュメントを解釈するためです。
私たちはすべて Unicode に移行する必要があります。そのため、できる限り UTF-8 を使用してコンテンツを配布してください。そうしないと、インターネットの長老たちに悩まされることになります。:)
文字エンコーディング名の意味に関する最も信頼できるリファレンスは、IANA レジストリのCharacter Setsです。
Windows-1252 は、一般に Windows Latin 1 または Windows West European などとして知られています。これは、文字エンコーディングとして ISO-8859-1 とも呼ばれる ISO Latin 1 とは異なるため、コード範囲 0x80 から 0x9F は、ISO-8859-1 (いわゆる C1 コントロール) の制御文字用に予約されています。 -1252 では、印刷可能な文字 (ほとんどが句読点) に割り当てられているコードもあれば、未定義のままになっているコードもあります。
ANSI は、ここでは誤称です。Microsoft はかつて Windows-1252 を標準として採用するために ANSI (American National Standards Institute) に提出しました。提案は拒否されましたが、Microsoft はまだコードを「ANSI」と呼んでいます。さらに混乱させるために、さまざまなエンコーディングに「ANSI」を使用する場合があります(基本的に、Windows インストールの「ネイティブ 8 ビット エンコーディング」)。
Web コンテキストでは、ISO-8859-1 を宣言すると、Windows-1252 を宣言したものと見なされます。その理由は、C1 コントロールが Web 上で使用されていない、または有用ではないためです。一方、追加された文字は、ISO-8859-1 と誤ってラベル付けされたページでも使用されることがよくあります。したがって、実際には、どちらを宣言しても問題ありません。
ISO-8859-1 と宣言されていれば、実際にデータを ISO-8859-1 として解釈するブラウザがまだいくつかあるかもしれませんが、それらは非常にまれであるに違いありません (最後に見たのは約 10 年前のバージョンの Opera でした)。
どのような問題に遭遇したかについては説明しません。問題の最も一般的な原因は、データが実際には UTF-8 でエンコードされているが、ISO-8859-1 (または Windows-1252) として宣言されていること、またはその逆であることです。これは、サーバーが文字エンコーディングを宣言するヘッダーを強制しContent-Type、オーサリング環境で処理できない (またはその方法がわからない)場合、Web ページの作成者にとって実際の問題になります。