2013-11-27 1 views
2

Мне было предложено исправить ошибку в нашем почтовом программном обеспечении. Когда сообщение предметом которого кодируется в RFC 2047 следующим образом:Кодировка японского символа в Base64

=?ISO-2022-JP?B?GyRCR1s/LiVGJTklSC1qRnxLXDhsGyhC?= 

получен, он неправильно декодирован - один из японских символов не отображается должным образом. Он отображается следующим образом: 配 信 テ ス ト? 日本語, когда это должно быть (я не понимаю японский) - очевидно, что один из символов, который выглядит в скобках, не был визуализирован.

декодирование осуществляется javax.mail.internet.MimeUtility.decodeText()

Если я попробовать с онлайн-декодером (единственным я нашел here), кажется, работает хорошо, так что я подозревал ошибку в MimeUtility ,

Так что я попробовал некоторые эксперименты, в виде этой маленькой программы:

public class Encoding { 

    private static final Charset CHARSET = Charset.forName("ISO-2022-JP"); 

    public static void main(String[] args) throws UnsupportedEncodingException { 

     String control = "繋がって"; 
     String subject= "配信テスト㈱日本語";    

     String controlBase64 = japaneseToBase64(control); 
     System.out.println(controlBase64); 
     System.out.println(base64ToJapanese(controlBase64)); 

     String subjectBase64 = japaneseToBase64(subject); 
     System.out.println(subjectBase64); 
     System.out.println(base64ToJapanese(subjectBase64)); 

    } 

    private static String japaneseToBase64(String in) { 
     return Base64.encodeBase64String(in.getBytes(CHARSET)); 
    } 

    private static String base64ToJapanese(String in) { 
     return new String(Base64.decodeBase64(in), CHARSET); 
    } 

} 

(The Base64 и Hex классы в org.apache.commons.codec)

Когда я запускаю его, вот вывод:

GyRCN1IkLCRDJEYbKEI= 
繋がって 
GyRCR1s/LiVGJTklSCEpRnxLXDhsGyhC 
配信テスト?日本語 

Первая, более короткая японская строка - это элемент управления, и это возвращает то же, что и вход, преобразованный в Base6 4 и обратно, используя Charset ISO-2022-JP. Все в порядке.

Вторая японская струна - одна с изворотливым персонажем. Как вы видите, он возвращается с? вместо персонажа. Выход кодировки Base64 также отличается от исходного кодирования объекта.

Извините, если это длинное, я хотел быть основательным. Что происходит, и как я могу правильно декодировать этого персонажа?

+0

Попробуйте использовать «MS932» в кодировке. Средство private static final Charset CHARSET = Charset.forName ("MS932"); – AJJ

+0

Вы пытались использовать SHIFT-JIS в качестве кодировки? –

+0

Ну, но обычно вы должны конвертировать UTF-8 в Base64 ... это упростит. –

ответ

1

Попробуйте использовать «MS932» или «Shift-JIS» в кодировке. Средства

private static final Charset CHARSET = Charset.forName("MS932"); 

Существуют различные сценарии на японском языке, такие как кандзи, катакана. Некоторая кодировка, подобная Cp132, не поддерживает некоторые символы японцев. Проблема, с которой вы сталкиваетесь, связана с кодировкой «ISO-2022-JP», которую вы использовали в своем коде.

1

ISO-2022-JP использует пары байтов, называемых ку и десять, этот индекс в таблицу символов 94 × 94. Пара, которая терпит неудачу, имеет ku 12 и десять 73, которая не указана в таблице допустимых символов, которые у меня есть (на основе JIS X 0208). Все ku = 12, похоже, не используются.

В Википедии не отображаются все обновления JIS X 0208. Возможно, отправитель использует какое-то расширение, определенное поставщиком?

0

Несмотря на то, что ISO-2022-JP является кодировкой с переменной шириной, кажется, что Java не поддерживает раздел набора символов, в котором он находится (возможно, в результате отсутствия управляющих последовательностей в ISO-2022-JP-2, которые присутствуют в ISO-2022-JP-3 и ISO-2022-JP-2004, которые не поддерживаются). UTF-8, UTF-16 и UTF-32 все же поддерживают все персонажи.

UTF-32:

AAB+SwAAMEwAADBjAAAwZg== 
繋がって 
AACRTQAAT+EAADDGAAAwuQAAMMgAADIxAABl5QAAZywAAIqe 
配信テスト㈱日本語 

В качестве дополнительных лакомого, независимо от того, был ли использован UTF-32, когда струны были напечатаны как есть они сохранили свою естественную кодировку и появились нормально.

2

Ошибка в вашем программном обеспечении, но сама строка темы неправильно закодирована. Другое программное обеспечение может декодировать текст, сделав дополнительные предположения о содержании, так же, как часто предполагается, что символы в диапазоне 0x80-0x9f кодируются Cp1252, хотя ISO-8859-1 или ISO-8859-15 указаны ,

ISO-2022-JP - кодировка с несколькими кодировками с использованием управляющих последовательностей для переключения между фактически используемым набором символов. Ваша закодированная строка начинается с ESC $ B, указывая, что используется набор символов JIS X 0208-1983. Оскорбительный символ кодируется как 0x2d6a. Эта кодовая точка не определена в указанном наборе символов, но позже добавлена ​​в JIS X 0213: 2000, более новую версию спецификаций набора символов JIS X.

 Смежные вопросы

  • Нет связанных вопросов^_^