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

* Your Email Address
* Spam protection	Enter the letters below: . __ .__..__.. . \| / `\| \|\| \|\ / \|___\__.\|__\\|__\| \/
Comment	> So my reply, which will attempt to battle yours for ignorance :) > > > > I do understand that ISO-2022-JP is a 7-bit charset in that any > individual byte is in the range 00-7f (hex). However, obviously, the > charset uses the presence of an escape character to indicate that > consecutive bytes need to be combined to properly form the character. > > > > Therefore, it is my understanding that the mb_ereg_() functions > _should_ somehow be able to return a multibyte character when the > non-charset preg_() functions will not. Example: > > > > String: ESCAPE_CHARACTER MB_CHAR_1 MB_CHAR_2 > > > > This string has three bytes. All three bytes are in the range 00-7f. > Therefore, doing a preg_() match will result in this string > appearing to be 3 7bit characters - thus, is8bit() will return false. > > > > However, to mb_ereg() this string should be interpreted as a single > character, two byte string. Therefore a search for 00-7f should* > fail since the character is actually something more like 2e3f (hex). > Even though the underlying string is entirely 7bit, mb_ereg() should > be applying the regex to the "actual" representation of the string. > > > > All of this goes to tell me that it is probably an error with the > regex which is causing the multibyte character to not be recognized. > I would think a regex like "/.{1}/" would match "ESCAPE_CHARACTER" > for preg and "japanese character" for ereg(). However, I haven't yet > figured out a way to do this in a single regex. Anyone with ereg() > style regex experience that could chime in would be appreciated.
Attachment
Watch this ticket

Saved Queries