下図は、SoftBankiPhoneのMailが用いるShift_JISのIBM拡張文字領域*1。どうだ、驚いたろう。 SoftBankiPhoneのMailは、charset=Shift_JISをよく使う。髙村薫の「髙」や宮﨑あおいの「﨑」などのWindows外字もShift_JISで送るし、絵文字もShift_JISで送る。しかし、WindowsのIBM拡張文字領域とSoftBankの絵文字領域は、もともと衝突しており、共存できない。なので、SoftBankiPhoneのShift_JISでは、IBM拡張文字のうち下図ピンク部分が使えない。 だったらその分は、NEC選定IBM拡張文字のほうを使えばいいじゃないですか、どうせダブってるんだから(下図)。というのが、大ざっぱに言えば、SoftBankiPhoneのMailが用いるShift_JISである。 その外字領域をまとめると、

ご利用に関する諸注意本サービスは smkn (From kiki verb) によって、”現状のまま” 提供されるものとします。本サービスについては、明示黙示を問わず、商用品として通常そなえるべき品質をそなえているとの保証も、特定の目的に適合するとの保証を含め、何の保証もなされません。事由のいかんを問わず、損害発生の原因いかんを問わず、且つ、責任の根拠が契約であるか厳格責任であるか (過失その他) 不法行為であるかを問わず、smkn (From kiki verb) も寄与者も、仮にそのような損害が発生する可能性を知らされていたとしても、本サービスの使用から発生した直接損害、間接損害、偶発的な損害、特別損害、懲罰的損害または結果損害のいずれに対しても (代替品またはサービスの提供; 使用機会、データまたは利益の損失の補償; または、業務の中断に対する補償を含め) 責任をいっさい負いません

という2chのスレがかなり勉強になったのでまとめ。 少しでも有用だと思ったものは載せてあるので結構長いです。 Unicodeのような文字集合(符号化文字集合?)やUTF-8のようなエンコーディング方式に限らず色んな文字コードにまつわる話があります。 たびたび話が繰り替えされますがそれは確認ということで。 (元スレ) 追記:簡単にまとめました。 1 :デフォルトの名無しさん:2007/04/30(月) 20:02:37 ビッグインディアンとかなんとかかんとか 3 :デフォルトの名無しさん:2007/04/30(月) 20:05:48 また、頭の悪そうなスレが・・・ >>1 それは魚とマグロの違いを訊ねるようなもんだ。 4 :デフォルトの名無しさん:2007/04/30(月) 20:06:49 魚と鮪というよりは、魚と刺身の違いのような気がする。 5 :デフォルトの名無しさん:2007/04/
UTF-JPの特徴 UTF-JPは、UTF-8と同様に、1バイト単位で可変長の多バイト文字を構成し、理論上、全てのUNICODE文字を表せますが、日本語テキストを扱うのに特に優れています。 UTF-JP符号では、ASCII文字(0x00-0x7f)は、1バイト、日本語のうち、JIS第一、第二水準の文字は、2バイト、その他のUNICODE文字は、3バイト以上で表されますので、UTF-8と比べて、日本語を短い符号で表せます。 また、UTF-8同様、テキストを逆戻り可能であり、検索する際も、多バイト文字の途中でヒットすることを簡単に防ぐことが可能です。 日本語の部分は、JIS符号と対応関係のある符号が割り当てられますので、UNICODEへは、変換テーブルを介する必要がありますが、日本語以外の部分は、UNICODEへ直接対応付けることが出来ます。 UCS-2までは、最大3バイトで、UCS-
今回から5回にわたって,アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか,疑問に思うかもしれないが,Webアプリケーションで文字コードを指定可能な個所は非常に多く,しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている(図1)。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では,ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して,文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは,セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう

こんにちは、亀本です。 === 追記:みなさんいっぱいはてブしてくれたようなので、せっかくなのでちょっと宣伝です(^^; この絵文字データベースは、携帯専用イベント支援サイト「あつまろ☆ねっと」というサイトの、メーリングリスト連動型の掲示板を構築していく過程で出来上がったものです。 「あつまろ☆ねっと」は現在ベータ版ですが、ぜひ利用してやってください<(。_。)>ペコリ === 携帯サイト作成の際に頭を悩ます最初の関門が、絵文字の取り扱いだと思います。 各社とも絵文字のデータ形式や相互変換表などを公開してくれていますが、取り扱いやすいデータ形式で統一的にまとめてある情報がなかなか存在しなかったりして、車輪の再発明が非常に多い分野ではないかな、という気がしました。 そこで、どうせなら利用しやすいようにきっちり整理しようと思い、各種文字コードや表示形式を統括的に扱う絵文字データと、それらの絵

最新版はこちら http://code.google.com/p/kanaxs/ ひらがな⇒カタカナ String.prototype.toKatakanaCase = function() { var i, c, a = []; for(i=this.length-1;0<=i;i--) { c = this.charCodeAt(i); a[i] = (0x3041 <= c && c <= 0x3096) ? c + 0x0060 : c; }; return String.fromCharCode.apply(null, a); }; "ぁぃぅぇぉあいうえお".toKatakanaCase(); // ァィゥェォアイウエオ カタカナ⇒ひらがな String.prototype.toHirakanaCase = function() { var i, c, a = []; for(i
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [intemplate "__entry.ftlh" atline 3, column 25] - Reached through: #include "__entry.ftlh" [intemplate "entry.ftlh" at
基本的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えばRuby の場合、不正なUTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです(昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く