自分の持ち場を守ること - もじのなまえ
どうもご無沙汰をしております。前回エントリから1ヵ月以上ですか。この間、「もじもじカフェ」があったり（たくさんの方に足を運んでいただき、ありがとうございました）、明日にはいよいよ漢字小委員会で最終答申案が発表される予定だったりと、けっして書くネタに困るような状況ではなかったのですが、ここ1ヵ月はブログどころではなかったのが実情でした。 では、なにをやっていたかというと、仲間とともに以下のような文書を作っておりました。 A Proposal to Revise a Part of Emoticons in PDAM 8[「PDAM8におけるEmoticonに対する修正提案」PDF/1.1MB] ISO/IEC 10646を審議するWG2委員会への寄書。絵文字についてです。 昨年11月にGoogleが絵文字をUnicodeに収録する計画を発表しました。これは順調にすすみ、今年2月にUnicod
CNS11643 中文全字庫(舊版)-首頁
2018-05-10 「107年中文全字庫網站推廣應用說明會」5月14日10:00開放報名囉! 2018-04-03 新增暫編戶政姓名用字14-3E5D及17-2141，共2字 2018-01-31 新增暫編戶政姓名用字17-213F，共1字 2018-01-23 新增暫編戶政姓名用字17-213D及17-213E，共2字 2017-11-02 新增暫編戶政姓名用字12-5023，共1字
htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ）
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
Announcing the “CMap Resources” open source project
CJK Type Blog CJK Fonts, Character Sets & Encodings. All CJK. #AllOfTheTime. Chinese Thanks to requests from numerous open source developers over the years, along with Adobe’s own “Open Source Initiative,” all of Adobe’s CMap resources are now available under an open source license. See: http://opensource.adobe.com/wiki/display/cmap/ The “CMap Resources” open source project includes all CMap resou
エリプシス（ellipsis）と三点リーダ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
欧文組版で用いられる一般的なエリプシスは、3つのドットをベースライン上に配したもので、日本語組版で用いられるセンターライン上の三点リーダとは位置が異なる。 しかしJIS X 0208やJIS X 0213は、（1面）1区36点の三点リーダを、U+2026 HORIZONTAL ELLIPSISと対応付けている。このため、U+2026 HORIZONTAL ELLIPSISをどちらの形状とするかは実装依存ということになり、一般に和文フォントではセンターライン形状、欧文フォントではベースライン形状となっている。 下図における長方形の枠内は、Unicode Standardのコード・チャートの画像。ただし、枠内の正方形の色地は、目安として追加したもの。 Unicodeには、U+2026 HORIZONTAL ELLIPSISの他に、センターライン形状のU+22EF MIDLINE HORIZON
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: )私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けにもう少し解りやすい
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
アポストロフィの悩み | Okumura's Blog
何でもいいから英語の単語に「痴」を付けてGoogleで検索してみる。例えば「he痴」でもいい。うまく見つからなければ，例えば Shakespeare痴 Got A Gun を見てみる。英語のサイトなのに何でこう「痴」が多いのか（うまく「痴」に見えないなら，ブラウザのデフォルトのエンコーディングをシフトJISにしてみてください）。 答え：Windows-1252（CP1252）のアポストロフィは 0x92 であり，これにs（0x73）が付くと 92 73 となり，これはシフトJISで「痴」になる。つまり，「He's」が「He痴」に化けるページはアポストロフィをWindows-1252でエンコーディングし，エンコーディング指定をしていないのでシフトJISで表示してしまったのである。書いた本人はLatin-1（ISO 8859-1）のつもりかもしれない。 アポストロフィは '（0x27）でいいの
Microsoftが総括「Windows Vistaにフォントの混乱なし」 - もじのなまえ
あまり時間がないので短くご報告。 Microsoftの「Windows 7向けJIS90互換フォントパッケージの提供と今後について」記者説明会に行ってきました。これについてはプレスリリースも出ています。 Windows(R) 7 向け JIS90 互換フォントパッケージの提供 より詳しくはINTERNET Watchの記事などをご参照ください。 マイクロソフト、JIS90互換フォントの提供はWindows 7で最後 細部は記事にゆずるとして、ぼくが重要だと思ったことは以下の点です。 Windows Vistaによるフォント変更について、同社コールセンターに対し、クレームの電話は1件もかかってきていない。 Microsoftは（今のところ）この件について、ユーザーに大きな混乱は発生しなかったと考えている。 Windows Vistaでフォント・デザインが変更されたことについては、2006年に
MiAU勉強会の反省 - もじのなまえ
前回のエントリでご案内した第4回 MIAU勉強会ですが、ぶじに終了。その画面資料ですが下記にて公開します。 RFCから見た新常用漢字表の矛盾と整合 以前にも書きましたが、自分の仕事については誉めてくれるより批判的な意見の方がより参考になります。参加者のご意見で最後に発言してくださった方が、文字コードの話の部分と新常用漢字表（仮）の部分とで違和感があるという趣旨の指摘をしてくださいましたが、あらためて画面を見直すと、たしかにそうだなあと。 会場では別の部分でお答えしたのですが、振り返ってみればもっと違う言いようがあった。わざわざ来てくださった直井さんも、後半が飛躍しすぎといっていたけど、おそらく同趣旨のことではないか。 この発表を考えていた際、ずっと思っていたことは、「一部のRFCやXMLで規定されている互換漢字の置き換え処理／使用禁止と、常用漢字表の考え方の間には共通点があるように思えるが
JIS X 0213は改正しないと新常用漢字表に対応できない？ - もじのなまえ
書いておかないと忘れそうなのでメモ。 前日のエントリに対するUnicodeさん、mashabowさんのご指摘について調べるうちに、ハタと気づいたこと。 完全に見落としていたのですが、今までなんとなく「新常用漢字表」の「（付）字体についての解説」の「1 明朝体のデザインについて」は、表外漢字字体表におけるそれと下位互換だと思っでいたのですが、まったくの思い違いでした。 表外漢字字体表の「表外字だけに適用されるデザイン差について」（漢字使用の実態への配慮から、字体の差と考えなくてもよいと判断したもの）で挙げられていたものを、新常用漢字表はまったくふれていません。そもそも新常用漢字表における「1 明朝体のデザインについて」は改定されていません。 表外漢字字体表で挙げられているうち、新常用漢字表の追加字種に関わるものは以下のとおりです。 A 画数の変わらないもの (2) 傾斜・方向に関する例 (3
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
二つの顔を持つ神 - もじのなまえ
幸いなことに先週末に掲載した絵文字が開いてしまった「パンドラの箱」第4回は好評をもって迎えられた様子。ブックマークしてくださった方々が、さきほど確認したら360人。これは第1回の693人には及ばないものの、第2回、第3回を上回る数字であり、素直に喜んでいる。 また、ネット上でも拙文に触れてくださる方々が大勢いらっしゃり、折りにふれて楽しく拝見している。こういう場合、書いた本人を触発するという意味では、肯定するよりむしろ批判する文章の方に軍配が上がる（もちろん誉めてくれるのは無条件にうれしいのだけれど）。 「そうか、こういう考え方があったのか」「そういう受け取られ方をしたか」ということです。こうした直言は親しい人や編集者はなかなか言ってくれないことだから、なるべく素直に受け止めたいと思っている。誤解や曲解も含め、あらゆる反応は筆者にとって良い糧になりうる。鰯や秋刀魚のように骨まできれいに食べ
明朝、CNETに絵文字の原稿が掲載 - もじのなまえ
5日の朝6時以降に公開だそうです。 絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り" 今回は、絵文字をめぐって勃発したUnicode公式メーリングリストでの議論を紹介します。ここで去年12〜今年2月にかけて1,000通以上のメールが行き交う、絵文字についての大論争が発生したんですね。 たしか3月の京大東洋学セミナーに行った際、早朝のマクドナルドで必死に翻訳をやっていたのがなつかしい（といっても電子翻訳）。あれからもう3ヵ月近くか、原稿書くのが遅いですね……。 今回は前までの倍近い分量なので*1、今まで通り多くの方々に読んでもらえるか心配です。翻訳その他の監修をご快諾いただいた師茂樹さん、直井靖さん、それにCNET翻訳チームに感謝感謝。 この後、WG2ダブリン会議のことを書いて完結。いつ終わるのかなあ。いや、来週には書き終えるぞ！ *1:ちな
第12回■主要言語別：入力値検証の具体例
これまで2回にわたってWebアプリケーションにおける入力値検証とセキュリティ対策の関係を説明してきた。入力値検証はセキュリティ上の根本的対策ではないが，保険的な対策として効果が期待でき，特に制御コードや不正な文字エンコーディングによる攻撃対策には有効であることを説明した。 今回は，Webアプリケーション開発によく使われる4種類の言語（Perl，PHP，Java，ASP.NET）に関して，入力時処理の具体例を示す。ここで取り上げる「入力時処理」とは以下の内容を含んでいる。 文字エンコーディングの検証文字エンコーディングの変換入力値検証 Perlによる実装の方針 Perl言語はバージョン5.8から内部文字エンコーディングとしてUTF-8をサポートし，文字単位での日本語処理が可能だ。文字エンコーディング処理にはEncodeモジュールを使用する。入力値検証には正規表現を用いるのが便利だ。 ■文字エ
第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう
前回，入力値検証をセキュリティ対策として実施すべき理由を説明する中で制御文字や不正な文字エンコーディングの問題を指摘した。今回は，その具体例として「ヌルバイト攻撃」と「冗長なUTF-8によるディレクトリ・トラバーサル」を説明する。 制御文字悪用の代表格「ヌルバイト攻撃」 ヌルバイト攻撃とは，ASCIIコード0の文字（ヌル文字）を用いた攻撃である。リスト1に示すPHPスクリプトは，クエリー文字列pとして数値を受け取り，それを表示するというもの。結果を表示する前に正規表現関数eregを使って数字だけのデータかどうかをチェックし，数字でない場合にはエラーメッセージを表示するようになっている。通常，数字だけを使った攻撃は不可能であり，このような「安全な文字」だけを許可するような検査方法を一般に「ホワイトリスト検査」と呼ぶ。
アルファベットを全角で打つ奴が許せない:アルファルファモザイク
どっちかに統一してもらえれば、特に問題ない。 うちの上司の書類は全半角混入だからイライラする。 ex.aｂcとか\５，000とか・・・
第5回 不正なバイト列の埋め込み | gihyo.jp
今回は、「不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて （1) 処理A ＝ 文字列中に特定の文字（あるいは文字列）が含まれていないか検査 （2) 処理B ＝ 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて本来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unicode Terminology: English - Japanese
マイクロソフト、JIS90互換フォントの提供はWindows 7で最後 