blocks|key|1123185|text|您的MySQL连接编码是否正确地设置为UTF-8？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1123186|有关更多细节，请查看字符集()和编码()。|1123187|entityMap|0|LINK|mutability|MUTABLE|url|http://php.net/manual/en/function.mysql-set-charset.php|1|http://www.php.net/manual/en/function.mysql-client-encoding.php^0|J|5|0|A|5|0|G|4|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@$9|V|A|W|1|X]|$9|Y|A|Z|1|10]]|E|$]]|$1|H|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

Is your MySQL connection encoding properly set to <code>UTF-8</code> ?

Check <a href="http://php.net/manual/en/function.mysql-set-charset.php" rel="nofollow noreferrer">mysql_set_charset()</a> and <a href="http://www.php.net/manual/en/function.mysql-client-encoding.php" rel="nofollow noreferrer">mysql_client_encoding()</a> for more details.

blocks|key|1123189|text|latin1_swedish_ci是一种排序规则，而不是字符集。因为排序规则应该与它们的字符集相匹配，所以它表明表使用的是latin1，但这并不是一个保证。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1123190|严格地说，这里的表格字符集与此无关，因为MySql可以转换输入/输出。这就是连接字符集(+connection，mysql_set_charset)的用途。但是，要使其正常工作，需要在数据库中对数据进行适当编码。首先，我将检查数据库中的字符串是否正确。最简单的方法是登录命令行，并选择其中包含非ascii字符的行。看上去还好吗？|1123191|$mystring+=+"Otivägen"+//+this+is+actually+obtained+from+database;|code-block|syntax|javascript|1123192|小心。$mystring中数据的编码现在将取决于php文件的编码。这可能与数据库中的数据相同，也可能不相同。|1123193|entityMap^0|0|H|0|1K|H|0|0|3|9|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|P|$]]

<code>latin1_swedish_ci</code> is a collation, not a charset. Since collations are supposed to match their charset, it suggests that the table is using latin1, but it's not a guarantee.

Strictly speaking, the charset of tables is irrelevant here, since MySql can convert input/output. That's what the connection charset (<code>mysql_set_charset</code>) is for. However, for that to work properly, the data needs to be encoded properly in the database. I would begin by checking that strings are correct in the database. Simplest thing is to log in on the command line and select a row which has non-ascii characters in it. Does it look OK?

<pre><code>$mystring = "Otivägen" // this is actually obtained from database;
</code></pre>

Watch out. The encoding of the data in <code>$mystring</code> will now depend on the encoding of the php file. That may or may not be the same as the data in the database.

blocks|key|2710393|text|在输出前运行查询SET+NAMES+utf8|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2710394|输出之后，可以返回并运行SET+NAMES+latin1|2710395|听着，这里,，我也有同样的问题|2710396|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1714629/mysql-latin1-utf8-convert-characters-to-their-multibyte-equivalents^0|8|E|0|C|G|0|3|3|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@]|D|@$9|Y|A|Z|1|10]]|E|$]]|$1|J|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

before output run query <code>SET NAMES utf8</code>

after output you can go back and run <code>SET NAMES latin1</code>

Look <a href="https://stackoverflow.com/questions/1714629/mysql-latin1-utf8-convert-characters-to-their-multibyte-equivalents">here,</a> I've got the same problem

blocks|key|1123518|text|看来你是“双重编码”Otiv+gen。如果Otiv+gen已经是UTF-8，则会得到这种行为，并再次对其运行utf8_encode()。示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1123519|$str+=+"Otivägen";+//+already+an+UTF-8+string
echo+utf8_encode($str);+//+outputs+OtivÃ¤gen|code-block|syntax|javascript|1123520|我不确定我们是否真正出现了“双重编码”，但这可能是由于您的编辑器中的设置所致。我的理论。假设您正在运行Aptana+Studio:您的实际字符集设置为ISO-8859-1+(在Aptana中，您可以通过右键单击一个文件并选择"properties“来检查该字符集)。若要为所有项目设置默认字符编码，请从Aptana主菜单->+General+->工作区中选择Preferences+)。如果是这样的话，您拥有$myxml的实际PHP源文件及其字符串<myxml><node>...被检测为ISO-8859-1，但是从数据库接收到的$mystring是UTF-8。然后，您的fixEncoding函数将运行$myxml子句，因为整个$myxml被看作是ISO8859-1，而不是UTF-8。这会导致对来自数据库的结果进行双重编码，这可能是造成问题的原因。|offset|length|style|CODE|1123521|在编辑器中检查实际源文件的编码，并验证它是否设置为UTF-8。或者，将固定编码/utf8+8_encode/utf8+8_decode应用或移除到$myxml中。观察结果，看看对Otiv+gen的价值需要做些什么。|1123522|entityMap^0|0|0|5O|6|68|G|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

It seems you are "double encoding" Otivägen. You get this behaviour if Otivägen already is UTF-8, and run utf8_encode() on it again. Example:

<pre><code>$str = "Otivägen"; // already an UTF-8 string
echo utf8_encode($str); // outputs OtivÃ¤gen
</code></pre>

I'm not sure we're the actual "double encoding" occurs, but it may be due to settings in your editor. My theory. Lets say you are running Aptana Studio: Your actual character set is set to ISO-8859-1 (in Aptana, you can check this by right clicking on a file and choose "properties". To set default character encoding for all projects, choose Preferences from Aptana main menu -> General -> workspace). If that's the case, the actual PHP source file where you have <code>$myxml</code> and its string <code>&lt;myxml&gt;&lt;node&gt;...</code> is detected to be ISO-8859-1, but $mystring received from the database is UTF-8. Your fixEncoding function would then run the else clause, since the $myxml as a whole is seen as ISO-8859-1 and not UTF-8. This results in double encoding the results from the database, and may be the cause to your problem. 

Check the encoding of your actual source file in your editor, and verify that it is set to UTF-8. Alternatively, experiment with applying or removing fixEncoding/utf8_encode/utf8_decode to $myxml. Observe the results and see what needs to be done to the value Otivägen right.

blocks|key|1185742|text|我认为你做的一切都是正确的，除了你的终端是拉丁文-1。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1185743|用于C3+A4的UTF-8序列，如果显示为拉丁文-1，则为圣保罗.|1185744|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think you did everything correctly, except that your terminal is in Latin-1.

The UTF-8 sequence for ä is C3 A4, which is Ã¤ if displayed as Latin-1.

blocks|key|1185770|text|哦，天哪。UTF8问题可能是一个真正的痛苦，当某些事情为您重新编码时，它们几乎是不可能解决的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1185771|您确实需要从一端开始，并确保每个进程都是UTF8。这将删除过程中的东西，从解释错误的数据和为您“转换”它。但值得注意的是，它还可以让您更容易地发现有错误编码的文本(是的，我遇到了这个问题)。|1185772|而且，如果表中的UTF8数据没有设置为UTF8，而且可能是错误编码的，则需要在数据重新编码之后最后再执行这些表。否则，您将无法挽回地损坏数据。我也有过这个问题。|1185773|第一步：|1185774|检查您的终端是否符合UTF8。侏儒终端机是。克伦特是。ETerm不是。|unordered-list-item|1185775|检查你的朗设置在你的外壳。它可能应该有..UTF+8在它的值的末尾。|1185776|检查vim是否正确地选择了UTF8设置。您可以向:set+encoding查询|offset|length|style|CODE|1185777|这意味着您的文件将在UTF8中进行编辑。|1185778|现在我们检查MySQL。|1185779|在MySQL+CLI中，执行show+variables+like+'character_set%25';。结果可能是：|1185780|%2B--------------------------%2B----------------------------%2B
%7C+Variable_name++++++++++++%7C+Value++++++++++++++++++++++%7C
%2B--------------------------%2B----------------------------%2B
%7C+character_set_client+++++%7C+latin1+++++++++++++++++++++%7C+
%7C+character_set_connection+%7C+latin1+++++++++++++++++++++%7C+
%7C+character_set_database+++%7C+latin1+++++++++++++++++++++%7C+
%7C+character_set_filesystem+%7C+binary+++++++++++++++++++++%7C+
%7C+character_set_results++++%7C+latin1+++++++++++++++++++++%7C+
%7C+character_set_server+++++%7C+latin1+++++++++++++++++++++%7C+
%7C+character_set_system+++++%7C+utf8+++++++++++++++++++++++%7C+
%7C+character_sets_dir+++++++%7C+/usr/share/mysql/charsets/+%7C+
%2B--------------------------%2B----------------------------%2B|code-block|syntax|javascript|1185781|您的目标是将所有这些latin1值(或您看到的任何东西)更改为utf8。|1185782|set+names+utf8;将更改其中的大多数，您可能需要在数据库中的每一个新连接中都这样做。这是我在上一次申请中必须采用的解决方案。要更改的其他设置在my.cnf文件中，为此，我需要将您引向文献资料。你不太可能需要把它们全部设置好。|1185783|我看到您已经设置了输出头，所以这很好。|1185784|现在，您可以查看数据库中的数据，并了解其“错误”的原因。|1185785|entityMap|0|LINK|mutability|MUTABLE|url|http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html^0|0|0|0|0|0|0|O|D|0|0|0|E|11|0|0|A|6|V|4|0|0|F|2P|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1M|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1N|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|1O|8|@]|9|@]|A|$]]|$1|M|3|N|5|J|7|1P|8|@$O|1Q|P|1R|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1S|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1T|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1U|8|@$O|1V|P|1W|Q|R]]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|1X|8|@]|9|@]|A|$11|12]]|$1|13|3|14|5|6|7|1Y|8|@$O|1Z|P|20|Q|R]|$O|21|P|22|Q|R]]|9|@]|A|$]]|$1|15|3|16|5|6|7|23|8|@$O|24|P|25|Q|R]]|9|@$O|26|P|27|1|28]]|A|$]]|$1|17|3|18|5|6|7|29|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]]|1C|$1D|$5|1E|1F|1G|A|$1H|1I]]]]

Oh boy. UTF8 issues can be a real pain and they get almost impossible to solve when something is doing re-encodings for you.

You really need to start at one end and make sure every process is UTF8. That will remove things in the process from interpreting the data wrong and 'converting' it for you. But significantly, it will also let you much more easily spot when something has already mis-encoded text for you (yes, I've had that problem).

And if you have UTF8 data in tables that aren't set to UTF8 and might be mis-encoded, you need to do the tables last, after the data has been re-encoded. Otherwise you will damage your data irretrievably. I've had that problem, too.

First steps:

<ul>
<li>Check your terminal is UTF8 compliant. Gnome-terminal is. Kterm is. ETerm is not.</li>
<li>Check your LANG setting in your shell. It should probably have .UTF-8 on the end of it's value.</li>
<li>Check that vim is picking up the UTF8 setting correctly. You can check with <code>:set encoding</code></li>
</ul>

This will mean that your files will be edited in UTF8.

Now we check MySQL.

In the MySQL CLI, do <code>show variables like 'character_set%';</code>. The results will probably be something like:

<pre><code>+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 | 
| character_set_connection | latin1 | 
| character_set_database | latin1 | 
| character_set_filesystem | binary | 
| character_set_results | latin1 | 
| character_set_server | latin1 | 
| character_set_system | utf8 | 
| character_sets_dir | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+
</code></pre>

What you're aiming for is to change all those <code>latin1</code> values (or whatever you're seeing) to <code>utf8</code>.

<code>set names utf8;</code> will change most of them and you might need to do that with every new connection in your database. This was the solution I had to adopt in a previous application. The other settings to change are in the my.cnf file for which I need to direct you to <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" rel="nofollow noreferrer">the documentation</a>. It is unlikely you will need to set them all.

I see you're already setting the output headers, so that's good.

Now you can look at the data from the database and see why it's "wrong".

I am having great problems solving this one:

I have a mysql database encoding latin1_swedish_ci and a table that stores names and addresses.

I am trying to output a UTF-8 XML file, but I am having problems with the following string:

<code>Otivägen</code> it is being outputted as <code>OtivÃ¤gen</code> when i vim the file. Also when opened it IE i get 

"<code>An invalid character was found in text content. Error processing resource</code>"

I have the following code:

<pre><code>function fixEncoding($in_str)
{
 $cur_encoding = mb_detect_encoding($in_str) ;
 if($cur_encoding == "UTF-8" &amp;&amp; mb_check_encoding($in_str,"UTF-8"))
 return $in_str;
 else
 return utf8_encode($in_str);
}

header("Content-type: text/plain;charset=utf-8");
$mystring = "Otivägen" // this is actually obtained from database;

$myxml = "&lt;myxml&gt;
....
 &lt;node&gt;".$mystring."&lt;/node&gt;
....
&lt;/myxml&gt;
";
$myxml = fixEncoding($myxml);
</code></pre>

The actual XML output is below:

<pre><code>&lt;?xml version="1.0" encoding="UTF-8" ?&gt;
&lt;myxml&gt;
 ....
 &lt;node&gt;Otivägen&lt;/node&gt;
 ....
&lt;/myxml&gt;
</code></pre>

Any ideas how I can output the file so in vim the file reads <code>Otivägen</code> and not <code>OtivÃ¤gen</code>?

EDIT:

I did <code>mysql_client_encoding()</code> and got <code>latin1</code> 
I then did <code>mysql_set_charset()</code> 
and again ran <code>mysql_client_encoding()</code> and got utf8, but still the same outputting issues.

Edit 2

I have logged into the command line and run the query <code>SELECT address1 FROM address WHERE id = 1000;</code>

<pre><code>SELECT address1 FROM address WHERE id = 1000;
Current database: ftpuser_db

+-------------+
| address1 |
+-------------+
| Otivägen 32 |
+-------------+
1 row in set (0.06 sec)
</code></pre>

Thanks in advance!

UTF-8, PHP and XML Mysql

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在解决这个问题上有很大的困难：我有一个编码latin1_swedish_ci的mysql数据库和一个存储名称和地址的表。我正在尝试输出一个UTF-8 XML文件，但是下面的字符串有问题：Otivägen --当我访问该文件时，它被输出为OtivÃ¤gen。也是当我打开它的时候我得到了"An invalid chara...

问UTF-8，PHP和XML Mysql
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问UTF-8，PHP和XML MysqlEN