目次
UTF-8
番外:Notepad++的字符编码测试
ホームページ 開発ツール Notepad Windows メモ帳のオプションの文字エンコーディングについて

Windows メモ帳のオプションの文字エンコーディングについて

Feb 18, 2021 pm 05:37 PM
unicode windows ノート

notepad の次のチュートリアル コラムでは、Windows メモ帳のオプションの文字エンコーディングについて紹介します。困っている友人の役に立てば幸いです。

Windows メモ帳のオプションの文字エンコーディングについて

Windows メモ帳のオプションの文字エンコーディングの簡単な分析

この記事では、Windows メモ帳の動作をテストするだけです。

Windows メモ帳のオプションの文字エンコーディングについて

▲ Windows メモ帳のエンコードには、ANSI、Unicode、Unicode ビッグ エンディアン、および UTF-8 が含まれます。

警告

この記事は、広く使用されているソフトウェアの技術的事実を説明するだけであり、作成者がそのソフトウェアの使用を支持または反対することを意味するものではありません。

実際、著者は、コンピューター プログラム コードを扱う際には、いかなる場合でも Windows メモ帳を使用しないことをお勧めします。
この記事は、64 ビット Windows 7 の簡体字中国語バージョンの特定のインスタンスでのみ検証されており、参照のみを目的としています。他の同一または異なるシステム上で一貫した結果を再現できるという保証はありません。

この記事では、Unicode の

エンコーディングバイト シリアル化 を厳密に区別します。 Unicode の
Encoding は、数値 (通常は 16 進数で記述される) を使用して文字を 1 対 1 で表現する作業のみを指します。この数値の範囲は Unicode 標準によってのみ制限されており、コンピューターとは関係ありません。 Unicode の
バイト シリアル化 は、コンピュータ メモリに書き込めるようにするために、Unicode 標準範囲内の数値を N バイトに表現する作業を指します。

テスト ケース

テスト ケースは「锟斤[改行]a[改行]」です。 (Kun Jin Kao は信念です。)

すべての文字の GBK および Unicode エンコードは次のとおりです:

    锟GBK=
  • EFBF Unicode=U 951F
  • 金GBK=
  • BDEF Unicode=U 65A4
  • copyGBK=
  • BFBD Unicode= U 62F7
次の ASCII 文字の GBK および Unicode エンコードは ASCII と一致しています:

a=

0x61 CR= 0x0D LF=0x0A (Windows では 1 つの改行文字が 2 文字を占めます: CR LF)

ANSI

簡体字中国語システムでは、ANSI は中華人民共和国の国家標準によって定義された GBK エンコードです。中国。

Windows メモ帳が ANSI を使用してこのファイルを保存した結果は次のとおりです。

EF BF  BD EF  BF BD  0D  0A  61  0D  0A
-----  -----  -----  --  --  --  --  --
ログイン後にコピー
単純に GBK エンコードを使用してすべての文字を保存します。最上位ビットが 1 ではない 1 バイトで ASCII と同等、それ以外の場合は 2 バイト。

ここでバイトオーダー(エンディアン)の問題に注意する必要があります

[注A]。ここでのバイトオーダーは big-endian であることがわかります。

ただし、「ビッグ エンディアンが最初の GBK」を特に強調する必要はありません。GB2312 以降、標準ではストレージ方式がビッグ エンディアン ファーストであることが規定されているためです。

[注 B]。以降の GBK は GB18030-2000 と下位互換性があります。

ANSI の問題点は、システムに依存することです。他の言語システムの ANSI は GBK ではないため、GBK で開かれたファイルは必然的に文字化けします。そしてGBK自体の文字セットが小さすぎます。

(決して「中国語しか使わない」とは言わないでください。Unicode の記号がなければ、インターネット上の絵文字は入力できません。)

Unicode シリーズ

Windows のメモ帳で「Unicode」と表示されたもの、 「Unicode ビッグ エンディアン」と UTF-8 はすべて、同じ Unicode

encoding の異なる バイト シリアル化格納方法です。

UTF-16 と BOM

ここでの Unicode は、UTF-16

[注 C] を指します。 UTF-16 は非常に単純かつ粗雑なシリアル化方法です。ほとんどの Unicode 文字は U 0000 ~ U FFFF [Note D] の範囲にあり、各文字は 2 バイトを使用し、Unicode エンコーディングの元の値を書き込みます。ディスクに。

ASCII 文字は、0x00 の上位 8 ビットを格納するために 2 倍のスペースを浪費する必要があることに注意してください。0 の上位 8 ビットが省略されると、解析中にハイフネーションを行うための他の根拠がなくなるからです。

UTF-16 には、ビッグ エンディアンとリトル エンディアンの問題があります。UTF-16 では、バイトが最初にビッグ エンディアンであるかリトル エンディアンであるかが指定されていません。ただし、UTF-16 にはバイト順序を示す情報が含まれていないため、どの解析が文字化けしていないかを手動で確認することはできません...

Unicode が提供する解決策は、

ゼロ幅の解読不可能な文字列を変換することです。文字スペース文字 (U FEFF ZERO WIDTH NO-BREAK SPACE) は UTF-16 でシリアル化され、ファイルの先頭に詰められます。このように、UTF-16 パーサーはファイルの最初の 2 バイトを読み取ります。FE FF の場合はビッグエンドが最初であることを意味し、FF FE はリトルエンドが最初であることを意味します。

この詰め込まれたものをBOM(Byte Order Mark、バイトオーダーマーク)といいます。

ゼロ幅のハイフンなしのスペース文字 は、さまざまな状況で単語制限を破るための有効な文字としてもよく使用されることに注意してください。 SegmentFault の Q&A とコメントが含まれます。

メモ帳の「Unicode」と「Unicode ビッグ エンディアン」

「Unicode」だけを書くことは、まったく記憶方法の完全な表現ではありません。これには、

encoding のみが含まれており、バイト シリアル化は含まれていないためです。

M$出现这种错误,我一点都不觉得奇怪。死记结论就可以了:Windows Notepad的“Unicode”就是UTF-16

Windows Notepad使用“Unicode” = 小端在先的UTF-16,存储这个文件的结果如下:

 FF FE 1F 95 A4 65 F7 62 0D 00 0A 00 61 00 0D 00 0A 00
 -BOM- ----- ----- ----- ----- ----- ----- ----- ----- 
U+FEFF  951F  65A4  62F7  000D  000A  0061  000D  000A <p>Windows Notepad使用<strong>“Unicode big endian” = 大端在先的UTF-16</strong>,存储这个文件的结果如下:</p><pre class="brush:php;toolbar:false"> FE FF 95 1F 65 A4 62 F7 00 0D 00 0A 00 61 00 0D 00 0A
 -BOM- ----- ----- ----- ----- ----- ----- ----- ----- 
U+FEFF  951F  65A4  62F7  000D  000A  0061  000D  000A <h3 id="UTF">UTF-8</h3><p>UTF-8是一种用1~4个字节表示1个Unicode字符的<strong>变长的</strong>字节序列化方法。具体的实现细节看这篇文章。UTF-8的好处在于:</p><ol>
<li>无论是IETF的推荐,还是实际业界的执行,UTF-8都是互联网的标准。</li>
<li>向下兼容,ASCII字符UTF-8序列化后仍是原样,任何ASCII文件也是有效的UTF-8文件。</li>
<li>没有字节序问题。UTF-8的字节序是由RFC3629定死的。</li>
</ol><p>Windows Notepad使用UTF-8存储这个文件的结果如下:</p><pre class="brush:php;toolbar:false"> EF BB BF  E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A
 --BOM---  --------  --------  --------  --   --   --   --   --
U+ FEFF      951F      65A4      62F7   000D 000A 0061 000D 000A <p>注意UTF-8前边仍然塞进去了<code>U+FEFF</code>按照UTF-8序列化的结果<code>EF BB BF</code>,作为前边提到过的<strong>BOM</strong>字节顺序标记。<strong>Windows Notepad存储的UTF-8,是带有BOM标记的UTF-8</strong>。</p><p>但是如果仅仅对于UTF-8而言,字节序是没有意义的。因为UTF-8的字节序被规范写死,<code>U+FEFF</code>编码后必然得到<code>EF BB FF</code>,得不出其他的。没有二义性,BOM就失去了原本的意义。也许只有区别UTF-8文件和UTF-16文件的用处……</p><p>如何对待UTF-8文件的BOM,RFC3629的第6章有详细的规定,不加详述。</p><p>值得一提的是,BOM我想很多PHP程序员都经历过并且恨之入骨——PHP不认识文件中的BOM头并会将其作为HTTP Response的正文送出。这甚至在无缓冲的情况下,会导致<code>header()</code>等必须在Response开始前执行的函数直接失效。</p><p>所以PHP程序员总是会喜欢<strong>UTF-8 without BOM</strong>的编码方式——这基本也就宣布了Windows下的PHP开发,Windows Notepad完全的淘汰出局,哪怕是任何一星半点代码的临时修改。</p><h2 id="番外-Notepad-的字符编码测试">番外:Notepad++的字符编码测试</h2><p>ANSI没有区别,但Notepad++支持选择多国编码的不同ANSI编码方式(类似浏览器里选编码),可以轻松生成或读取Shift-JIS等其他字符集的文件。适合用于对付日文老游戏的<code>README</code>等文档。</p><p>UCS-2 Big Endian、UCS-2 Little Endian和前边UTF-16的两个例子一致。注意UTF-16的文件不提供“无BOM”的存储方法(提供了就坏了)。</p><p>UTF-8仍然代表“带有BOM标记的UTF-8”。但同时提供PHP程序员最爱的UTF-8 without BOM,就像:</p><pre class="brush:php;toolbar:false"> E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A
 --------  --------  --------  --   --   --   --   --
U+ 951F      65A4      62F7   000D 000A 0061 000D 000A <p>Simple and clean.</p><blockquote><p><strong>注解</strong><br><code>[注A]</code> 对于一个双(多)字节的数,一定会按8位截断为1字节后写盘。那么写盘时先写最低8位还是先写最高8位,就是所谓的“字节序”(Endian)问题。例如,数<code>0x01020304</code>写盘时,是先写最低8位的<code>04 03 02 01</code>,还是先写最高8位的<code>01 02 03 04</code>?<br>
  先写低8位的叫做小端在先(little-endian),先写高8位的叫做大端在先(big-endian)。实际采用何种字节序受系统环境、标准规范和软件实际编写的多方面控制,不一概而论。<br><code>[注B]</code> 字节序如果我没弄错,是GB2312采用的EUC字符编码方法控制的。<br><code>[注C]</code> 本文并不严格区分<strong>UTF-16</strong>与<strong>UCS-2</strong>。<br><code>[注D]</code> Unicode的最大值实际上达到了U+10FFFF,超出了两个字节能够存储的限度。<br>
  但Unicode由于历史原因,留下了U+D800~U+DFFF这一段永久保留不用的空缺区域。<br>
  因此对U+10000及以上的字符,UTF-16借助了这部分空缺区域,对这些编码超大的字符打破2字节16位的惯例,特别的用4字节32位去表示之。<br>
  这一部分编码值太大的字符,超出了GBK的字符集范围,因此本文将<strong>完全忽略</strong>。如有机会再进一步测试。</p></blockquote>
ログイン後にコピー

以上がWindows メモ帳のオプションの文字エンコーディングについての詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

WindowsやLinuxファイルを同期するときに、Compare Beyond Compareがケース感度に失敗した場合はどうすればよいですか? WindowsやLinuxファイルを同期するときに、Compare Beyond Compareがケース感度に失敗した場合はどうすればよいですか? Apr 01, 2025 am 08:06 AM

compareを超えてファイルを比較して同期する問題:それ以降を使用する場合のケース感度障害...

マルチスレッドをC言語で実装する4つの方法 マルチスレッドをC言語で実装する4つの方法 Apr 03, 2025 pm 03:00 PM

言語のマルチスレッドは、プログラムの効率を大幅に改善できます。 C言語でマルチスレッドを実装する4つの主な方法があります。独立したプロセスを作成します。独立して実行される複数のプロセスを作成します。各プロセスには独自のメモリスペースがあります。擬似マルチスレッド:同じメモリ空間を共有して交互に実行するプロセスで複数の実行ストリームを作成します。マルチスレッドライブラリ:pthreadsなどのマルチスレッドライブラリを使用して、スレッドを作成および管理し、リッチスレッド操作機能を提供します。 Coroutine:タスクを小さなサブタスクに分割し、順番に実行する軽量のマルチスレッド実装。

ノード環境で403エラーを返すサードパーティのインターフェイスを回避する方法は? ノード環境で403エラーを返すサードパーティのインターフェイスを回避する方法は? Apr 01, 2025 pm 02:03 PM

ノード環境で403エラーを返すサードパーティのインターフェイスを回避する方法。 node.jsを使用してサードパーティのWebサイトインターフェイスを呼び出すと、403エラーを返す問題が発生することがあります。 �...

Windowsの下のpython .whlファイルをどこからダウンロードしますか? Windowsの下のpython .whlファイルをどこからダウンロードしますか? Apr 01, 2025 pm 08:18 PM

Pythonバイナリライブラリ(.whl)のダウンロードメソッドは、Windowsシステムに特定のライブラリをインストールする際に多くのPython開発者が遭遇する困難を調査します。一般的な解決策...

なぜ私のコードはAPIによってデータを返しているのですか?この問題を解決する方法は? なぜ私のコードはAPIによってデータを返しているのですか?この問題を解決する方法は? Apr 01, 2025 pm 08:09 PM

なぜ私のコードはAPIによってデータを返しているのですか?プログラミングでは、APIが呼び出すときにヌル値を返すという問題に遭遇することがよくあります。

Windowsシステムログを効率的に読み取り、ここ数日から情報のみを取得する方法は? Windowsシステムログを効率的に読み取り、ここ数日から情報のみを取得する方法は? Apr 01, 2025 pm 11:21 PM

Windowsシステムログの効率的な読み取り:Pythonを使用してWindowsシステムログファイル(.EVTX)を処理する場合、EVTXファイルを逆転させます。

PSの負荷速度をスピードアップする方法は? PSの負荷速度をスピードアップする方法は? Apr 06, 2025 pm 06:27 PM

Slow Photoshopの起動の問題を解決するには、次のような多面的なアプローチが必要です。ハードウェアのアップグレード(メモリ、ソリッドステートドライブ、CPU)。時代遅れまたは互換性のないプラグインのアンインストール。システムのゴミと過剰な背景プログラムを定期的にクリーンアップします。無関係なプログラムを慎重に閉鎖する。起動中に多数のファイルを開くことを避けます。

See all articles