Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong character encoding if platform's default encoding is not based on ASCII #73

Open
GoogleCodeExporter opened this issue Mar 30, 2015 · 0 comments

Comments

@GoogleCodeExporter
Copy link
Contributor

Hi!

When running the SMTP server on a platform with an encoding that it not based 
on ASCII (i.e. most IBM platforms are based on EBCDIC) the server is unable to 
do its work.

A look into the sources showed, that the CRLFTerminatedReader takes an 
InputStream and every consumed byte is simply converted into a char. Java will 
use the platform's default encoding to convert a byte into a char. When using 
any ASCII based default encoding this is no problem. But on IBM platforms with 
default encoding EBCDIC this does not work.

The same problem occurrs, when writing the data to the socket output stream. 
The OutputStream is simply wrapped by a PrintWriter, that uses the platform's 
default encoding.


I fixed the first issue by changing the input of the CRLFTerminatedReader into 
an InputStreamReader that explicitly uses ASCII as character encoding (and by 
the way changed the super class to FilterReader to minimize the number of 
methods I had to overwrite).
The OutputStream problem could be fixed using a similar "trick": Simply wrap 
the socket's output stream in a OutputStreamWriter and then wrap that Writer in 
a PrintWriter.


Attached you can find both files I changed.
Tested on Windows 7 x64 and IBM z/OS (both Java 1.6)
Version of SubethaSMTP: 3.1.7

Original issue reported on code.google.com by [email protected] on 5 Jan 2015 at 12:58

Attachments:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant