On Mar 6, 2010, at 15:34, Bob Cronin wrote: > Oh and I believe that your specific example would require VM SMTP to be > configured with the DBCS statement with SJISKANJI as the value. If you did > that, it would have converted the incoming ASCII to EBCDIC 939 (but would > likely have left the headers alone). > the character set translated-to really ought to be documented in a "Content-type: text/???; charset=IBM???" header so that if your guess doesn't match the recipient's expectation, he has a chance to recover by refiltering.
But what to use for a last resort EBCDIC encoding without information loss? The dreaded and widely shunned UTF-EBCDIC? I see a lot of merit in a scheme that would leave the message in the recipient's reader in untranslated ASCII (no informaton lost!) and leave the EBCDIC rendering to the viewer (PEEK) or extractor (RECEIVE). If the recipient doesn't like what he sees, he can PEEK again with different rendering options, or forward to a UTF-8 savvy workstation. Back on charter: Wnat pipelines stages manipulate Unicode? -- gil
