php - Utf-8 编码不适用于使用 php 5.5 的 utf-8 编码文档

Question

我遇到了一种非常奇怪的编码问题，我并不真正理解也从未遇到过。我在 Ubuntu 机器上使用 PHP 5.5 只是为了了解信息。

问题

我有一个简单的文件 index.php，我想在其中打印这个简单的字符串

<?php echo "übermotivierter";  ?>

在浏览器中查看时，我希望得到以下输出

�bermotivierter

这按预期工作!

为了以正确的方式显示它，我已经完成了以下步骤

1. 将我的 IDE ( Zend Studio ) 的编码更改为 UTF-8 并再次保存文件

2. 设置合适的html meta标签

   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   

3. 设置适当的 php header

   <?php header("Content-Type: text/html; charset=utf-8"); ?>
   

完成此操作后，我本以为它会以正确的方式显示，但我仍然在输出中得到这个奇怪的 �!

解决方法

为了让这个东西正确显示，我必须这样做

<?php echo utf8_encode("übermotivierter");  ?>

现在它以正确的方式显示。

我的问题

我真的不明白为什么我必须使用 utf8_encode 当我的文档已经编码并保存为 utf-8 时。这对我来说没有任何意义。对此有何解释？

Answer 1

使用 Git 2.18+(2018 年第 2 季度)，您可能不需要任何第三方技巧来将 repo 内容转换为 UTF-8，因为新的“checkout-encoding”属性可以询问 Git在 checkout 到工作树时将内容转换为指定的编码( checkin 时则相反)。

参见 commit e92d622、commit 541d059、commit 7a17918、commit 107642f、commit c6e4865、commit 10ecb82、commit 2f0c4a3(2018 年 4 月 15 日)、commit 66b8af3(2018 年 3 月 9 日)和 commit 13ecb46、commit a8270b0(2018 年 2 月 15 日)。
^{(由 Lars Schneider (larsxschneider) 合并到 Junio C Hamano -- gitster -- ，2018 年 5 月 8 日)}

convert: add 'working-tree-encoding' attribute

Git recognizes files encoded with ASCII or one of its supersets (e.g. UTF-8 or ISO-8859-1) as text files.
All other encodings are usually interpreted as binary and consequently built-in Git text processing tools (e.g. 'git diff') as well as most Git web front ends do not visualize the content.

Add an attribute to tell Git what encoding the user has defined for a given file. If the content is added to the index, then Git reencodes the content to a canonical UTF-8 representation. On checkout Git will reverse this operation.

如果有任何问题，您现在可以使用 commit 1ac0ce4 来跟踪使用“working-tree-encoding”属性重新编码的内容。
这对于调试编码问题很有用。

the GIT_TRACE_WORKING_TREE_ENCODING environment variable 现在提到:

Please note that using the working-tree-encoding attribute may have a number of pitfalls:

• Alternative Git implementations (e.g. JGit or libgit2) and older Git versions (as of March 2018) do not support the working-tree-encoding attribute.
  If you decide to use the working-tree-encoding attribute in your repository, then it is strongly recommended to ensure that all clients working with the repository support it.

  For example, Microsoft Visual Studio resources files (*.rc) or PowerShell script files (*.ps1) are sometimes encoded in UTF-16.
  If you declare *.ps1 as files as UTF-16 and you add foo.ps1 with a working-tree-encoding enabled Git client, then foo.ps1 will be stored as UTF-8 internally.
  A client without working-tree-encoding support will checkout foo.ps1 as UTF-8 encoded file. This will typically cause trouble for the users of this file.

  If a Git client, that does not support the working-tree-encoding attribute, adds a new file bar.ps1, then bar.ps1 will be stored "as-is" internally (in this example probably as UTF-16).
  A client with working-tree-encoding support will interpret the internal contents as UTF-8 and try to convert it to UTF-16 on checkout. That operation will fail and cause an error.

• Reencoding content requires resources that might slow down certain Git operations (e.g 'git checkout' or 'git add').

Use the working-tree-encoding attribute only if you cannot store a file in UTF-8 encoding and if you want Git to be able to process the content as text.

---

As an example, use the following attributes if your '*.ps1' files are UTF-16 encoded with byte order mark (BOM) and you want Git to perform automatic line ending conversion based on your platform.

*.ps1     text working-tree-encoding=UTF-16

Use the following attributes if your '*.ps1' files are UTF-16 little endian encoded without BOM and you want Git to use Windows line endings in the working directory.
Please note, it is highly recommended to explicitly define the line endings with eol if the working-tree-encoding attribute is used to avoid ambiguity.

*.ps1 text working-tree-encoding=UTF-16LE eol=CRLF