ほら貝：文字コード
B案には 680 x 96（JIS風にいうと、680区96点）のB-1案と、256 x 256（256区256点）のB-2案がありました。いずれも制御文字、アルファベット等の非漢字、JIS X 0208の漢字部分、GB2312の漢字部分、9216字（= 96 x 96）分の保留領域４つ、最後に外字領域という構成です。ISO 2022を無視して16bitのスペースをフルに使っていますから、A案の倍近い文字が収録可能です。 B-1案の 680 x 96は半端な構造のように見えますが、運用実績のあるJIS X 0208とGB2312は 94 x 94の配列でできていましたし、提案の年に制定されるKSC5601は 96 x 96だったので、横を 96列とすると国内コードと国際コードの相互変換が簡単になるのです。 投票では、圧倒的多数でISO 2022系の既存文字コードとの互換性を維持したA案が支持
UnicodeとUTF-8の違いは？ - Humanity
という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/
KLab
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
文字エンコーディングの妥当性確認(バリデーション)について - t_komuraの日記
大垣さんからコメントをいただきましたので、最後に追記しました(2009.09.22)。 少し時間が経ってしまいましたが、以下のページを読んで、PHP に関連する部分について思ったことを書きたいと思います。 http://blog.ohgaki.net/char_encoding_must_be_validated http://blog.ohgaki.net/is-char-encoding-problem-difficult 私の理解が間違っていなければ、「Web アプリケーションで文字エンコーディングに関連する問題を無くす」ことを目的として、全ての Web アプリケーション開発者が以下を実行しようという主張だと思います。 全ての入力文字列の文字エンコーディングの妥当性を確認する 文字エンコーディングを厳格に取り扱う データベースなどで「バイナリ」に近い文字エンコーディングは利用しない
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
第8回 Unicodeからの多対一の変換［後編］ | gihyo.jp
前回は、WindowsにおいてWideCharToMultiByte APIを使用してUnicodeからShift_JISやISO-8859-1へ変換した場合に、WC_NO_BEST_FIT_CHARSというフラグを指定しなかった場合は「似ている文字への変換」が発生するため、セキュリティ上の問題が発生する可能性がある、という説明をしました。 今回は、実際にUnicodeから他の文字コードへの変換が、具体的に脆弱性を引き起こした例をいくつか紹介します。 電子メールの添付ファイル 電子メールの添付ファイル名には自由にUnicodeの文字が指定できますが、いくつかのメールクライアントにおいては添付ファイル名をUnicodeではなくShift_JISとして扱うために、問題が発生していました。 JVN#89344424: 複数のメールクライアントソフトにおける、添付ファイルによりメールクライアントソ
ブラウザでさくさく確認できる、Unicodeの一覧表
ブラウザでさくさく確認できる、Unicodeの一覧表「Unicode table for you」を紹介します。
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
UTF-8.jp
- WinMirror - 任意のアプリケーションのウィンドウやデスクトップをミラーリングして表示できます。 解説: オンサイトでの登壇で返しのモニターがなくてもデモをやりやすくするツールを作った - SSTエンジニアブログ - 音声字幕機能付きのWebカメラ - Web Audio APIを使ってマイク入力をスピーカーから出力 - LTタイマー - JavaScriptセキュリティの基礎知識：連載｜gihyo.jp … 技術評論社 - HTML5時代の「新しいセキュリティ・エチケット」－ @IT - 教科書に載らないWebアプリケーションセキュリティ － ＠IT - 連載：本当は怖い文字コードの話｜gihyo.jp … 技術評論社 - JSF*ck - encode JavaScript with only 6 letters - []()!+ (broken) JSF*ck demo
Variable Byte Code と UTF-8、またはUTF-24が存在しないわけ : 404 Blog Not Found
2009年08月05日00:30 カテゴリLightweight Languages Variable Byte Code と UTF-8、またはUTF-24が存在しないわけ 実は、これに非常に良く似た符号化を、我々は日々目にしています。 γ符号、δ符号、ゴロム符号による圧縮効果 - naoyaのはてなダイアリー 通常の整数は 32 ビットは 4 バイトの固定長によるバイナリ符号ですが、小さな数字がたくさん出現し、大きな数字はほとんど出現しないという確率分布のもとでは無駄なビットが目立ちます。 UTF-8です。 UTF-8は、0x0から0x10FFFFまでの整数を、以下のようにしてバイト列に変換します。 Range/Offset0123 0x00-0x7F0xxxxxxx 0x80-0x3FF110xxxxx10xxxxxx 0x400-0xFFFF1110xxxx10xxxxxx10xx
使いこなそうユニコード
UCSとUTFとは？ [2003-11-11] Unicode正規化とは [2008-01-14] Unicodeに関するメモ [2002-06-15] JIS X 0213とUCS/Unicodeとの対応について [2006-12-30] Unicode文字の表示例 (Unicode 4.1.0) [2005-04-23] JIS/SHIFTJISとWINDOWS/CP932との相違 [2001-07-08] JIS X 0208とUnicodeとの対応表/ZIP版 [2002-06-01] Shift_JIS-2004 (JIS X 0213:2004)とUnicode 3.2.0の対応表/ZIP版 [2007-01-03] [同じくShift_JIS-2004 (JIS X 0213:2004)とUnicode 3.2.0の対応表/非圧縮テキスト] ・JIS X 0213:2000
MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.1 一般の文字セットおよび照合順序
文字セットとは、記号とエンコーディングのセットです。 照合順序とは、文字セット内の文字を比較するためのルールを集めたものです。 架空の文字セットを例にして、文字セットと照合順序の違いを見てみましょう。 4 文字のアルファベットがあるとします: A, B, a, b。 各文字に数字を付けます: A = 0, B = 1, a = 2, b = 3。 文字 A は記号、数字 0 は A 用の encoding で、4 文字すべてとそのエンコーディングの組合せは文字セットです。 A と B の 2 つの文字列値を比較するとします。 これを行う最も簡単な方法は、エンコーディングを確認することです: 0 (A の場合)、1 (B の場合)。 0 は 1 より小さいため、A は B より小さいと言います。 今ここで行なったのは、文字セットに対する照合順序の適用です。 照合順序はルールの集まりであり、こ
PHPとMySQLの個人的まとめ - ぱんぴーまっしぐら
MySQLではまったこと MySQLの文字化け 今さら何いってんのコイツとかそこ言わない。 文字コードを確認するSQL文「SHOW VARIABLES LIKE ‘char%’;」 MySQL4.1以降はサーバとは別にクライアントの文字コードが設定されている。 クライアント、サーバ間で違う文字コードがセットされていると、一度ucs2変換を通る。 よって、クライアント、サーバ間で違う文字コードを指定することとなり文字化けが起こる可能性がある。 PHPはmy.cnfで[mysql]、[client]を設定しようがクライアントの文字コードはビルド時に指定されたキャラクタセット(通常latin1)。 my.cnfの設定 [mysql] default-character-set = utf8 [mysqld] default-character-set = utf8 mysqlクライアントからチェ
UTF-8 エンコーディングの危険性 - WebOS Goodies - 葉っぱ日記
UTF-8の非最小形式による代替エンコーディングの話。古典的な攻撃方法なので、知っていて当然の話だと思っていたのですが、意外にまだ知られていないんですね。古くは Nimda の攻撃でも利用されていました…というのを調べていたら、たまたま「セキュリティホールのアンチパターン」という資料がひっかかったので紹介しておきます。あとは、ばけらさんによる説明「用語「Unicode Web Traversal」@鳩丸ぐろっさり (用語集)」がわかりやすいです。 個人的には、「UTF-8」というからには、こういうおかしなバイト列が含まれていた時点で入力全てを捨ててしまって例外などを発生させるべきで、無理やり UTF-32 とかに直すのは間違っているように思います。そうでないと、0xC0 0x32 のように、完全に壊れている UTF-8 をどうするの？とかにもなりますし。 あと、どうでもよい話： そもそもU
perl - use CGI; use Encode; # 非英語Webプログラミング3原則 : 404 Blog Not Found
2009年06月23日15:30 カテゴリLightweight Languages perl - use CGI; use Encode; # 非英語Webプログラミング3原則 これは、実はPerlに限らず未だに事実だったりするのですが.... Perl でフォームデータから UTF-8 日本語文字をとりだす方法 (プログラミングの小石・大石) UTF-8 のフォームによっておくられたデータのなかから日本語文字をとりだすことは，日本の Perl CGI プログラマならたいてい必要になることである． ところが，その方法は意外に確立されていないようにみえる． しかし、元発言の方法は先祖帰りすぎるので。 Perlプログラマー以外にも、Webプログラマーであれば有用なentryです。 PerlでWebプログラミングする場合の三原則 QueryはCGIモジュールで処理する 文字コードはEncode
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
文字エンコーディングが仲間外れのファイルを素早く見つける方法
プロジェクトに多人数が参加するようになると、なぜかプロジェクトの標準とは異なる文字エンコーディングのファイルがcommitされていることがあります。UTF-8で統一しているはずなのにShift_JISのファイルがある、なんて場合ですね。そこでメンバーの注意力不足を指摘したり、「だから＊＊＊（自分の使っていないエディタの名前を入れてください）はダメなんだ」とかいう宗教論争に発展させたりというのでは不毛ですよね。簡単に気づく方法があればそれでいいんですよ。 方法は色々あると思いますが、今日はどこのご家庭にも必ずあるnkfを使ってみましょう。最近のnkfには--guessというオプションがあり、文字エンコーディングを推測してくれます。 $ nkf --guess hoge*.txt hoge1.txt:EUC-JP (LF) hoge2.txt:UTF-8 (LF) hoge3.txt:B
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLの文字化け