Tickets :: Comment on [#1621] non-ASCII 7-bit message headers not RFC2047-encoded

* Your Email Address
* Spam protection	Enter the letters below: . ,.__.. ..__ .__ \./ [__]\|\/\|[__)[__) \| \| \|\| \|\| \[__)
Comment	> Well, I tried the '[^\x00-\x7f]' regex pattern in is8bit(), but no > dice. I may be speaking ignorantly (in fact, it's very likely) but, > even though we are using a multibyte-aware regex function, this > character set (ISO-2022-JP) is still a 7-bit character set. How > are we going to find byte values in the range [\x80-\xff] in a > 7-bit-byte character set? > > > > I'm starting to think this is a lost cause...I placed some diagnostic > output in the String::regexMatch function and see that, even though > the $charset being passed in is "ISO-2022-JP", the resultant > mb_regex_encoding() is "EUC-JP". > > > > IMHO, the root of this problem is that the MIME::encode function > claims to "Encode a string containing non-ASCII characters according > to RFC 2047", while it actually only encodes strings containing > non-8bit characters. Since non-8bit does not always imply ASCII, we > need to find a good test of "ASCII-ness". I can test for ISO-2022-JP > using a regex like '\x1b[\(\$]', but it would be nicer to have a more > general test (if one exists) for non-ASCII 7-bit encodings.
Attachment
Watch this ticket