タグ

文字コードに関するno_riのブックマーク (61)

  • 革命の日々! ハチクロはUnicodeの歴史を変えてしまったらしい

    togetterで「ISO/IEC JTC 1/SC 2/WG 2 ad hoc meetings: Emojiに関するTweets」がまとめられているようだ。 すばらしい。 → http://togetter.com/li/15979 と http://togetter.com/li/16108 一番面白かったのは「勝ち誇り」フェイス変更のくだりで この頭の左側のような「はぁ?なにこの鼻提灯」といった図面から 以下のような正しい鼻息に変更されたのだが そのときに使われた、日のマンガ文化の文脈で「勝ち誇り」がどのように抽象化されているのか という説明に使われたのが以下のコマだという 小形さんの多大なる貢献に経緯を表しつつ。そして同時に、森田先輩あなたって人は・・・・

  • エディトリアル : ほら貝 北朝鮮の文字コードには「金日成」と「金正日」に特別に文字が割り振られている

    Apr05 二ヶ月ぶりの更新です。また文字コードのを書いていて、更新しない状態がつづきました。 24時間かかりきりになっているわけではないし、映画も見れば芝居にもいって、文字コードに関係のないも読んでいるのですが、文字コードというテーマは精神衛生上よくなくて、更新する気力が失せていました。 この二ヶ月間にR.A.ラファティが亡くなり、早稲田松竹が休館し、情報処理学会の標準化セッションにパネラーとして出席するというように、材料はたくさんあったのですが、文字コードにかかわっていると気分がふさいできて、ページの更新にまでエネルギーがまわせませんでした。 悪い話ばかりではなく、来月、安部公房の『幽霊はここにいる』が上演されますし、『燃えつきた地図』の映画化が決まりだそうです(監督はこのページの中にいます)。安部公房関係はこれから目が離せなくなります。 Jun22 『図解雑学 文字コード』とい

    no_ri
    no_ri 2010/05/06
    「北朝鮮の国家文字コード、KPS 9566」「空白をはさんで72位から77位まで、ハングル完成形6文字が飛地のようにマッピングされている」「この6つの符号、先代の将軍様、キム・イル・ソンと現将軍様、キム・ジョン・イルの
  • Baidu絵文字検索の苦労話、開発者の文字コードマニアが論文に -INTERNET Watch

    no_ri
    no_ri 2010/03/10
    文字コードもそうだけど、絵としての印象で使い方が全く異なる事に興味が。国際化しても解釈にかなり差が出るだろうな。
  • 絵文字が開いてしまった「パンドラの箱」第7回--そして舞台はダブリンから東京へ

    地図が国際規格にふさわしくない理由 2009年4月21日、ここはアイルランドのダブリン・シティ大学です。ISO/IEC 10646を審議する第54回WG 2会議は、2日目の日程に入っていました。この日はいくつかの分科会に分かれテーマ別に審議が進められます。そのうちの一つ、Emojiアドホック会議では、GoogleAppleによって提案された絵文字の審議がおこなわれていました。 開催前は激しい対立が予想されていましたが、いざフタを開けるとGoogleAppleが一員であるアメリカ・ナショナルボディ(以下、ナショナルボディはNBと略)の大幅な妥協によって合意が成立していきます。残ったのは議長が後回しにしておいた「議論の余地のあるもの」だけになりました。 これは全部で3種類あります。まずは5文字の「日文化に依存したアイコン文字」です。どんな文字か確認してみましょう。 図1 日文化

    絵文字が開いてしまった「パンドラの箱」第7回--そして舞台はダブリンから東京へ
    no_ri
    no_ri 2010/02/25
    『ここまで絵文字の審議では、原規格のオーナーであるはずの日本のキャリアは積極的な発言をしていません。』
  • 新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH(クロステック)

    普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。     (日経コンピュータ) 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ

    新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH(クロステック)
  • 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/

    UnicodeとUTF-8の違いは? - Humanity
  • 論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)

    _文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不

    no_ri
    no_ri 2009/09/25
    『文字エンコーディングのバリデーションは基盤ソフトウェア側の担当になる *べき* 』私もそう思います。
  • ファイル名にDEL文字が使える! - Windows Script Programming

    意外なことに、ファイル名にDEL文字(�)(0x7F、127)が使えます。それも短いファイル名に使えます。ということは、DOS時代からの仕様? エクスプローラではCTRL+BSで入力できますが、コマンドプロンプトでは入力できません。 しかし、エクスプローラでは見えません。コマンドプロンプトでは見えます。 他の制御文字(0x00~0x1F)が使えないのに、DEL文字だけが使えるのは「一貫性のない仕様」です。 また、入力できるのに表示されない「仕様の非対称性」はセキュリティ上の脆弱性の懸念があります。

    ファイル名にDEL文字が使える! - Windows Script Programming
  • UTF-16の動的コンテンツにおけるXSS - masa141421356’s blog

    charset指定を明示しない動的なUTF-16のHTMLでは、 動的に生成した部分に1バイトで文字を表現できるエンコーディングで HTMLのタグと認識できるようなバイト列を注入することでXSSが成立する。 例: UTF-16(BE,BOMなし)で生成されるレスポンスが <html><head> <title>ユーザー入力文字列</title> </head> <body>AA</body></html>の場合。(便宜上改行していますが実際には改行されていないものと思ってください) ユーザー入力文字列のUTF-16でのバイト列が hex表記で 3C 2F 74 69 74 6C 65 3E 3C 73 63 72 69 70 74 3E 61 6C 65 72 74 28 64 6F 63 75 6D 65 6E 74 2E 63 6F 6F 6B 69 65 29 3C 2F 73 63

    UTF-16の動的コンテンツにおけるXSS - masa141421356’s blog
  • 第6回 先行バイトの埋め込み | gihyo.jp

    今回は、「⁠先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式(文字エンコーディング)においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />

    第6回 先行バイトの埋め込み | gihyo.jp
  • 第5回■注目される文字コードのセキュリティ問題

    今回から5回にわたって,アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか,疑問に思うかもしれないが,Webアプリケーションで文字コードを指定可能な個所は非常に多く,しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている(図1)。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では,ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して,文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは,セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう

    第5回■注目される文字コードのセキュリティ問題
  • 文字コードをまとめようとして挫折した - Webと文字

    土日でできませんでした。 進捗率:10%ぐらい 目標:符号化方式を追加すること ∧,,∧    僕には無理でした ( ´・ω・) c(,_U_U      ・゚・。・ ゚・。・゚・ 。・゚・ ━ヽニニフ PDF:http://www.geocities.jp/project_the_tower2/web_mozi/code/matome.pdf 右クリックで保存してローカルで開いてください。 OpenOfficeDrawで作ったファイル:http://www.geocities.jp/project_the_tower2/web_mozi/code/matome.zip ダウンロードしたら、拡張子をodgに変えてOpenOfficeで開いてください。 追記1 ブクマがいっぱいでびっくり。ダウンロード先のリンクを修正します。いいか、見て幻滅するんじゃないぞ(´・ω・`)!当は修正したい箇所

    文字コードをまとめようとして挫折した - Webと文字
  • Unicode Web Traversal | 鳩丸ぐろっさり (用語集)

    用語「Unicode Web Traversal」についてUnicode Web Traversal (ゆにこーどうぇぶとらばーさる)話題 : セキュリティ かつて IIS に存在した脆弱性で、「Unicodeバグ」とも呼ばれます。これは、冗長な符号化がなされた UTF-8 の文字列を含む URL によって、来アクセスできてはならないものにアクセスできてしまうという Path Traversal の問題です。Microsoft はこの問題を MS00-057 (www.microsoft.com) および MS00-078 (www.microsoft.com) として公開、修正プログラムを提供しています。 ※名前だけ聞くと Unicode 系の符号化方式全般の問題のように思えますが、これは UTF-8 に固有の問題で、UTF-16 ではこのような問題は発生しません。 たとえば、スラッシ

  • [その他]フォーマット制御文字 - 2008-06-23 - T.Teradaの日記

    ECMA-262 3rd Edition(和訳)を見ていたら、7章にこんなことが書いてあるのを見つけました。 フォーマット制御文字は ECMAScript プログラムのソーステキストのどの場所に出現してもよい。これらの文字は、字句文法を適用する前にソーステキストから取り除かれる。文字列と正規表現リテラルの処理前にこれらの文字が取り除かれるので、文字列、正規表現内に Unicode 制御文字を入れるには Unicode エスケープシーケンス (セクション 7.6) を使用しなければならない。 This Document has Moved ざっとCfカテゴリ(プロパティ)の文字で調べてみると、IEでは無視される(取り除かれる)ことはありませんでしたが、Firefox2では以下の文字が無視されました。 U+200C: ZERO WIDTH NON-JOINER U+200D: ZERO WID

    [その他]フォーマット制御文字 - 2008-06-23 - T.Teradaの日記
  • Oracle Java Technologies | Oracle

    Java Is the Language of Possibilities Java is powering the innovation behind our digital world. Harness this potential with Java resources for student coders, hobbyists, developers, and IT leaders.

  • UTF-7によるXSSからの防御方法 - 葉っぱ日記

    たぶん UTF-7 XSS Cheat Sheet を読んだ人の感想: http://twitter.com/nyaxt/statuses/596330132より 残念ながら違います。伝え方がヘタクソでごめんなさい。 UTF-7によるXSSを防ぐには、以下の対策をとれば大丈夫です。 文字エンコーディング(charset)を明示する(できればHTTPレスポンスヘッダがよい) HTTPレスポンスヘッダではなく、<meta> で指定する場合には、<meta> より前に攻撃者がコントロール可能な文字列をおかない 指定する文字エンコーディング名は、ブラウザが確実に認識できる名称とする この3点を守っている限り、UTF-7を利用したXSSは発生しません。 iframeを使用するのは、攻撃者の作成した罠ページです。ターゲットとなるページのcharsetが不明瞭な場合、罠ページ内でターゲットとなるページを

    UTF-7によるXSSからの防御方法 - 葉っぱ日記
  • ha.ckers.org web application security lab - Archive ≫ IE8.0 US-ASCII and Other Stuff - ripjyr's blog

    なんか動きがFireFoxとIEで違うそうだ・・・詳しくは理解出来ない・・・ I’ve found a discrepancy between IE and Firefox that I think is worth noting. Most of the time this isn’t an issue but most web-pages decode Unicode inputs, so the fact that Firefox automatically encodes every GET parameter with Unicode is not a big deal. However, if the page doesn’t do any conversions, but rather echos the data back exactly as it was seen Fi

    ha.ckers.org web application security lab - Archive ≫ IE8.0 US-ASCII and Other Stuff - ripjyr's blog
  • 404 Blog Not Found:perl - Encode 入門

    2008年04月09日01:00 カテゴリLightweight Languages perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ 入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これがすべてです!とにかくこの基方針をまもっていれば幸せになれます。ここでは、EUC-JPでエンコードされたファイル中の「小飼弾」「こがいだん」「コガイダン」「Kogai Dan」を正規表現で書き換えて標準出力にEUC-JPで出力するプログラムを例にとって説明します。 decode() then encode(

    404 Blog Not Found:perl - Encode 入門
  • 高木浩光@自宅の日記 - はてなブックマークを禁止する技術的方法, 追記, 追記2 (23日)

    はてなブックマークを禁止する技術的方法 ある属性を持つ人々にとって、はてなブックマークは、必要な情報源を巡回するための効率的なツールとなっている。もはや「はてブ」されない記事は存在しないのも同然となってしまている人もいるかもしれない。ソーシャルブックマークサービスはなにも「はてな」だけではないのだが、事実上「はてな」が独占状態にあり(少なくとも一部の分野においては)、「はてなブックマーク」でないと情報源となり得ない状況になっている。この状況はアーキテクチャ的に望ましい状態ではないと思うが、しかたない。 そういう中で一つ問題がある。情報セキュリティの話題を追いかけるには「セキュリティ」タグを見ていればよいわけだが、ここに「JVN」のエントリが出てこない。 JVNの認知度が高まらないのにはいろいろな要因があって、JVNのサイトデザインが最悪だ(ユーザビリティを何も考えていない)という問題も

  • 安全なウェブサイトの作り方 改定第3版 - 葉っぱ日記

    IPAによる「安全なウェブサイトの作り方」の改定第3版が出ていました。あちこちにUTF-7によるXSSネタが出てきているんですが、いくつか気になる点がありました。 まずはP.25から。 HTTP のレスポンスヘッダのContent-Type フィールドには、「Content-Type:text/html; charset=us-ascii」のように、文字コード(charset)を指定することができますが、この指定を省略した場合… 安全なウェブサイトの作り方 改定第3版 (P.25)より。charset をきちんとつけようという例で US-ASCII を示すのはあまり頂けないなと思います。Internet Explorer においては、US-ASCIIの場合は最上位ビットを無視するという問題が2006年から放置されてますので、US-ASCIIを指定してもそれはそれでWebアプリケーション開発

    安全なウェブサイトの作り方 改定第3版 - 葉っぱ日記