added japanese iso-2022-jp support.
Still need to configure dependency_maps and charset
cleaned a bit
fixed Swift_Mime_Headers_IdentificationHeader::setId() when passed an array of ids (closes #203)
- Updated Swift_CharacterReader_Utf8Reader::getMapType docblock
 * Changed @int to @return int because it was causing problem to the Symfony2 annotation parser
 * See Symfony2 issue GH-4518
Fixed an encoding bug with MailboxHeader when using both special characters and , or ;
Fixed typo in a comment
merged branch arthens/master (PR #211)

Commits
-------

414a2ca Fixed typo in a comment
d35320b Fixed an encoding bug with MailboxHeader when using both special characters and , or ;

Discussion
----------

Fix address header encoding bug

This is a fix for issue #206:
https://github.com/swiftmailer/swiftmailer/issues/206

This problem happens when the name contains both special characters and commas or semicolons, but in different tokens.

Surnamé, Name is encoded correctly, because the the comma is part of the token with the special character, and therefore it will be encoded.
Surnamé ,Name will NOT be encoded correctly, because the comma is part of the fully-ASCII token and therefore won't be encoded.

This is a problem because commas and semicolons are used to separate addresses, and if not quoted or encoded they will produce an invalid address header.

My fix is to redefine the encoding requirements for mailboxes, adding commas and semicolons to the list of characters that force the token to be encoded.
I've also added a regression test to make sure this problem is not re-introduced in future.
updated CHANGELOG
merged branch maoueh/patch-1 (PR #209)

Commits
-------

b453a96 - Updated Swift_CharacterReader_Utf8Reader::getMapType docblock  * Changed @int to @return int because it was causing problem to the Symfony2 annotation parser  * See Symfony2 issue GH-4518

Discussion
----------

Updated Swift_CharacterReader_Utf8Reader::getMapType docblock

Changed `@int` to `@return int` in docblock because it was causing problem to the Symfony2 annotations parser. See Symfony2 issue [GH-4518](https://github.com/symfony/symfony/issues/4518) for further details.
fixed some phpdoc
Changed the required script to lazy-load the initialization
Made SwiftMailer autoloadable when installed through composer
merged branch stof/autoload (PR #212)

Commits
-------

92e2674 Made SwiftMailer autoloadable when installed through composer
d803827 Changed the required script to lazy-load the initialization

Discussion
----------

Autoload

This makes Swiftmailer autoloadable easily when using composer, by requiring the ``swift_required`` file from the composer autoload. It also changes the file to make it lazy-load the initialization (as done in the Symfony standard edition) to avoid loading the initialization on each request.
updated the CHANGELOG
fixed test suite (was running with Swift installed via PEAR if installed instead of the current one)
merged branch ganchiku/fix-for-iso-2022-jp-without-dependency-maps (PR #199)

Commits
-------

8de4792 cleaned a bit
b4f6fc9 added japanese iso-2022-jp support. Still need to configure dependency_maps and charset

Discussion
----------

added japanese iso-2022-jp support.

Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Swiftmailer tests pass: yes
Fixes the following tickets: #122

Still need to fix dependency maps, and default charset, as I have on my branch as follows:
https://github.com/ganchiku/swiftmailer/tree/iso-2022-jp-with-dependency_maps

---------------------------------------------------------------------------

by fabpot at 2012-05-06T10:58:15Z

A test is broken after applying this PR:

    php test-suite/run.php Swift_Mime_HeaderEncoder_Base64HeaderEncoderAcceptanceTest
    Swift_Mime_HeaderEncoder_Base64HeaderEncoderAcceptanceTest
    1) Encoded string should decode back to original string for sample  at [/Users/fabien/work/swiftmailer/swiftmailer/tests/acceptance/Swift/Mime/HeaderEncoder/Base64HeaderEncoderAcceptanceTest.php line 35]
    	in testEncodingJIS
    FAILURES!!!
    Test cases run: 1/1, Passes: 0, Failures: 1, Exceptions: 0

---------------------------------------------------------------------------

by ganchiku at 2012-05-06T12:20:44Z

Well, the test passes in my environment.
Ubuntu10.04, PHP 5.3.2-1ubuntu4.14 with Suhosin-Patch (cli) (built: Feb 11 2012 06:50:46)

```text
$ php test-suite/run.php Swift_Mime_HeaderEncoder_Base64HeaderEncoderAcceptanceTest
Swift_Mime_HeaderEncoder_Base64HeaderEncoderAcceptanceTest
OK
Test cases run: 1/1, Passes: 1, Failures: 0, Exceptions: 0
```

The test is basically doing the same thing, and should pass.
```php
public function encodeString($string, $firstLineOffset = 0,
    $maxLineLength = 0, $charset = 'utf-8')
  {
      $charset = strtolower($charset);
    if ($charset == 'iso-2022-jp')
    {
        $old = mb_internal_encoding();
        mb_internal_encoding('utf-8');
        $newstring = mb_encode_mimeheader($string, $charset, $this->getName(), "\r\n");
        mb_internal_encoding($old);
        return $newstring;
    }
    return parent::encodeString($string, $firstLineOffset, $maxLineLength);
  }
```

```php
  public function testEncodingJIS()
  {
    if (function_exists('mb_convert_encoding'))
    {
      // base64_encode and split cannot handle long JIS text to fold
        $subject = "長い長い長い長い長い長い長い長い長い長い長い長い長い長い長い長い長い長い長い長い件名";

      $encodedWrapperLength = strlen('=?iso-2022-jp?' . $this->_encoder->getName() . '??=');

      $old = mb_internal_encoding();
      mb_internal_encoding('utf-8');
      $newstring = mb_encode_mimeheader($subject, 'iso-2022-jp', 'B', "\r\n");
       mb_internal_encoding($old);

      $encoded = $this->_encoder->encodeString($subject, 0, 75 - $encodedWrapperLength, 'iso-2022-jp');
      $this->assertEqual(
        $encoded, $newstring,
        'Encoded string should decode back to original string for sample '
      );
    }
  }
```

Or am I missing something?

---------------------------------------------------------------------------

by fabpot at 2012-05-07T06:23:01Z

Here is the values of `$encoded`:

    6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6
    ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6Z
    W344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE5Lu25ZCN

And the value of `$newstring`:

    =?ISO-2022-JP?B?GyRCRDkkJEQ5JCREOSQkRDkkJEQ5JCREOSQkRDkkJEQ5JCREOSQkGyhC?=
     =?ISO-2022-JP?B?GyRCRDkkJEQ5JCREOSQkRDkkJEQ5JCREOSQkRDkkJEQ5JCREOSQkGyhC?=
     =?ISO-2022-JP?B?GyRCRDkkJEQ5JCQ3b0w+GyhC?=

---------------------------------------------------------------------------

by xdecock at 2012-05-07T09:04:01Z

It's more a transcoding to utf-8 than adding charset support if i read
correctly.

On Sat, May 5, 2012 at 10:04 AM, Shin Ohno <
reply@reply.github.com
> wrote:

> Bug fix: yes
> Feature addition: yes
> Backwards compatibility break: no
> Swiftmailer tests pass: yes
> Fixes the following tickets: #122
>
> Still need to fix dependency maps, and default charset, as I have on my
> branch as follows:
>
> https://github.com/ganchiku/swiftmailer/tree/iso-2022-jp-with-dependency_maps
>
>
> You can merge this Pull Request by running:
>
>  git pull https://github.com/ganchiku/swiftmailerfix-for-iso-2022-jp-without-dependency-maps
>
> Or you can view, comment on it, or merge it online at:
>
>  https://github.com/swiftmailer/swiftmailer/pull/199
>
> -- Commit Summary --
>
> * added japanese iso-2022-jp support.
>
> -- File Changes --
>
> M lib/classes/Swift/Mime/HeaderEncoder/Base64HeaderEncoder.php (29)
> M lib/classes/Swift/Mime/HeaderEncoder/QpHeaderEncoder.php (2)
> M lib/classes/Swift/Mime/Headers/AbstractHeader.php (16)
> M lib/classes/Swift/Mime/Headers/ParameterizedHeader.php (2)
> M lib/classes/Swift/Mime/MimePart.php (29)
> A tests/_samples/charsets/iso-2022-jp/one.txt (11)
> A
> tests/acceptance/Swift/Mime/HeaderEncoder/Base64HeaderEncoderAcceptanceTest.php
> (39)
>
> -- Patch Links --
>
>  https://github.com/swiftmailer/swiftmailer/pull/199.patch
>  https://github.com/swiftmailer/swiftmailer/pull/199.diff
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/swiftmailer/swiftmailer/pull/199
>

--
Xavier De Cock
GPG Fingerprint: 93CA EE3F 9F57 5BE1 AE4A  794D 3C74 CA9E E7A5 0C1B
GPG Id: 0xE7A50C1B

---------------------------------------------------------------------------

by ganchiku at 2012-05-08T01:15:29Z

@fabpot , hmm, the $encoded is wrong.. Let me look into the code again.

@xdecock , well I thought so at first, but the you cannot split 75 chars to fold header string without checking each byte of the characters in the header, such as subject field.
The splitting fails because it cannot choose the right place to split. That is the reason why we are using mb_encode_mimeheader, or write the same function in native PHP, which was the one I PRed last time. But closed the one, and instead PRed using mb_encode_mimeheader.

---------------------------------------------------------------------------

by ganchiku at 2012-05-08T02:09:10Z

I cleaned the code a bit, but I don't think it is related the problem.

The $encoded characters,
```text
6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6
ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6Z
W344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE6ZW344GE5Lu25ZCN
```
is utf-8 base64_encoded characters. And it seems the "if statement" below is returning false.

```php
    if (strtolower($charset) === 'iso-2022-jp')
```

I cleand that part to add strtolower, anyway.
As the test code,  the string, "iso-2022-jp" is passed as fourth parameter, "if statement" should pass.

---------------------------------------------------------------------------

by ttsuru at 2012-05-30T12:35:58Z

+1

---------------------------------------------------------------------------

by fabpot at 2012-06-15T19:42:21Z

I still have the same failing test. Can I do something to help you figure out the problem?
updated CHANGES
prepared the 4.1.8 release
bumped version to 4.1.9-DEV
Remove my PayPal details from README and remove old mention of version 3 (long past).