Your code displays Japanese wrong
A static site to link people to when their code is displaying Japanese wrong. View the Project on GitHub heistak/your-code-displays-japanese-wrong Why am I here? If someone gave you a link to this page, that person probably thinks your code displays Japanese wrong. In short, from a native Japanese eye, yѳur ҭєxҭ lѳѳκs κιnd ѳf lικє ҭЋιs. This page will give you a brief description of the glyph appe
楽しい文字コード入門 知っておきたいUnicode Emoji編
Bizreach Tech Beer Bashでの発表資料です
四半世紀ぶりにWAVE DASH 例示字形が統一
小形克宏 @ogwata Hiroyuki Komatsu, “Proposal for the modification of the sample character layout of WAVE_DASH (U+301C)”, std.dkuug.dk/JTC1/SC2/WG2/d… [PDF] 2015-01-23 11:03:30
Character Code on Basic Resident Registration Network in Japan
2012年4月6日付，最高裁判所事務総局経理局一般競争入札「裁判員候補者に対する通知書等の印刷，発送及び集計等の業務 一式」の官報公告には，以下の条件が付されていた。 本件業務の通知書等の印刷物は，ＫＡＪＯ＿Ｊ明朝フォントを利用したものを作成すること。 実は，裁判員候補者予定者名簿システムや，後期高齢者医療広域連合電算処理システムには，住民基本台帳ネットワーク（以下，住基ネット）に使われている文字コードと，同一の文字コードが用いられている。いわゆる住民基本台帳ネットワーク統一文字（以下，住基文字）と呼ばれている文字コードだ。ところが，この入札公告では，住基文字の使用を，入札条件として書いていない。その代わり，「ＫＡＪＯ＿Ｊ明朝」という住基文字と互換なフォントを指定することで，結果として使用する文字コードを，住基文字に決め打ちさせているわけである。 ではなぜ，この入札公告は，住基文字の使用を
Appleカラー絵文字文字コード表(UTF-16) - mixi engineer blog
期末のお忙しいところ失礼致します。iPhoneアプリ開発担当の七尾です。 iOS5がリリースされてしばらく経ちましたが、iOS5の新機能のひとつである、Appleカラー絵文字についてUTF-16な文字コード表を作りましたので、お知らせ致します。 iOS Emoji - GitHub Pages テーブルの横幅が大きくなってしまったので、GitHub Pagesに乗せてしまいました。 また、画像数が多いので、GitHub Pagesで公開しているものは、カテゴリごとのhtmlに分割しています。統合版htmlはmasterブランチに入っていますので、必要な方はそちらをご利用ください。 iOS5からどこでも入力できるようになった絵文字は見た目はSoftbankのUnicode絵文字ですが、実体はAppleカラー絵文字(Unicode6互換)に変わっています。 ちなみに従来のSoftbank Un
制御機能用記号: ユニコード 2400-243F 文字一覧表(入力Web検索) - 3rdpageSearch Jp
制御機能用記号(Control Pictures): Charset=UTF-8 ユニコード(Unicode)文字 2400-243F
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
C/C++に文字エンコーディングバリデーション機能がないって、ほんと？ - kazuhoのメモ置き場
通りすがり (2009-09-16 18:09) > PHP以外の言語は「(略)」のに対し ここに挙げられている言語がWebアプリで使われる全ての言語ではない。 例えば、CやC++にはない。付け足せば、PHPやPerlなどのCモジュール内部で起こった不正な文字はスルーされうる。 よって、「Perl、Java、.NET、Ruby、PHPの中では」と書けば筋は通るが、「PHP以外では」は誤り。 そしてそんなことを、PHPの(脆弱性撲滅に注力している)開発者に言ったら、喧嘩を売られたと受け止められて当然。 PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14) というコメントが気になった。 C言語にある文字コード変換機能って言ったら mbtowc だと思うけど、mbtowc は無効なバイト列を受け取ると EILSEQ を返すことに
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
ミケネコの 文字コードの部屋
とっても楽しくて、どうでもよくて、奥の深い、そんな魅惑の世界。 Perl で文字コード jcode.pl の私的な解説書 CGI での日本語処理ですっかりおなじみの、jcode.plについての解説です。 文字コードいろいろ 第 1 章 文字セットの種類 : 日本の文字セットの変遷 JIS X 0201 (ANK) JIS X 0208 (漢字・ひらカタ・JIS 第 1、第 2 水準) JIS X 0212 (JIS 補助漢字) JIS X 0213 (JIS 第 3、第 4 水準) JIS X 0221 (Unicode) 第 2 章 文字コードの種類 : ASCII、SJIS、EUC-JP などなど ASCII ISO 646 ISO 8859 シフト JIS コード ISO-2022-JP EUC-JP EBCDIC EBCDIK NEC 漢字コード TRON コード 第 3 章 Un
#06 文字コードのバッドノウハウ［最終回］ | gihyo.jp
ソフトウェアなどを使いこなすために、ストレスを感じながらもしぶしぶ覚えなければならないようなノウハウ、「バッドノウハウ」がテーマの本連載、最終回の今回は文字コードのBKを取り上げたいと思います。 文字コードとバッドノウハウ 文字コードは、Web開発を行う上で避けては通れない分野です。文字化けを起こさずに、コンテンツをブラウザに正しく表示させることはWeb開発の基本といえます。 しかしながら、文字コードには歴史的な紆余曲折がいろいろあり、膨大なバッドノウハウが人類の英知として蓄積されています。今回は、その膨大なるBKの一部を紹介したいと思います。 機種依存文字は滅びず 文字コードのBKといえば、機種依存文字の存在を忘れてはなりません。インターネットの世界では、古くから「①などの丸付き数字は機種依存文字だから使うな」といわれています。これらの文字はその昔「NEC特殊文字」と呼ばれ、Macとの
第5回 不正なバイト列の埋め込み | gihyo.jp
今回は、「不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて （1) 処理A ＝ 文字列中に特定の文字（あるいは文字列）が含まれていないか検査 （2) 処理B ＝ 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて本来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
この知恵袋めちゃくちゃ笑った！→まさか原因はこれだった！？（笑）
Google
UTF-8の亜種の一つで、Oracleが使っている不届き千万な仕様の一つ。 概要 本来UTF-8(RFC 2279)では、サロゲートペアは適時解釈してから符号化せねばならない。 しかしこのCESU-8は、サロゲートの各ペアを機械的にUTF-8に変換するのみであり、supplementary characterは6バイトで表現される。これはUTF-8の仕様から外れた手法であるばかりか、公害ともなりうる実装である。 しかしながら、Oracleはこのような実装をしてしまった。それを正当化するために、CESU-8
文字コードに起因する脆弱性とその対策
