以UTF-8格式保存所有源代碼文件是否有缺點？

如果這是相關的（它很可能），它們是PHP源代碼文件。以UTF-8格式保存所有源代碼文件是否有缺點？

來源

2011-04-05 julien_c

稍微offtopic - 任何嚴重的項目應存儲的所有數據（包括UI文本）在一些數據庫，而不是在源代碼文件中有硬編碼。如果你遵循這一點，那麼只有代碼註釋可能需要UTF8。 – binaryLV 2011-04-05 14:20:20

哼...爲什麼呢？ – 2011-04-05 16:13:32

用於本地化。即使不需要本地化，也可能在將來。 – binaryLV 2011-04-06 06:11:50

有幾個陷阱，以照顧：

PHP不知道BOM字符，某些編輯器或集成開發環境喜歡把在UTF-8文件最開始的。這個字符表示文件是UTF-8，但它不是必需的，而且它是不可見的。這可能會導致處理HTTP標頭的函數發出「標頭已發出」警告，因爲如果PHP發現它，則會向瀏覽器輸出BOM，並且這會阻止您發送任何標頭。確保你的文本編輯器有一個UTF-8（無BOM）編碼;如果你不確定，只需做測試。如果<?php header('Content-Type: text/html') ?>在其他空文件的開始處不會觸發警告，那麼您沒有問題。
默認的字符串函數不支持多字節編碼。這意味着strlen確實返回字符串中的字節數，而不是實際的字符數。直到用substr這樣的函數開始拼接非ASCII字符的字符串時，這並沒有太大的問題：當你這樣做時，傳遞給它的索引是指字節索引而不是字符索引，這會導致腳本中斷兩個非ASCII字符。例如，echo substr("é", 0, 1)將返回無效的UTF-8字符，因爲在UTF-8中，é實際上需要兩個字節，substr將只返回第一個字符。（解決方案是使用mb_ string functions，它知道多字節編碼。）
您必須確保您的數據源（如外部文本文件或數據庫）也會返回UTF-8字符串，因爲PHP不進行自動轉換。爲此，您可以使用特定於實現的方法（例如，MySQL有一個特殊的查詢，可以指定您希望得到結果的編碼：SET CHARACTER SET UTF8或沿着這些行的內容），或者如果找不到更好的方法，mb_convert_encoding或iconv會將一個字符串轉換爲另一種編碼。

來源

2011-04-05 14:03:49 zneak

很好的答案。只是想補充說，字符串函數有「多字節替換」，例如'mb_strlen（）'和'mb_substr（）'。 – binaryLV 2011-04-05 14:06:34

+1打字速度不錯:)（還有很好的回答）。我只是編輯我的答案，當我看到你的答案時，添加關於BOM和'mb_ *'函數的詳細信息:)。 – Slava 2011-04-05 14:16:34

如果您使用的是e.g字符串值的任何特殊字符，尺寸有點大了，但不應該的問題。

不過，我的建議是，始終保持默認格式。我花了那麼多小時，因爲格式保存和所有字符都發生了錯誤。

從技術角度來看，沒有什麼區別！

來源

2011-04-05 13:55:58 Stefan

由於編輯器和編輯器的默認設置不同（其中一些將其從環境中拉出，而環境又有所不同）。將它作爲默認值是一個非常糟糕的主意。最好選擇一個編碼，然後確保一切都使用它。 – Quentin 2011-04-05 14:06:28

-1

非常相關的，PHP解析器可以開始輸出虛假的人物，像一個時髦的unside向下的問號。只要堅持規範，就更好。

來源

2011-04-05 14:02:07

-1，即使在PHP中，UTF-8也應該是常態。處理字符串時只需要使用多字節感知函數，以避免時髦的問號字符。 – zneak 2011-04-05 14:05:10

UTF-8是常態。 UTF-16（對亞洲更好），UTF-32（Err，no），ISO-8859（Legacy），ASCII（有限）和專有資料。 – Quentin 2011-04-05 14:05:17

我可以問爲什麼我已被標記。我的回答是真實的，繼續並用Unicode編碼您的PHP文檔，您將不會得到任何輸出，這將驗證我的聲明。除此之外，除非用戶更改了設置，否則ANSI在所有文本編輯器中都是正常的，這與C＃/ C++/VB/PHP/JS的版本是一致的，所以更多。 – 2011-04-05 14:31:47

實際上通常建議您將所有源保存爲UTF8。使用拉丁字符的普通代碼的大小並不重要，但可以防止任何特殊字符的故障。

來源

2011-04-05 14:03:24 Slava

以UTF-8格式保存所有源代碼文件是否有缺點？

回答

相關問題