Do not fail printing non-ascii text

Signed-off-by: Daniel Graña <dangra@gmail.com>
(cherry picked from commit 35aacae92c1af7acbf7e59c2dfc31f998f7fcf3d)

Closes pull request #7 from @dangra.

This probably collides with #5, depending on whether the main script is
able to properly decode the value to the terminal.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Revert pull request #5.

This reverts commit 7c29e2343a1f2877fc36cd771652644132b156ea.

Pull request #7 should take care of proper encoding already and encoding
to latin1 while ignoring encoding errors is a workaround, so let's drop
it now and verify/test if it's working.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fix server listing in presence of non-ascii chars

Signed-of-by: Daniel Graña <dangra@gmail.com>
(cherry picked from commit a4953eb6d5bcb07d548c6dd3b1f6bae506ab6050)
hetznerctl: Replace encoding errors by '?'.

It's not nice to rely on exception handling here, but we're doing this
only for hetznerctl, so it shouldn't be critical for the API itself.

This at least ensures that the encoding won't fail if the current locale
doesn't contain characters we want to encode.

A better way would be if we could change the default encoding error
handler, but unfortunately, we can't do this if we want to ensure
compatibility.

This is also noted at:

http://www.python.org/dev/peps/pep-3116/#unicode-encoding-decoding-issues

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Bump version to 0.7.1.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Merge branch 'release-0.7.1'.

Closes #7 and #10.

Conflicts:
	hetznerctl