php - すべてのソースコードファイルをUTF-8に保存することの欠点はありますか？

Question

それが関連している場合（それは非常によくあるかもしれません）、それらはPHPソースコードファイルです。

Answer 1

世話をするいくつかの落とし穴があります：

1. PHPは、特定のエディターまたはIDEがUTF-8ファイルの先頭に配置することを好むBOM文字を認識しません。この文字は、ファイルがUTF-8であることを示しますが、必須ではなく、非表示です。これにより、HTTPヘッダーを処理する関数から「ヘッダーが既に送信されました」という警告が発生する可能性があります。これは、PHPがBOMを検出すると、ブラウザーにBOMを出力し、ヘッダーを送信できなくなるためです。テキストエディタにUTF-8（BOMなし）エンコーディングがあることを確認してください。よくわからない場合は、単にテストを行ってください。それ以外の場合<?php header('Content-Type: text/html') ?>は空のファイルの先頭で警告がトリガーされない場合は、問題ありません。
2. デフォルトの文字列関数は、マルチバイトエンコーディングに対応していません。これはstrlen、実際の文字数ではなく、文字列のバイト数を実際に返すことを意味します。非ASCII文字の文字列を次のような関数でスプライスし始めるまで、これはそれほど問題にはなりませんsubstr。その場合、渡すインデックスは文字インデックスではなくバイトインデックスを参照します。これにより、スクリプトが非ASCII文字で破損する可能性があります。 -2つのASCII文字。たとえば、UTF-8では実際には2バイトを使用し、substrは最初のバイトのみを返すecho substr("é", 0, 1)ため、は無効なUTF-8文字を返します。é（解決策は、マルチバイトエンコーディングを認識するmb_文字列関数を使用することです。）
3. PHPは自動マジック変換を行わないため、データソース（外部テキストファイルやデータベースなど）もUTF-8文字列を返すようにする必要があります。そのために、実装固有の手段を使用することができます（たとえば、MySQLには、結果を期待するエンコーディングを指定できる特別なクエリがあります：SET CHARACTER SET UTF8またはこれらの線に沿った何か）、またはより良い方法が見つからない場合は、mb_convert_encodingまたはiconv、ある文字列を別のエンコーディングに変換します。

Answer 2

通常、すべてのソースをUTF8に保持することをお勧めします。ラテン文字を使用する通常のコードのサイズはまったく関係ありませんが、特殊文字を使用するグリッチを防ぐことができます。

Answer 3

文字列値などで特別な文字を使用している場合、サイズは少し大きくなりますが、それは問題ではありません。

それにもかかわらず、私の提案は、常にデフォルトの形式のままにすることです。フォーマットの保存にエラーがあり、すべての文字が変更されたため、私は非常に多くの時間を費やしました。

技術的な点では、違いはありません。

Answer 4

非常に関連性が高いのは、PHPパーサーが、ファンキーな裏返しの質問マークのような偽の文字を出力し始める可能性があることです。ただ規範に固執し、非常に好まれます。