モバイル

iPhoneアプリを多言語対応にする

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - iPhoneアプリを多言語対応にする
このエントリーをはてなブックマークに追加

こんにちは、デスクの上にiPhoneを意味もなく3台並べる男、faultierです。

僕の普段の仕事はlivedoor blogやlivedoor ニュースのモバイル版のシステム開発ですが、ときにはlivedoor クリップアプリのようなiPhoneアプリの開発もやっています。ということで、今日はPerlの話ではなく、iPhoneアプリとObjective-Cの話をしようと思います。

iphone_jaiphone_ja_icon

上の画像はlivedoor クリップアプリですが、実は言語設定が「日本語」以外に設定されていると日本語部分が英語に変わります。

ピクチャ 3iphone_en_icon

MacOSXのアプリケーションを作成したことがある方はご存知かと思いますが、Cocoaアプリケーションは簡単に多言語化する仕組みが備わっています(できることは単順ですが)。

ローカライズされたリソースを用意する

まず、ローカライズされたリソースの置き場を用意します。英語と日本語に対応する場合は、en.lprojとja.lprojというディレクトリを作って、Xcode上でプロジェクトに取り込みます。他の言語にも対応する場合は、(ISO 639で定義されている2文字もしくは3文字の言語コード).lprojというディレクトリを追加していくだけです。

また、もっと細かく分類したいのであれば、en_USやen_GBなどのように、ISO 3166で定義されているコードを使用して国や地域に絞り込むことができます。

さらに、English、Japanese、French、Germanなど言語名での指定もサポートしていますが、こちらはレガシーなやり方のようなので、言語コードを使う方をお薦めします(後述するXcode上からローカライズドなリソースを作る方法では、何故かEnglishやJapaneseのようなディレクトリになりますが…)。

en.lprojとja.lprojをプロジェクトに取り込んだら、それぞれの下にInfoPlist.stringsとLocalizable.stringsというファイルを作ります。InfoPlist.stringsは、Info.plistで設定される内容(例えばアプリの表示名など)をローカライズするために使います。Localizable.stringsの方は好きに使えるローカライズドされた文字列を入れて置きます。

中身は以下のように、"key" = "localized value"の形式で記述します。あとは、プログラム側からこのキーを元に文字列を取得すれば、そのときのiPhoneの設定に応じてそれぞれの言語の文字列を使うことができます。

/*
 ja.lproj/InfoPlist.strings
 */
CFBundleDisplayName = "日本の心";
/*
 ja.lproj/Localizable.strings
 ここはコメント
 エンコーディングはUTF-16でなければならないことに注意
 */
"Hoge" = "ほげ";
/*
 en.lproj/Localizable.strings
 */
"Hoge" = "foo";

また、先にlprojディレクトリを作るのではなく、先にInfoPlist.stringsやLocalizable.stringsをプロジェクトに追加しておき、「情報を見る」から「ローカライズ可能にする」こともできます。この場合、Xcodeのプロジェクト上にはlprojグループは表示されず、stringsファイルそのものが二つに分裂したように表示されますが、内部では(言語名).lprojが作られています。

プログラム側をLocalizedStringに対応させる

こうして用意したローカライズドされた文字列をプログラム側から使うコードは、次のようになります。

NSString *localizedString = [[NSBundle mainBundle] localizedStringForKey:@"Hoge" value:@"Hoge" table:nil];

これで、「Localizable.stringsからキーがHogeのローカライズドされた文字列を取得する。現在の設定の言語専用のリソースが無いか、あってもこのキーが定義されていなければ、"Hoge"という文字列を返す」という処理です。

ただ、毎回これを書くのは「文字列を取得する」という目的のためだけにはちょっと煩雑なので、次のようなマクロが用意されています。

NSString *localizedString = NSLocalizedString(@"Hoge", @"");

2個目の引数はただのコメントなので、特に何かに使われるわけではありません。これで最初のコードと同じ文字列が得られます。元のメソッドでは、どこのバンドルから取ってくるか、どのテーブル(ファイル)から文字列を探すか、指定されたキーが見つからなかった場合に返すデフォルトの値は何か、まで指定できますが、「バンドルがmainBundle、テーブルはLocalizable.strings、指定したキーが見つからない場合はキーと同じ文字列」で良いのであれば、このマクロの方が楽ですね。

ちなみに、テーブル名を指定した場合はLocalizable.strings以外のファイルから文字列を取得することもできます。例えば、Error.stringsというファイルを作り、そこにエラーメッセージをまとめておくと、プログラムからは次のように呼び出せます。

NSString *lcalizedErrorMessage = NSLocalizedStringFromTable(@"ConnectionError", @"Error", @"");
// 次のコードでも同じ
//NSString *lcalizedErrorMessage = [[NSBundle mainBundle] localizedStringForKey:@"ConnectionError" value:@"ConnectionError"];

このようにして、アプリ中で使われる文字列を(言語名).lproj以下のstringsファイルに抜き出しておけば、あとはそのファイルを言語毎に作ってやるだけで、表示する文言やメニューのラベルなどを変える程度ではありますが、簡単に多言語対応できるようになります。

xibファイルのローカライズ

stringsファイルでローカライズする他に、xibファイルも同じ方法で各言語ごとのローカライズ版を作ることができます。プログラム側を大幅に変更せずとも、言語に合わせてUIを変えることができるようになります。

ただ、機能やデザインに関わるxibファイルを各言語分用意して管理するのは、文字列しか含まれていないstringsファイルの管理よりは手間もかかり気を使う必要もありますし、サイズも大きくなります。これを使う場合はその必要があるかどうか、慎重に検討した方が良いでしょう。

ちなみに、livedoor クリップアプリのUIは大部分をxibファイルを使わずに実装しているため、特にUI自体のローカライズはしていません。

多言語対応のメリット

iPhoneアプリは、AppStoreのおかげで思った以上に海外のiPhoneユーザにも見てもらえます。

livedoor クリップの場合、元のサービスがそもそも日本語を理解できる人でなければ使えないサービスなので、日本語のみ対応にしてもよかったのですが、リリース後に国別のダウンロード数を見たところ予想以上に海外からのダウンロードがありました(もちろん、海外在住の日本人だったり、無料のアプリなので気軽にダウンロードしてしまっただけの可能性もありますが)。

よく分からないアプリケーションでも、まったく読めない言語で書いてあるより、英語化されているだけでも少し安心してもらえるようです。

みなさんも、是非、世界中で使ってもらえるiPhoneアプリを作ってみて下さい!

livedoor Blog モバイルのサーバ構成

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - livedoor Blog モバイルのサーバ構成
このエントリーをはてなブックマークに追加
こんにちは、栗原です。

今回はlivedoor Blog モバイルのサーバ構成についてご紹介しようと思います。

日本でも最大規模のブログサービスのモバイルサイトがどのようなサーバ構成で稼動しているのか、またその構成を構築していく上で苦労した点や今後どのようにして行こうと考えているかについても説明できたらと思います。

サーバ構成

まずは現在のlivedoor Blog モバイルの内部構成について簡単に説明したいと思います。
livedoor Blog モバイルでは、大きく分けて5種類のサーバ群が稼動しています。

リバースプロキシ + アプリケーションサーバ
ユーザが携帯からブログを閲覧した際にページを生成してレスポンスを返すサーバ群になります。現状はApache(リバースプロキシ)とApache + mod_perl(アプリケーション)を1台のサーバに同居させた形で稼動しており、台数は全部で66台になります。

画像変換サーバ
携帯のサービスではキャリアや端末ごとに画像サイズや形式を変換して表示するため、ユーザがアップした1つの画像につき数種類の画像を生成してやる必要があります。その画像変換処理をするサーバが、この画像変換サーバになります。

現在は、ユーザのリクエストに応じてリアルタイムに画像を変換し(独自Apacheモジュールにて変換)、一度変換した画像は一定期間キャッシュする(memcachedを使用)構成になっています。画像変換サーバはApache + modperlで稼動しており、その台数は16台あります。

画像キャッシュサーバ
上記の画像変換サーバで生成された画像をキャッシュすると共にユーザが閲覧する際にレスポンスを返すサーバが、この画像キャッシュサーバになります。画像キャッシュサーバは、Apache(リバースプロキシ)とbalanceと呼ばれるソフトウェアロードバランサを同居させた形で稼動しています。

このサーバでは、まずユーザからの画像のリクエストをApacheが受け、そこからbalanceを使って前述の後ろに控えている16台の画像変換サーバにメッシュ状に変換を依頼するリクエストの投げています。こちらは合計4台のサーバが稼動しています。

リビルドサーバ
livedoor Blogを使用したことのあるユーザはご存知かと思いますが、livedoor Blog(PCサイト側)ではユーザがブログを書く際にその記事のページなどを静的に再構築する処理があり、その再構築処理をこのリビルドサーバで行なっています。現在は変換依頼をキューとして貯めるためのMySQLと、実際に再構築処理をするためのdaemon(Perlで書かれた独自プログラム)が稼動しています。こちらは合計4台で稼動しています。

モブログサーバ
ユーザがモブログをした際にメールを受けとり、記事投稿処理をするためのサーバがモブログサーバになります。こちらはMTAとしてqmailが稼動しており、Perlで書かれたプログラムでメールを処理しています。こちらは現在8台で稼動しています。

livedoor Blog モバイルのPV数

さて、サーバ構成とその台数について簡単にご紹介しましたが、実際にこの構成でどのくらいのリクエストをさばいているのかが気になるところだと思いますが、その内訳は以下のようになっています。

ユーザブログ及び管理画面のPV:約1200万PV/日
画像閲覧PV:約300万PV/日
モブログ数:約5万通/日

この内訳をみて皆さんはどう感じたでしょうか。現在のlivedoor Blogモバイルでは、画像などのファイル以外、ほぼすべてのページを動的に生成しているためサーバの台数に対する処理数が少ないように感じるかもしれません。しかし、それにはわけがあります。

モバイルサービスではページを閲覧しているユーザの携帯端末やキャリアによって広告やHTMLを適宜出し分ける必要があり、リクエスト毎にページを動的に生成する必要があります。そのためリクエストは必ずアプリケーションサーバ(この場合mod_perl)での処理が必要となります。どうしてもその部分では、PCサイトなどに見られる静的ファイルを前段のリバースプロキシサーバなどでキャッシュして負荷分散をすることができません。

今後は、この部分をmod_perlよりも前のレイヤーであるApache(リバースプロキシ)側でApacheモジュールとして実装するなどして、負荷を分散することも検討しているところです。

運用していく中で困ったこと

今まで運用をしてきて、最も困ったのはモブログです。

当初モブログのサーバでは、ユーザからの投稿メールが来た際リアルタイムにデータベースにデータをインサートし、リアルタイムに再構築(PC側の静的ファイル)をする形式をとっていました。

この方法ですとメールが大量に送られてくる時間帯は必然的にサーバが重くなり、それにひきづられる形で記事データをデータベースに格納する処理や再構築の処理も遅くなります。結果として携帯用のページも再構築して生成されるPC用のページも閲覧できるようになるまで、かなりの時間を要していました。

モブログをするユーザは、モブログを送った後すぐに携帯でそのモブログした記事が投稿されているかを確認する傾向にあるようです。そこで重い処理はキューに入れて後で処理をするという方法を用いて、最低限携帯用のページだけは見られるようするという施策を取っています。

これによりPCサイトのページの再構築の処理は一旦キューに入れておき、記事データだけは先にデータベースに入れておくことで動的な携帯用のページだけは、すぐに見えるようにしてあります。そしてサーバのリソースに余裕がでてきたところで、順次PCサイトのページの再構築を行なっています。

今後は再構築する処理を別サーバにするなども検討しています。

今後行いたいこと

今後行いたいと考えていることはいくつかありますが、その中でもユーザ的にも、システム的にもインパクトのあるものをいくつか上げると
  • 画像のインライン表示
  • デコメでのモブログ
  • 全キャリアでの絵文字対応
  • オリジナルデザインのアップロード
  • 静的コンテンツ化

などを予定しています。
すべてをすぐに対応ということは難しいかもしれませんが、これらの対応を徐々にしていきたいと考えておりますので、今後ともlivedoor Blog モバイルをよろしくお願い致します。

上位端末向けケータイサイトを作ってみた

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - 上位端末向けケータイサイトを作ってみた
このエントリーをはてなブックマークに追加
こんにちは。モバイル担当の小森谷です。
puchiprofpuchiprof_qrcode
ケータイユーザーで流行っていると言われるプロフサイトなるものを作ってみました。
プチプロフ
今回はこちらのプロフサイトの仕組みをモバイル部分を中心に紹介したいと思います。

■ターゲット
10代〜20代の男女のケータイユーザーを中心に向けて仕様やデザインを検討してみました。また、その辺りの年代の人たちはDoCoMoのmovaやEZの非win端末を使用する割合は低いだろうと見てXHTMLや画像サイズは大きめに取る上位端末向けサイトとして作成しました。
もちろんPCからの閲覧も可能ですが、現段階ではオープンしたばかりでケータイユーザーをメインに据えていますので、PCでのインターフェースなど使いづらい部分もあるかと思いますがご了承ください。

■環境
・CentOS4
・Apache2.0 + WebDAV, Apache1.3 + mod_perl
・MySQL5
・perl5.8 (Sledge, DBIC, Gearmanなど)
・qmail
・memcached
・HyperEstraier

■画像
添付メールで送られてきた画像はImage::Imlib2またはImagerを使って適当な大きさへリサイズと変換を行います。
変換ルールとして、EZ,Softbankの上位端末はGIFの表示が可能ですのでちょっと強引ですが
・JPG → JPG
・PNG → JPG
・GIF → GIF
とし、キャリアごとに別の拡張子の画像を用意しない方針で変換しています。
そして変換した画像はWebDAV経由でImageサーバーへ転送される仕組みになっています。

■絵文字
社内向け共通モジュールとして作成されたEncode::JP::Mobileを拡張したものを使用しております。
モバイルはすべてSJISで出力を行っており、Softbankの3G用にUTF8で出力するなどの対応は行っておりません。
PCはUTF8で出力し、絵文字に対応するマッピングされた画像を用意しIMGタグで出力されます。

■認証
モバイルでのログインは端末製造番号を必須とし、それを使って認証を行います。DoCoMoで機種変した時などはID,PASSWORD入力の必要がありますがその際にも端末製造番号を必須とし、認証用の端末製造番号を上書きします。
1端末につき1ユーザーとしPCからの入会もすべてモバイルを経由する方式になっています。

■キャリアGW
モバイルのIP判別はNet::CIDR::MobileJP::Scraperを使用し取得しております。
弊社内の全ての案件で効率的にキャリアのIPの管理が行えるように現在社内用IP管理APIなども製作してもらってるとこです。
外部公開に関しては未定のようです。

■検索
HyperEstraierを使用し、インデックスの作成はDBIC経由でGearmanにdispatch_backgroundで投げています。

■サーバー構成
オープンして間もなく、とりあえず小規模構成で始めてみる方針なので
Webサーバー + Imageサーバー x 2台
DBサーバー x 1台
Mailサーバー + 検索サーバー x 1台
の計4台でPVが伸びて行き次第、同梱されているサービスを分けて拡張していく予定でおります。


まだオープンしたばかりでバグなどもいくつか見つかっていますが、機能拡張と安定運用を目指しユーザーの増加に努めて行きたいと思います。
よろしくお願いします。

モブログに潜んでいる不具合

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - モブログに潜んでいる不具合
このエントリーをはてなブックマークに追加
今回はモブログに潜んでいる不具合を紹介してみたいと思います。
モブログと言ってもブログサービスに限った話ではなく、SNS の日記などを携帯から投稿したり、送信するメールに写真を添付してフォトストレージサービスにアップロードしたり、その仕組みは様々なサービスに応用されています。

では、その様々なサービスに潜んでいる不具合の内容からご説明しましょう。

・件名を「サークルKサンクス」など「全角半角英数全角」としてモブログ。
・投稿された記事のタイトルが「サークルK サンクス」となる。
 「サークルK」と「サンクス」の間に半角スペースが入る。
・AU、SoftBank の端末ではこの不具合は起こらない。

こんな感じ。

なぜこの不具合が起こるか、を説明する前に RFC2822(822) の Section 2 に目を通しておいた方がよいかもしれません。
とは言うものの、英文で量も少なくないので大事な部分を抜粋します。

2.1.1. Line Length Limits

There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.


2.2.3. Long Header Fields

Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a multiple
line representation; this is called "folding". The general rule is
that wherever this standard allows for folding white space (not
simply WSP characters), a CRLF may be inserted before any WSP. For
example, the header field:

(p8)
Subject: This is a test

can be represented as:

Subject: This
is a test

「2.2.3. Long Header Fields」はちょっと理解しずらいですが大事なので補足的な説明を。
ヘッダフィールド(「Subject: This is a test」や「To: precure@example.com」などのこと)は

「フィールド名」「:」「フィールドボディ」「CRLF」

という構造をしていなくてはいけません。
ヘッダにおいて「CRLF」は1つヘッダフィールドの終わりを示す特別なものです。
しかし、「2.1.1. Line Length Limits」に「SHOULD be no more than 78 characters, excluding the CRLF.」とあるように、1つのヘッダフィールドは 78文字以内にするのが推奨されます。
でも、78文字を越える場合は「CRLF」で folding することができます。
その場合は、「CRLF」に続く次の行はホワイトスペースではじめましょう。
ということです。

それでは実際に DoCoMo、AU、SoftBank のそれぞれの端末でメールを送ってみて Subject: がどうなっているか見てみましょう。

まずは、DoCoMo。

Subject: =?iso-2022-jp?B?GyRCJFUkPyRqJE8bKEI=?=PrettyCure
=?iso-2022-jp?B?GyRCJEAkaCRNISohKhsoQg==?=

1行目の「=?iso-2022-jp?B?GyRCJFUkPyRqJE8bKEI=?=PrettyCure」で 57文字。78文字の制限まで多少余裕はあるけれど、次の「=?iso-2022-jp?B?GyRCJEAkaCRNISohKhsoQg==?=」を続けられるほど余裕はないので改行します。2行目はホワイトスペースを1つ入れて「 =?iso-2022-jp?B?GyRCJEAkaCRNISohKhsoQg==?=」。
RFC2822(822) の推奨通りですね。行儀が良いです。

続いて、AU。

Subject: =?ISO-2022-JP?B?GyRCJFUkPyRqJE8bKEJQcmV0dHlDdXJlGyRCJEAkaCRNISohKhsoQg==?=

AU は改行することなく1行。ちなみに、75文字。行儀よくないです。

最後に、SoftBank。

Subject: =?ISO-2022-JP?B?GyRCJFUkPyRqJE8bKEJQcmV0dHlDdXJlGyRCJEAkaBsoQg==?=
=?ISO-2022-JP?B?GyRCJE0hKiEqGyhC?=

SoftBankも改行しています。

おまけとして、Thunderbird。

Subject: =?ISO-2022-JP?B?GyRCJFUkPyRqJE8bKEJQcmV0dHlDdXJlGyRCJEAkaCRNGyhC?=
=?ISO-2022-JP?B?GyRCISohKhsoQg==?=

きれいですね。

さて、3キャリアから送信したメールのヘッダが揃いましたが、これらをデコードしてみましょう。Perl でモブログの機能を提供しているところではおそらく、MIME::Parser を使用しているのではないでしょうか。そして、肝心な Subject: のデコードは、MIME::Words::decode_mimewords で実装されていると思います。
ということで、今回は MIME::Wrods::decode_mimewords でデコードした結果を掲載します。
DoCoMo の場合。

ふたりはPrettyCure(CRLF)
だよね!!(CRLF)

AU の場合。

ふたりはPrettyCureだよね!!(CRLF)

SoftBank の場合。

ふたりはPrettyCureだよね!!(CRLF)

ヘッダの最後には必ず CRLF が含まれます。デコードしてもその CRLF が取れることはありません。なのでアプリ側で行末の CRLF を取り除いたりしていると思います。CRLF を取り除いてみましょう。このとき、DoCoMo の途中にある変な CRLF も一緒に取れてしまいます。

DoCoMo の場合。

ふたりはPrettyCure だよね!!

AU の場合。

ふたりはPrettyCureだよね!!

SoftBank の場合。

ふたりはPrettyCureだよね!!

やっぱり、DoCoMo の端末のみ「PrettyCure」の後にホワイトスーペースが入っています。AU はそもそもホワイトスペースを挿入していないのでホワイトスペースが入るわけもありませんが、SoftBank は改行してホワイトスペース(1行目は TAB)を入れているにも関わらず、デコードしてもホワイトスーペースが入っていることはありません。なぜでしょうか?
それは、DoCoMo のエンコードの仕方に問題があるからです。
メールのヘッダは ASCII を使うようにしなくてはならないので、日本語は Base64 にエンコードしますね。3キャリアすべて Base64 にエンコードされてはいますが、DoCoMo 茸もともと ASCII である「PrettyCure」をエンコードしていないのです。
(おまけとして挙げた Thunderbird は AU、SoftBank 同様すべてを Base64 でエンコードしています。)
この状態で MIME::Words::decode_mimewords を通ると、2行目以降の行頭の半角スペースが取れません。
それはなぜか?
MIME::Words::decode_mimewords をちょっと覗いてみましょう。手元のバージョンは 5.420 です。

sub decode_mimewords {
my $encstr = shift;
my %params = @_;
my @tokens;
$@ = ''; ### error-return

### Collapse boundaries between adjacent encoded words:
$encstr =~ s{(\?\=)\s*(\=\?)}{$1$2}gs;
pos($encstr) = 0;
### print STDOUT "ENC = [", $encstr, "]\n";

### Decode:
my ($charset, $encoding, $enc, $dec);
## 以下デコード処理

鍵は真ん中あたりの「$encstr =~ s{(\?\=)\s*(\=\?)}{$1$2}gs;」。
「?=」はエンコードの終了マーク、「=?」はエンコードの開始マークになります。
なので、この行で行っている処理は、

エンコードの終了とエンコードの開始マークの間にあるホワイトスペースを取り除く

ということになります。s オプションがついているので改行は無視されて単一行として扱われていますね。前述したように、DoCoMo はそもそも ASCII である「PrettyCure」をエンコードしていません。「?=」と「=?」の間にホワイトスペース以外の「PrettyCure」があるので上記の正規表現に引っ掛からないんですね。だから、CRLF の後の行頭のホワイトスペースがとれないんです。デコード後に「変な CRLF」が残っているのも上記の正規表現に引っ掛からないからです。
結果として DoCoMo の端末で件名を「ふたりはPrettyCureだよね!!」としてモブログすると、投稿された記事のタイトルが「ふたりはPrettyCure だよね!!」となるわけです。

ここまでの説明だと
「『PrettyCure』をエンコードしない DoCoMo の端末がダメなんじゃない?」
なんて思われる方もいるかもしれませんが、そうでもないみたいです。
と言うのも、RFC2047
MIME の Non-ASCII Text についての取り決めです。
RFC2047 で重要な部分を「Perlメモ - Base64エンコード・デコードする」から引用します。

1. encoded-word は 75バイト以内でなければならない.
2. encoded-word を含む行は 76バイト以内でなければならない.
3. encoded-word はそれぞれ独立してデコード可能でなければならない.
4. encoded-text をデコードした文字列の文字コードは,最後に ASCII が指定された状態でなければならない.
5. encoded-word が現れる出現位置に関する決まり.
* Subject や Comment のヘッダフィールドなどの, 'text' 内に出現.
* "(" と ")" で区切られた 'comment' 内に出現.
* From や To,CC ヘッダなどで,'phrase' 内に出現.
* 'addr-spec' 内で出現してはならない.
* 'quoted-string' 内で出現してはならない.などなど.
6. 隣り合う encoded-word の間の 'linear-white-space' は無視する.

RFC2822(822) から「ヘッダフィールドは CRLF を抜いて 78文字以内にしましょうね」と紹介しましたが、日本語 (Non-ASCII Text) を使用するときは Base64 でエンコードしますので上記の 1 と 2 から 1つのヘッダフィールドは76文字以内にしなくてはいけません。
6 は MIME::Words::decode_mimewords の
「エンコードの終了とエンコードの開始マークの間にあるホワイトスペースを取り除く」
というロジックの根拠ですね。
1 〜 6 はどれも大事なことなのでメール関係のスクリプトを書くときはおさえておきたい項目です。

そして、今回の不具合において大事なのは次の引用


RFC 2047 には本来 encoded-word に変換する必要のないもの,つまり,ASCII だけから成る単語まで変換するのは推奨できないと書かれています.ですから,実行例のように is や test. までいっしょに encoded-word に変換するのはあまりいい例とは言えません.

おそらく、上記の「推奨」を重んじて DoCoMo の端末は「PrettyCure」をエンコードしないのだと思います。

今回紹介したモブログに潜む不具合がアプリのバグなのか、RFC2047 の推奨を頑なに守る DoCoMo の端末がおかしいのかはわかりませんが、とにかく提供しているサービスに不具合があることは確かです。
担当者のみなさん、頑張って直してくださいね。

開発部「ちわ」でした。

続きを読む