Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

unicodeに関するpenaltyのブックマーク (9)

  • LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog

    LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回

    LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
  • UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか?を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏

    何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、(2/3)SQLインジェクションを根絶!セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題:ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『¥』は?」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst

    UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか?を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
  • 第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でのビットパターン

    第4回 UTF-8の冗長なエンコード | gihyo.jp
  • Unicode一覧 0000-0FFF - Wikipedia

    この一覧は、U+0000からU+0FFFまでのUnicodeコードの一覧である。YYY0行X列のコードはU+YYYXであり、HTML文字参照は&#xYYYX;である(環境により表示が異なる場合がある)。 各文字の範囲についてはUnicodeのブロックの一覧を参照。 この項目には、一部のコンピュータや閲覧ソフトで表示できない文字が含まれています(詳細)。

    penalty
    penalty 2009/04/23
    おおお!これは便利!
  • 図解: Perl と Unicode 文字列 - daily dayflower

    id:tomi-ru さんが [http://e8y.net/mag/015-encode/:title] というとてもプラクティカルな [http://search.cpan.org/perldoc?Encode:title=Encode] 入門をお書きになったので,わたしも違う切り口で書いてみたくなりました。 いちおうの基礎(読み飛ばし可) 文字セット, キャラクタセット, 文字集合, 文字集合 - Wikipedia エンコーディング, 符号化方式, 文字符号化方式 - Wikipedia この2つは異なります。とくに知らなくても下記の文書を読むことはできますが,理解しているとためになります。くわしく知りたい人は自習してください。 文字セットの例 Unicode JIS X 0208 ひらがなとかカタカナとか漢字とか ASCII 文字 エンコーディングの例 UTF-8 ISO-202

    図解: Perl と Unicode 文字列 - daily dayflower
  • ISO/IEC 10646 - Wikipedia

    この規格は制定の一歩手前の段階までは、現在の姿とはかなり異なる仕様だった。4オクテットの符号であり、各オクテットをそれぞれ群、面、区、点とする。各面には従来のコントロール領域を避けた0x20 - 0x7Fと0xA0 - 0xFFの範囲に文字を割り当てる。その範囲にISO/IEC 2022に従った構造の各国コード(ISO/IEC 8859やJIS X 0208、GB 2312など)を平行移動してそっくり収容するという、従来のコード系との互換性を最大限に尊重した構成をとっていた。 この案は1990年に国際標準の一歩前の段階のDIS (Draft International Standard) として作成されたが、1991年6月の投票で否決された。その理由は、同じ時期にアメリカの企業群がUnicode仕様を作成したため、同じ目的の規格が2つ作られることを避けることだった。 その後、DIS 106

  • 波ダッシュ・全角チルダ問題 - Wikipedia

    Unicode(ユニコード)は、符号化文字集合や文字符号化方式などを定めた、文字コードの業界標準規格。文字集合(文字セット)が単一の大規模文字セットであること(「Uni」という名はそれに由来する)などが特徴である。 従来、各国の標準化団体あるいは各コンピュータメーカーによって独自に開発されていた個々の文字コードの間には互換性がなかった[1]。ISO/IEC 2022のように複数の文字コードを共存させる方法も考案されたが、例えば日語の漢字と中国語の漢字のように、文字が重複する短所がある。一方Unicodeは、微細な差異はあっても質的に同じ文字であれば一つの番号を当てる方針で各国・各社の文字コードの統合を図った規格である[1]。1980年代に、Starワークステーションの日語化(J-Star)などを行ったゼロックスが提唱し、マイクロソフト、Apple、IBM、サン・マイクロシステムズ、ヒ

    波ダッシュ・全角チルダ問題 - Wikipedia
  • それ Unicode で

    UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。

  • 新しいUnicode符号化方式

    新しい文字符号化方式 戻る リンク 文字符号について ユニコード UTFCP UTFCP2 UTFCP-TABLE 文字符号化方式比較 文字コード用語 UTFCPとUTF-JP 新しいUNICODE符号の必要性 UTF8では、日語に対応する文字(ひらがな、カタカナ、全ての漢字)の符号長が3バイトです。一方、Shift_JISやEUCでは、2バイトで表せます。この意味で、UTF8は、今までの文字コードよりもある意味において改悪されています。この事情は、他国の文字に置いても同様で、例えば、中国語の文字(漢字)においても、今まで2バイトで表せていた物が、UTF8では、3バイト必要になります。これは、欧米/中東圏以外の世界のあらゆる国や言語の文字において言えます。今まで2バイトで余裕を持って扱えていたものを、突然3バイトで扱わなければならないと言われれば、誰でも納得しがたいものでしょ

  • 1