<p>The login page in my Tapestry application has a property in which the password the user types in is stored, which is then compared against the value from the database. If the user enters a password with multi-byte characters, such as:</p>

<pre><code>áéíóú
</code></pre>

<p>...an inspection of the return value of getPassword() (the abstract method for the corresponding property) gives:</p>

<pre><code>Ã¡Ã©Ã­Ã³Ãº
</code></pre>

<p>Clearly, that's not encoded properly. Yet Firebug reports that the page is served up in UTF-8, so presumably the form submission request would also be encoded in UTF-8. Inspecting the value as it comes from the database produces the correct string, so it wouldn't appear to be an OS or IDE encoding issue. I have not overridden Tapestry's default value for org.apache.tapestry.output-encoding in the .application file, and the Tapestry 4 <a href="http://tapestry.apache.org/tapestry4/UsersGuide/configuration.html#configuration.properties" rel="nofollow noreferrer">documentation</a> indicates that the default value for the property is UTF-8.</p>

<p>So why does Tapestry appear to botch the encoding when setting the property?</p>

<p>Relevant code follows:</p>

<h2>Login.html</h2>

<pre class="lang-html prettyprint-override"><code>&lt;html jwcid="@Shell" doctype='html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"' ...&gt;
    &lt;body jwcid="@Body"&gt;
        ...
        &lt;form jwcid="@Form" listener="listener:attemptLogin" ...&gt;
            ...
            &lt;input jwcid="password"/&gt;
            ...
        &lt;/form&gt;
        ...
     &lt;/body&gt;
&lt;/html&gt;
</code></pre>

<h2>Login.page</h2>

<pre class="lang-jsp prettyprint-override"><code>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE page-specification
    PUBLIC "-//Apache Software Foundation//Tapestry Specification 4.0//EN"
    "http://jakarta.apache.org/tapestry/dtd/Tapestry_4_0.dtd"&gt;

&lt;page-specification class="mycode.Login"&gt;
    ...
    &lt;property name="password" /&gt;
    ...
    &lt;component id="password" type="TextField"&gt;
        &lt;binding name="value" value="password"/&gt;
        &lt;binding name="hidden" value="true"/&gt;
        ...
    &lt;/component&gt;
    ...
&lt;/page-specification&gt;
</code></pre>

<h2>Login.java</h2>

<pre><code>...
public abstract class Login extends BasePage {
    ...
    public abstract String getPassword();
    ...
    public void attemptLogin() {
        // At this point, inspecting getPassword() returns
        // the incorrectly encoded String.
    }
    ...
}
</code></pre>

<h2>Updates</h2>

<p>@Jan Soltis: Well, if I inspect the value that comes from the database, it displays the correct string, so it would seem that my editor, OS and database are all encoding the value correctly. I've also checked my .application file; it does not contain an org.apache.tapestry.output-encoding entry, and the Tapestry 4 <a href="http://tapestry.apache.org/tapestry4/UsersGuide/configuration.html#configuration.properties" rel="nofollow noreferrer">documentation</a> indicates that the default value for this property is UTF-8. I have updated the description above to reflect the answers to your questions.</p>

<p>@myself: Solution found.</p>

[{'answer_id': 43238, 'author': 'Palgar', 'author_id': 3479, 'author_profile': 'https://Stackoverflow.com/users/3479', 'pm_score': 2, 'selected': False, 'text': "<p>If you have built them as Hyper-V machines, I don't think you can go back.  There are serious differences in the HAL for Virtual PC and Hyper-V.  You can move a VPC to Hyper-V permanantly by removing the VPC add-ins ans adding the Hyper-V integration drivers/services and re-detecting the hardware.</p>\n\n<p>A VPC can run in Hyper-V just fine, don't add the machine drivers for Hyper-V and you can go back to VPC with no problem.  </p>\n"}, {'answer_id': 43369, 'author': 'Brian Leahy', 'author_id': 580, 'author_profile': 'https://Stackoverflow.com/users/580', 'pm_score': 3, 'selected': True, 'text': '<p>VPC to Hyper-V is one way.</p>\n'}, {'answer_id': 4978762, 'author': 'user614283', 'author_id': 614283, 'author_profile': 'https://Stackoverflow.com/users/614283', 'pm_score': 0, 'selected': False, 'text': '<p>You should review Windows 2008 R2 SP1 upgrade with RemoteFX, it comes with a new video driver for VM\'s that allow 3D, extended desktops and more. It will help resolve some of the issues you are seeing today.</p>\n\n<p>Both the Host server and VM need to be running SP1 of Windows 2008 R2.</p>\n\n<p><a href="http://blogs.technet.com/b/virtualization/archive/2010/03/18/explaining-microsoft-remotefx.aspx" rel="nofollow">http://blogs.technet.com/b/virtualization/archive/2010/03/18/explaining-microsoft-remotefx.aspx</a></p>\n'}, {'answer_id': 7784809, 'author': 'jaksonn', 'author_id': 997896, 'author_profile': 'https://Stackoverflow.com/users/997896', 'pm_score': 1, 'selected': False, 'text': "<p>Hyper-V is designed to be used on the server, obviously. Whereas VirtualPC is designed for the end user. Hyper-V will give you more control, and the ability to create and restore snapshots. However, it does not have a direct console interface to the VM, you would use a browser to access the console. I would go Hyper-V, but it really depends on what you're using your VMs for. Luckily, they share the same format for virtual disks, so you can try it out with your existing VMs.</p>\n"}]
['https://Stackoverflow.com/questions/43199', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/4287/']