誕生日に一人で仕事しながら見ると元気が出る「ﾕ･鬣`､ﾎ･､･ﾟ･ﾆｩ`･ｷ･逾?ﾎﾕ」5選 - 自省log
先日以下のような記事を書きまして 誕生日に片思いの相手から電話がかかってきた。 - 自省log 要約すると 誕生日に片想いの人から電話があって、うぉおおおお！ってなってうぉおおおおおおお！！！ってなった 話で、おかげ様でたくさんの方にご覧いただいた次第でございます。皆さんその切はありがとうございました。 ただ上記記事を投下した5月24日(私の誕生日)はなんだか休日出勤を余儀なくされておりまして、何故誕生した日に一人さみしく休日出勤しなければいけないのか。なんて毒付きながら半べそかいておりましてね。 そんな自分へのご褒美を買うべく、Amazonで「馬のたてがみ」と検索したら、「ﾕ･鬣`､ﾎ･､･ﾟ･ﾆｩ`･ｷ･逾ﾎﾕ」みたいな商品が出てきまして、すごく元気になりましたので本日は皆さんにもおすそ分けすることにしました。 誕生日に一人で仕事しながら見ると元気が出る「ﾕ･鬣`､ﾎ･､･ﾟ･ﾆｩ`
git 1.7.12でUTF8-MAC問題が解決 | Butaman-kun Project
gitの唯一の弱点は日本語ファイル名に弱いことだ。 つい最近WindowsではUTF-8ファイル名に対応したが、MacではUTF8-MAC(UTF-8-MAC)問題という持病を抱えていた。 このため、WindowsやLinuxで濁点、半濁点とかの入った日本語ファイル名のファイルを含むリポジトリを作成し、Mac上にcloneすると、次の画像のようにこれらのファイルをリポジトリ内のファイルとして見なしてくれないと言う問題があった。 日本語ファイル名が使えなかった旧バージョンのgit 簡単に説明すると、ファイル名の見た目はLinux等と一緒だが、文字コード的に濁点の扱いが微妙に違うためである。ある意味、文字化けの類の問題である。この説明はかなり端折っていて不正確なので、技術的な詳細はこちらを参照して欲しい。 これまで、解決するにはnfsをマウントする方法や、パッチはあったが、本家では取り込まれて
UTF-8-MAC - MacWiki
UTF-8-MAC とは[編集] UTF-8-MAC とは、Mac OS X に付属する iconv にて利用できる文字エンコードの一つで、 Normalization Form D (NFD) で符号化した UTF-8 のことを指します。 一般に UTF-8 とだけいった場合には、Normalization Form C (NFC) でエンコードされたものを意味します。 Unicode 標準では、NFC は正規結合(Canonical Composition)、 NFD は正規分解(Canonical Decomposition)として規定されています。 たとえば、「が」の字を NFC で表現すると U+304C (HIRAGANA LETTER GA) ですが、 NFD では U+304B U+3099 (HIRAGANA LETTER KA + COMBINING KATAKANA-
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
れぶろぐ - [PHP] mb_convert_encoding 関数の ISO-2022-JP と JIS の違い
■ mb_convert_encoding 関数の ISO-2022-JP と JIS の違い mb_convert_encoding() 関数でエンコーディングを指定する際、 ISO-2022-JP と JIS では意味が違うというのはご存知でしょうか？ PHP のソースコード (mbfilter_jis.c) を見てみると、 それぞれのエンコーディングが対応する文字種は、次のようになっています。 ISO-2022-JP ASCII JIS X 0201 ラテン文字 JIS X 0208 JIS ASCII JIS X 0201 ラテン文字 JIS X 0201 半角カナ JIS X 0208 JIS X 0212 要するに、JIS は半角カナに対応していますが、ISO-2022-JP は対応していません。 そのため、半角カナのメールを扱うという無茶なことをやりたい時には、 ISO-20
講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ
「文字集合と文字エンコーディング」というタイトルで、経験2〜3年目の人をターゲットに社内勉強会を開催しました。文字集合という単語を知っている必要はないですけど、少なくともUTF-8とShift_JISとでは扱える文字の種類数が違うことだけは伝えたかったので、その意味では目標が達成できたと思っています。 まとめ 文字集合とは、扱える文字の集合 JIS X 0208なら6000文字くらいの日本語の文字 UCS-2なら60000文字くらいの世界中の主要な文字 文字エンコーディングとは、文字の集合をバイト列に直す方式 Shift_JISはJIS X 0208（など）を1〜2バイトにする UTF-8はUCS-2を1〜3バイトにする 文字エンコーディング関連のツールを使いこなそう nkfやlvを使いこなそう 日本語を探すならlgrep 最終兵器：hexjaで16進ダンプ ムービー
PHP 5.2.12 の文字エンコーディング関連の修正点 - t_komuraの日記
PHP 5.2.12 がリリースされました。 PHP 5.2.12 Release Announcement PHP 5.2.12 ChangeLog Release Announcement にも載っていますが、以前、日記に書いた htmlspecialchars() が Shift_JIS の一部の文字を通してしまう問題は、セキュリティ問題として修正されました。 他にもセキュリティ問題の修正がありますので、バージョンアップした方が安全です。PHP 5.2.12 では、htmlspecialchars() の他にも、mbstring 関連でも文字エンコーディング関連の問題が修正されましたので、メモしておきます。 htmlspecialchars()/htmlentities() で文字エンコーディングを指定した場合に、一部の不正な文字が排除されない問題の修正 以前の日記(最新の PHP
最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容について - t_komuraの日記
前の記事(Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある)で Shift_JIS ではブラウザによっては XSS が発生する可能性があることを書きました。この問題は、PHP の開発版のスナップショット(snaps.php.net)で修正されたことを確認しましたが、それ以外にも、EUC-JP や UTF-8 について修正が行われました。この件で、行動された方に感謝します。どうもありがとうございました。その後、修正内容について調べましたので、メモしておきます。他の修正点など、何か気付いた方がおられましたら、ぜひ教えてください。 この修正は、PHP 5.3.2/PHP 5.2.12 で反映されることになると思います。実際の修正内容の大半は、以下で行われました。 http://svn.php.net/viewvc?view=revision
UnicodeとUTF-8の違いは？ - 自分的まとめ - Humanity
UnicodeとUTF-8の違いは？ - Humanityはあんなに反響があるとは思わなかった。 ブコメにコピペじゃなくてまとめを書いてくれれば良い資料になるのにと書いてあったので今度は自分の知識をまとめてみる。 と言っても自分もあのスレを見るまでUnicodeとUTF-8を混同してた一人なのでほとんどあのスレからの知識ですが...orz なので簡単なまとめ。引用を多分に含みます。間違ってたらつっこんでいただけるとうれしいです。 調べる際に弾さんのエントリがかなり参考になったので(今頃意味が分かってきた)関連リンクとして度々載せさせていただきます。 参考リンクじゃない理由は解説しているエントリだけじゃなくて既存のエンコーディングを拡張するといった高度なエントリも含まれているため。 UnicodeとUTF-8 まず一番重要なことは Unicodeは「符号化文字集合(Coded Charact
htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ
mb_check_encoding() の代替関数 - t_komuraの日記
これまでに挙げた文字コードについて、正規表現を使用して mb_check_encoding() の代替用の関数を書いてみました。ある程度、妥当なものになっているとは思いますが、間違い等に気付いた方がおられましたら、ご指摘ください。 UTF-8 については、RFC3629 を参考にしました。各文字は4バイト以下、冗長な表現、サロゲートペアの領域を FALSE と判定します。 <?php function is_valid_encoding( $str, $encoding ) { switch ( $encoding ) { case 'ASCII' : $regex = '/(?:' . '[\x00-\x7f]' // ASCII (mb_check_encoding) // . '[\x00\x09\x0a\x0d\x20-\x7f]' // ASCII (mb_detect_enco
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
第3回 US-ASCIIによるクロスサイトスクリプティング | gihyo.jp
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
第4回 UTF-8の冗長なエンコード | gihyo.jp
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\）、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
惜しいが間違っている - elf's blog
惜しいけど間違っている点がいくつか． ●default_charsetはデフォルトの文字コードのことではない。 非常に誤解しやすい内容。 default_charsetというパラメータはご存じの人も多いと思う。 それに大抵の初心者本にはこれを設定するように書いてあるが、 むしろ逆である。 default_charsetとは 出力時にHTTPヘッダとして送信する文字コード名 のこと。 これを指定しておくと以下のコードが自動で出力される。 default_mimetype = 'text/html'で default_charset = 'utf-8'の場合 header('Content-Type: text/html; charset:utf-8'); default_charsetは関係ない．もし未指定なら単に Content-Type: text/htmlが出力されます． これだとコン
第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう
前回，入力値検証をセキュリティ対策として実施すべき理由を説明する中で制御文字や不正な文字エンコーディングの問題を指摘した。今回は，その具体例として「ヌルバイト攻撃」と「冗長なUTF-8によるディレクトリ・トラバーサル」を説明する。 制御文字悪用の代表格「ヌルバイト攻撃」 ヌルバイト攻撃とは，ASCIIコード0の文字（ヌル文字）を用いた攻撃である。リスト1に示すPHPスクリプトは，クエリー文字列pとして数値を受け取り，それを表示するというもの。結果を表示する前に正規表現関数eregを使って数字だけのデータかどうかをチェックし，数字でない場合にはエラーメッセージを表示するようになっている。通常，数字だけを使った攻撃は不可能であり，このような「安全な文字」だけを許可するような検査方法を一般に「ホワイトリスト検査」と呼ぶ。
PHP+PostgreSQLでEUC-JP出力は非常識！？ 〜windowsでIBM拡張文字が文字化け：地方で活動するweb制作者の日々を綴るblog
2007年07月10日23:27 カテゴリ技術-PHP PHP+PostgreSQLでEUC-JP出力は非常識！？ 〜windowsでIBM拡張文字が文字化け PHPでプログラムを作成する場合、文字コードをEUC-JPで作成するケースが多いと思います。 SJISでソースは書けませんし、UTF-8は正直まだなじみが薄いといえます。 しかし... 今回の結論（突然ですが） PHP+PostgreSQLの環境でEUC-JPを使うと、Windows環境においてIBM拡張文字を正しく表示できずに文字化けを起こす。 表示させるには、出力文字コードをUTF-8やSJISとすること。 IBM拡張文字とは？ JIS基本漢字（JIS X 0208）以外に定義される拡張文字のことです。 IBMによって定義された「IBM拡張文字」 (115〜119区) と、NECが自社のPC-9800シリーズ用に定義した「NEC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shift_JIS「もしかして・・・・・・」 UTF-8「私たち……」：キニ速
GitHub - okbob/url_encode: url_encode, url_decode functions for PostgreSQL