web-dev-qa-db-ja.com

WordPressのファイルエンコーディングとは何ですか？

私はWordPressファイルがBOMなしでUNIXの行末とUTF-8を使うことに気づきました。これは使用すべき標準ですか？他に注意することはありますか？

FilezillaがMacintoshの行末ファイルをWindowsまたはLinuxサーバーに正しく転送できないことに気付きました。改行コードがありません。そして時々それらは異なった構成と倍増する。できればそれを避けたいのですが。

customizationencodingcoding-standards
2
Paul

UNIXの行末（\n）とUTF-8は単なる一般的なコード標準です。私が見ることができる限りでは、それらは コーディング規約 でも言及されていません。ほとんどの（すべて？）コアPHPファイルは、単なるUS-ASCIIです。ファイルの互換性をできるだけ保つために、そのパスをたどってみてください。

UTF-8を使用している場合は、PHPファイルの先頭にエンコードCookieまたはファイル変数 を含む行を追加します。

<?php # -*- coding: utf-8 -*-

多くの編集者（Emacs、Vim、Sublime、Scite）はそれを使って適切なエンコーディングを自動的に設定します。

私も見ました：

<?php # -*- coding: utf-8-unix -*-

しかし、それがどれほど互換性があるのか​​私にはわかりません。

3
fuxia

PHP自体はPHPコードセクションでDOSまたはUNIXスタイルの行末を使用するかどうかを気にしません。なぜならそれはとにかく単に空白を無視するからです。

PHPインタプリタはファイル内のバイトオーダーマークの存在を知らないため、PHPファイルの先頭にBOMがあると、PHPファイルが出力されたときにそのBOMが出力されます。実行されます。これは望ましくないことが多いため、PHPファイルには一般にBOMを含めることができません。

PHPファイルはエンコーディングを気にせず、ほとんどの場合に指定されたとおりの出力を生成するだけなので、PHPセクション以外のすべてのものは多かれ少なかれ、すべてのPHP気にします。最大限の互換性と移植性のために、BOMのないUTF-8をお勧めします。

WordPressはUnixスタイルの行末文字を優先して使用しますが、プラグインリポジトリへの送信はどちらのスタイルでもチェックされません。好きな方を使用してください。テーマリポジトリへの投稿は、行末が混在しているかどうかチェックされます。つまり、UnixとDOSの両方の形式の行末が含まれているファイルです。これは、特定のMacエディタを使用してコードをコピーして貼り付けるときによく発生します。これらの混在する行末はSubversionリポジトリで問題を引き起こす可能性があるので、テーマアップローダは混在する行末を持つファイルを拒否します。自分のSVNリポジトリに直接アクセスするプラグインの作者は、混乱したファイルをアップロードするときにSVNから同様の失敗を受け取るでしょう。

2
Otto