我们有一些来自意大利的数据，并在波兰的服务器上显示。我们正在获得一些字符替换的实例。具体而言，à（带有坟墓的小写字母A）将被替换为ŕ（具有锐角的小写字母R）。我们可以看到00E0中的à是CP1252 Western European character set，而CP1250东欧字符集中的ŕ是相同的值，因此我们知道这是字符集问题。
该页面由使用JSP的Websphere应用服务器提供服务。我有一个实验页面，我可以重现问题，并解决它，但不是以可接受的方式。
如果我在JSP中设置它：
response.setContentType("text/html;charset=windows-1250");
重现问题并显示带有急性的R.
要解决问题，我在浏览器上将编码更改为IE中的"Western European"或Chrome中的"Western Windows-1252"。
所以这自然会让我相信，如果我在内容类型中设置“windows-1252”，它将解决问题，但事实并非如此。当我这样做时，角色会显示为问号。
我玩过response.setContentType，response.setCharacterEncoding，response.setLocale，<meta http-equiv>，<meta charset>的各种组合，大部分内容都会产生？展示。只在内容类型上设置1250然后更改浏览器本身的编码似乎可以解决问题。
有什么建议吗？
由于
答案 0 :(得分：0)
首先，每个源必须带有它已编码的字符集（即你必须知道它），否则你不会知道在呈现该源时使用什么字符集，你的问题将出现下一个数据源 其次，如果可以的话，你应该让你的消息来源转到utf-8，并让这些提供商重写他们的内容。
由于为所有源提供了一个通用字符集是最佳解决方案（如果你不能让它们进行转换，那么使用utf-8是目前最兼容/标准导向的方式） ，通过了解源编码，您可以尝试使用转换器将数据内容从源字符集转换为您的字符集（我没有使用任何，所以我不能给你任何建议）。
最后，两个笔记：
1）没有办法在单个Web应用程序中显示两个使用不同字符集的内容（在一个网页中都没有），因为 - 就像您已经找到的那样 - 您一次只能使用一种编码;
2）如果您的数据内容严格面向网络，您可以要求您的来源使用html实体（但请记住，如果您将以PDF格式呈现该内容，这可能会成为一个问题。）