You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
という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/
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
これらの対策のうち，ここでは「文字集合の変換を伴う変換をしない」など，アプリケーション全体の文字コードの取り扱いについて上流工程で留意すべき内容について説明しよう。「入力値のチェック」については次回以降，「入力値の検証」の項で詳しく説明する。「アプリケーションでの正しいマルチバイト文字の処理」については，個別の処理内容の項で説明する。 文字コードの取り扱いについて，上流工程で留意すべき点としては，次の三つが挙げられる。 要求仕様として文字集合を定義する端末がサポートする文字集合を確認する実装に用いる文字エンコーディングを決定する まずアプリケーション仕様として，処理対象となる文字集合を規定する必要がある。日英語以外の韓国語や中国語，アラビア語などの対応が必要な場合はUnicodeを選択するしかない。さらに日本語だけの場合でも，例えばJIS X 0201＋JIS X 0208はJIS第2水準
文字コードの問題に正しく対応する前提として，アプリケーションが稼働する基盤ソフトウエアがマルチバイト文字列処理に対応している必要がある。特に問題となるのが，言語処理系とデータベース管理システム（DBMS）である。利用者の使い方が正しくない場合も，ぜい弱性が混入することがある。このため，今回は主要言語とデータベース（MySQLとMS SQL Server）のマルチバイト文字対応状況について説明する。 文字列の処理単位は文字単位かバイト単位か Webアプリケーション開発で人気のあるスクリプト言語の多くは，かつては文字列をバイト単位で扱っているものが多かった。以下のPerlスクリプトは“漢字”という文字列の長さを表示するものだが，ソースの文字エンコーディングによって結果が変わる。具体的には，Shift_JISやEUC-JPの場合は4，UTF-8の場合は6と表示される。原因は，このスクリプトが文字
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
文字集合自体は抽象的な「文字の集まり」に過ぎないので単独で問題になることはないが，異なる文字集合に変換する際には問題が発生する場合がある。文字集合が異なるということは，対応する文字が1対1対応していないので，変換先の文字集合で対応する文字がないケースや，多対1の対応が発生する可能性がある。 図1に，Unicodeからマイクロソフト標準キャラクタセットに変換する場合を例示した。マイクロソフト標準キャラクタセットには「骶」（尾てい骨の“てい”）や，ハングルなどはない。また，バックスラッシュ「\」（U+005C）と円記号「\」（U+00A5）がともにJIS X 0201の「\」（0x5C）に変換される場合について示している。 「漢」のように1対1対応している文字は問題ない。ハングルや「骶」のように対応するコードポイントがない場合はエラーになるか文字化けする。インターネットで「尾 骨 びていこつ」
今回から5回にわたって，アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか，疑問に思うかもしれないが，Webアプリケーションで文字コードを指定可能な個所は非常に多く，しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている（図1）。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では，ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して，文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは，セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
Stream_Filter_Mbstring Subversion Repository: http://openpear.org/repository/Stream_Filter_Mbstring / Latest Release: 0.0.7 Stream_Filter_Mbstringは、PHPストリームに対するカスタムフィルタです。あらゆるストリームに対し、文字エンコーディングの変換および英数字/記号/カタカナの正規化を提供します。 機能一覧 以下のストリームフィルタを提供します。詳細は後述します。 convert.mbstring.encoding.* convert.mbstring.kana.* メリット 巨大なファイルに対しても、メモリを無駄に消費せず文字エンコーディングを変換できます 標準入力や標準出力に対しても適用可能です 利用が容易です 文字エンコーディング関連の攻撃
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに？そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな！ 8割の女性は「恋人以外にも使う」』（RBB NAVI）なんていうニュースもありました。携帯電話の個人普及率が9割を上回る（平成20年内閣府消費動向調査）この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
This proposal has been approved, and Emoji symbols were added in Unicode 6.0. They have been growing and flourishing since then. The rest of this page (and much of this site) is only of historic/archival interest. The proposal for encoding of Emoji symbols as Unicode characters covers the Emoji symbols that are in widespread use by DoCoMo, KDDI and Softbank for their mobile phone networks. These s
絵文字とは、顔の表情やその他のシンボルなどを絵で表現した文字で、日本の携帯電話ユーザーの間で特に人気があり、広く使用されているものです。先月、Gmail でも絵文字が使用可能になりました。詳しくはGmail チームのブログポスト「Gmail で絵文字が使えるようになりました 」をご覧ください。 これらの絵文字は携帯電話会社が各々独自に創作したもので、メールやウェブなどで使われています。絵文字は元々各携帯会社のユーザー同士で使用されることを前提に作られたものですが、現在では各社間である程度の互換性を保つための絵文字変換表も利用されています。 ユーザーは携帯会社や機種の違いに関わらず、見慣れている絵文字が表示されることを期待しています。自分がメールで送った絵文字が、受信側でも同じか同等の絵文字で表示されること、ウェブで見る絵文字が他の携帯ユーザーにも同じに見えること、また検索エンジンで絵文字を
UbiquityでHTMLコンテンツとマッシュアップ - IkeTの日記 英語翻訳 - エキサイト翻訳のサービスを利用して英日翻訳するUbiquityコマンド。 このサービス、どうも翻訳後の文字コードがShift_JISで文字化けしてしまうという事が書かれていたので、ブクマコメントにてjQueryは知らんけど、XMLHttpRequestのoverrideMimeTypeでcharsetを指定すれば文字化けはしないはずですよとアドバイスした。 それを受けてid:IkeTさんが、jQueryではできそうもないからXMLHttpRequestを直に叩いたよ、と追記してくれました。 上記、記事を受けて、jQueryでスクレイピングする時の文字化け対処法 - 不動産屋のラノベ読みでid:Lhankor_Mhyさんが、jQueryでも出来るよ！的な記事を書いている。 ただ、この記事での書き方では た
Yahoo! Pipes の charset 問題の文字化けが直らないので回避策を調べてみました。 いずれも reverse proxy 的にヘッダ (だけでもないけど) を書き換えるサービスをオリジンサーバと Pipes の間にはさむ方法です。 xmliconv Pipes の掲示板で紹介してもらいました。http://william.cswiz.org/tool/xmliconv/?url=http://pc.watch.impress.co.jp/sublink/pc.rdf のように使います。 charset だけを書き換えるサービスです。 個人サービスっぽいのでいつまで続くかわかりません。 feed のキャッシュはしないようです。 Google Mashup Editor Google Mashup Editor で公開されているアプリには feed を Atom で提供する機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
