文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！ 文字コードには、どのような種類があり、それぞれどのような意味を持つのか、といった、文字コードの基本的な概念、従来の文字コードを紹介し、現在のUnicodeの構成を概説し、プログラミングにおいて注意すべき箇所をいくつか取り上げます。 ソフトウェア開発に携わる方の多くは、何らかの形で文字コードに触れることがあるでしょう。文字や記号をコンピュータ上でデータとして扱うには、文字コードの知識が必要不可欠です。 本稿では、書籍『プログラマのための文字コード技術入門』の著者である矢野啓介さんが、知っておきたい基礎知識を分かりやすく解説します。 文字コードとは？ Unicode以前の文字コード Unicodeとその主な符号化形式 UTF-16 UTF-32 UTF-8 Webで文字コードを指定する仕組み
UTF-8にもいろいろある - ザリガニが見ていた...。
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 OSX 10.8 Mountain Lion以前((OSX 10.9 Mavericksでは、Mac仕様なNFDのUTF-8を表示しようとするとエラーになってしまったため、10.8以前の環境で実験した。Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137. ** ** Abort trap: 6
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
PHPのロケールに関するまとめ - hnwの日記
5/3 17:45追記：t_komuraさんに指摘いただいた関数と、さらに僕が調べ直したものを含め、「ロケール設定に従う関数一覧」に25個ほど追加しました。かなり見落としがありましたね…。 PHPのロケール*1まわりについて調査したので、これをまとめてみます。 この記事は「ロケールの影響を受ける関数 - Sarabande.jp」を掘り下げたものです。masakielasticさん、ナイスな記事をありがとうございます。 PHPの文字列型と文字エンコーディング 他のモダンなLL言語と異なり、PHPは文字列の文字エンコーディングに関して何も仮定せず、単なるバイト列として管理しています。つまり、文字エンコーディングの取り扱いは各関数の実装に委ねられています。 下記の通り、これはマニュアルにも記述があるのですが、実に残念なことです。 残念ながら、PHP の各関数が文字列のエンコーディングを判断する
文字コード変換ミスによる文字化けパターンと想定される原因 - drk7jp
とあるシステムでデータベースから引いてきたデータの表示が文字化けするという不具合がありました。 データベース内のデータとしては文字化けしていない状態で格納されていることはわかっていたので、どこかしらの文字変換で化けていることはわかっています。まずはどの誤変換により文字化けするのか原因切り分けのために、decode/encode の組み合わせによる文字化けパターン一覧を作りました。おかげさまでどのパターンに類するものか判別することができ、無事に改修することができました。 その話はまた別にするとして、今も昔も変わらず文字化けに悩む人は意外と多いと思います。誤変換結果一覧は原因解析の参考になると思い、記事としてまとめることにしました。 文字コード変換ミスによる文字化けパターンを可視化するプログラムと一覧表 まずは誤変換を生成する perl スクリプトです。プログラムはとっても簡単で、「文字化けで
住民基本台帳ネットワーク統一文字の完全変更 | スラド
本日2013年4月1日付で、住民基本台帳ネットワーク統一文字が完全に変更された。これまでは、21170字を収録した16ビットコードだった住基文字は、本日を機に16～64ビットの多倍長コードとなり、戸籍統一文字をも全て包含するものとなった。実は、昨年3月におこなわれた「住民基本台帳ネットワークシステムの統一文字の文字種追加作業」の入札は、傍目には不調に終わったかに見えたのだが、その実、追加作業は着々と秘密裡に進められていて、とうとう今日の秘密リリースに至ったわけである。 ウラを明かすと、先週3月26日に起こった住基ネットの大規模障害は、今回の住基文字変更と無縁ではない。本来は、今日の時点で流されるはずだった完全移行の「大号令」が、ミスで3月26日朝にLASDECから流れてしまい、既に移行準備の終わっていた200ほどの自治体のコミュニケーションサーバが、その「大号令」に反応してしまったのだ。ミ
［続報］住基ネット障害の原因は「文字化け」、231市町村に影響
2013年3月26日から発生していた住民基本台帳ネットワークシステム（住基ネット）の障害の原因が、データベース（DB）に情報を書き込む際の文字コードの誤り（文字化け）にあったことや、障害が影響した市町村の合計が231に及んでいたことなどが分かった。総務省が4月2日に発表した（関連記事：全国200の自治体で住基ネットが利用不可能になる障害が発生）。 今回の障害は、自治体にある住民基本台帳システムと住基ネットを接続する「コミュニケーションサーバー」のハードウエアとOSを231の自治体で更新し、それに伴い、コミュニケーションサーバーのアプリケーションに対して、新OSに対応させる修正プログラムを適用することで発生した。 コミュニケーションサーバーのアプリケーションは、氏名・住所・生年月日・性別という4つの「本人確認情報」を、DBサーバーである「Oracle Database」に保存する際に、住基ネ
Twitter時代の文字の数え方 | 配電盤
入力「×」のブラウザでは、「𠮷」が2文字とみなされるため、2文字目まで、つまり「𠮷野」までしか入力できません。 Mozillaの文書には、Unicode code pointsで数えると書いてあるので、そのうち改善されるのかもしれませんが、現時点ではTwitterのために「maxlength="140"」を使うことはできません。 pattern属性 Firefox 21とChrome 27、IE 10、Opera 12.15は、「pattern=".{0,3}"」（任意の文字からなる0から3文字）のような正規表現を使った検証にも対応していますが、やはり「𠮷野家」は4文字とみなされてしまいます。 JavaScript 追記：javascript – でBMP以外のUnicode文字をきちんと扱う（404 Blog Not Found） JavaScriptでは、文字列strの長さをst
ExcelでUTF-8のCSVを開く方法 (CodeZine編集部ブログ)
Unicodeが実装レベルで登場してからずいぶんたった今では、UTF-8のファイルを普通に扱うことが多くなりました。ほとんどのアプリケーションも何なくUTF-8のファイルを読むことができるようになっています。 ところが、です。最近UTF-8のCSVファイルで作業していて、これをダブルクリックしてExcelで開くと文字化けすることに気づきました。 最初はUTF-8からExcelが好きそうなS-JISに変換していたのですが、ちょっと複雑なデータになると「変換できない文字があります」というアラートがでます（長母音記号などが鬼門）。できればUnicodeのままでExcelに読み込ませられないものか。 以前よりマイクロソフト社製品はすべて内部的にはUnicodeを全面的にサポートしているはずなので、読み込ませられないわけはないはず…とおもって検索したりしていたところ解決方法がわかりました。 ＜解決方
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
円記号問題とウェブブラウザ - はてなるせだいあり
起源 円記号問題の始まりは1960年代にまで遡ります。1967 年に文字コード最初の国際規格である ISO R 646 が制定されましたが、その規格では 0x5C をはじめとして一部の文字が置き換え可能になっていました。アメリカの制定した ASCII では 0x5C に対して REVERSE SOLIDUS を割り当てました。一方、日本版である JIS X 0201 では YEN SIGN を割り当てました。 問題の拡大 7bit では扱いきれない文字を扱うため、世界で ISO 646 系のコードを拡張した文字コードが生まれました。日本ではシフトJIS、日本語 EUC、いわゆる JIS コードの三種類の文字コードが現れ、それぞれに多くの亜種が生まれました。では、それぞれの文字コードの 7bit 領域は ASCII と JIS X 0201 のどちらだったのでしょうか。 日本語 EUC 日本
第10回 文字コードが引き起こす表示上の問題点［後編］ | gihyo.jp
前回は、文字コードの引き起こす問題がソフトウェアの処理上だけでなく、人間に対する視覚的な効果という点でも強く影響を与え、攻撃者にとっての強力な道具となることがある、という点について説明しました。今回も前回に引き続き、そのような文字コードが引き起こす視覚的な問題点について説明します。 拡張子の偽装 Unicodeを利用したWindowsにおける拡張子の偽装は、文字コードを利用した視覚的な攻撃の中でも特にインパクトの大きいものだと思います。 Unicodeには多数の文字に加え、さまざまな制御も収録されています。そのような制御コードのうち、U+202E「RIGHT-TO-LEFT OVERRIDE」（RLO）と呼ばれる文字をファイル名に含めることで、見かけ上の拡張子を簡単に偽装することができます。 たとえば、copy-txt.exeという名前の実行可能ファイルがあったとします。 図1 copy
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
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/
htmlspecialchars/htmlentitiesはBMP外の文字を正しく扱えない
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月14日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPの安定版(PHP5.3.0、PHP5.2.11)のhtmlspecialcharsおよびhtmlentitiesには、Unicodeの基本多言語面 (BMP)範囲外の文字、すなわち、U+10000以降の文字を正しく扱えない問題があります。 もっともシンプルな再現コードを以下に示します。 <?php $c = "\xF0\x90\x80\xBC"; // U+1003C $a = htmlspecialchars($c, ENT_QUOTES, 'UTF-8'); echo bin2hex($a) .
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UnicodeのWAVE DASH例示字形が、25年ぶりに修正された理由 
https://tanaka.sakura.ad.jp/archives/001071.html
ダウンロード - PHPカンファレンス2010 テックデイ 講演資料
文字コードに起因する脆弱性とその対策
