文字コード嫌いだ - Qiita
WEBシステムの構築をしていて、文字コード関連でつまずくことがよくある。 そのたびに、何やったけ？って悩むことが嫌なのでまとめていきます。文字コード関連は、ほんとにめんどくさくていやだ。クライアントも、サーバもDBも全部UTF-8にしてやれば良いのに。。。 全角チルダ問題 簡単にいうと、SJISとUTF-8で文字コードもマッピングがずれている問題。 なんでこんなことになっているのか。。。 どのような事象か 見た目がほぼ同じな「〜」（波ダッシュ）、「～」（全角チルダ）という二つの文字がそれぞれUTF-8で「0x301C」「0xFF5E」の文字コードが割り当てられています。しかし、Sjisでは、「〜」（波ダッシュ）が「0x8160」、「～」（全角チルダ）は対応なしとなっています。そのため、SJISに変換するときに対応する文字がないということがあり得てしまいます。 ■SJISとUnicodeの変
「ユニコード」で予期せぬ目に遭った話 - moriyoshiの日記
自分の知らないCJK Ideographのバリエーションがまだあったことに戦慄している pic.twitter.com/kUlyRLDDTM— moriyoshit (@moriyoshit) March 9, 2017 などというツイートをしたところ、思ったより反響があったのでまとめておく。 上記ではあいまいに「バリエーション」などと書いたが、Unicodeとそれを扱う環境においては、バリエーションと一口に言っても次のような状況がある。 意味論的に等価な異なる字形の集合 同じ字形で異なるコードポイントの集合 aは結構なじみ深いと思う。 a-1. 異なるコードポイントにそれぞれ異なる字形が割り当てられているもの 例: 「東」(U+6771) ⇔「东」(U+4E1C) 「斉」(U+6589) ⇔「齊」(U+9F4A) 「高」(U+9AD8) ⇔「髙」(U+9AD9) a-2. 同じコードポイ
IVD/IVSとは | 文字情報基盤整備事業
IVS(Ideographic Variation Sequence/Selector)は、文字符号としては同一視される漢字の、細かな字形の差異を特別に使い分けるための仕組みです。IVSは文字符号の国際規格であるISO/IEC 10646(2008年版以降)に規定されています。また、IVSと、それに対応する字形の一覧は、UnicodeコンソーシアムからIVD(Ideographic Variation Database)として公開されており、ISO/IEC 10646から正規の規格として参照されています。 文字符号（文字コード）を定める日本工業規格のJIS X 0213(以下、JIS)やISO/IEC 10646 Universal Coded Character Set（以下、UCS）などでは、複数の字形に対して一つの共通な符号（コード）を与える場合があります（「同一の符号位置に複数の字
円マークとバックスラッシュ
文字コードの話題です。発端は「ソースコードのバックスラッシュを円マークに統一していいですか?」という編集の方からのツッコミでした。すっかり、Unicode馴れしていた私は、もはや円マークなんて目にしなくなって数年。HTMLに含める時は、¥ と明示的に書く場面でもなければ、基本「バックスラッシュ」がデフォルトになっていました。 改めて「円マーク」で良いのか…と聞かれて、どうも自信が無くなったので、記憶を掘り返してみることに。 SJIS時代は文字コードにそもそもバックスラッシュが含まれず、円マークが代用されていたわけですが、それがUnicodeになりちゃんと分けましょう、という話に当然なります(当たり前!)。そして、円マークには別途「00A5」が割り振られた、という経緯のようです。 ※UTF8の場合、正確には「C2A5」に割り振られます。 Unicode (あるいは Latin 1)
fudist - Shift_JISのダメ文字
Shift_JIS(SJIS, cp932) の文字コードで、2byte目が0x5c の \ になっているものの俗称(だめ文字、駄目文字) 0x5cの \ は使用するフォントやロケールによりバックスラッシュまたは￥記号で表示されます。 ダメ文字を含む文字列やパス、ファイル名を処理する場合には文字化け、検索不可など様々な不具合が起きることがあります。 ダメ文字には ー ソ 十 表 など、使用頻度の高いものもあるので cp932を扱う場合には注意が必要です。 また広義には2byte目が 0x7c のパイプ文字 | になっている文字や、2byte目が正規表現などのメタ文字と重なる文字も含む場合もあります。 ダメ文字問題は正規表現をはじめとする様々な言語、システムで制御用のメタ文字として扱われる文字と同じバイト列が、SJISの漢字の2byte目に含まれていることにより起こります。 特に 0x5c
JIS X 0208 (1990) to Unicode 漢字コード表
unicodeの変換表はユニコードコンソーシアムのものを使用しています JIS X 0208 (1990) to Unicode UTF-8、UTF-16のコードがない文字は実体で表示されていても自分の環境に依存している可能性があります 機種に依存しない観点より、ＨＴＭＬでUTF-8、UTF-16のコードがない文字は使用すべきではありません 逆にUTF-8、UTF-16のコードがあるのに実体が表示されない場合は（無いと思いますが）SJISでの自分の環境がよほど悪いと考えるべきです JIS X 0208 (1990) to Unicode 漢字コード表 区 点 JIS SJIS EUC UTF-8 UTF-16 実体(SJIS) 01 01 2121 8140 A1A1 E38080 3000 01 02 2122 8141 A1A2 E38081 3001 、 01 03 2123 814
西村賢さんのPython内部文字コードの話題から端を発するUnicodeの話
K.Takata @k_takata 「Unicode文字列型が複数の内部表現をサポート」ってどういうこと？「Python 2系からの移植を容易にするため…Unicodeリテラルシンタックスも復活」これは良い。 http://t.co/LxkUP45x 2012-03-06 21:44:00
文字符号値参照道具 [JavaScript版]
符号値→文字 希望の符合値を選択して、16進数表記で数字を入力すると、 それに対応した文字が、その下の文字入力領域に反映される。 数文字分まとめて入力することも可能で、 その場合、途中にいれた空白文字は無視される。 文字符号によっては、変換表を再構築するので、 最初の実行時に処理が遅くなるが、 二回目からは通常の速度に戻る。 文字→符号値 文字を入力して、調べたい符号化を選び、好みの文字属性を選ぶことで、 それらの文字に対応する符号値を 16進数表記で、 表として下の領域に出力する。 文字集合 ( Coded Character Set ) 日本語を表記するための文字集合として、次のものがある。 Unicode 16進数で 0 ～ 10FFFF の範囲に約100万字分の文字領域を確保して、 全世界の文字を扱えるようにしたもの。実際には 10万字程度が定義され
複数の事象を混同しがちなVistaの文字問題
既にいくつかの記事で報道されているように，Windows Vistaでは，JIS X 0213:2004（JIS2004）と呼ぶ規格に対応し，利用できる文字数が増えるとともに一部の文字の形が変わる。そのことで，Windows Vistaを使うと文字に関して何か問題を起こすかのように思われている節があるようだ。 私が書いた記事でも，「これらの文字を使ってWindows Vistaで作った文書を，JIS2004に対応していない既存のWindowsで開くと，『・』や『■』などで表示される恐れがある」と記述しており，読者に対して余計な不安を与えてしまったかもしれない。また，「追加文字を使った文書を保存するときは，エンコーディングをUnicodeにする必要がある」との記述は，Windows Vistaだけのことかと誤解を与えてしまったかもしれない。これは，後で説明するようにWindows 98/NT
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
文字符号化方式 - Wikipedia
文字符号化方式（もじふごうかほうしき、英: character encoding scheme、CES）とは、符号化文字集合で文字に対応付けた非負整数値を、実際にコンピュータが利用できるデータ列（通常、バイト列）に変換する符号化方式。 文字符号化体系、文字符号化スキーム (CCS) とも言う。文字について述べていることが明確なときは、単に符号化方式、またIBMの用語ではコード化体系 (ES) などとも言う。 この用語はUnicodeやIETFの標準などで用いているが、ISO/IECやJISの標準では用いず「符号化文字集合の構造」あるいは「文字符号の構造及び拡張法」として扱われている。この用語の定義は、世界の文字コード規格とは必ずしも合致しないことがある。 符号化文字集合と文字符号化方式[編集] 符号化文字集合とCESの関係を示すため、JIS X 0208を例にとる。なお、話を簡単にするため
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
特番 Windows Vistaの新文字セットが引き起こすトラブル：ITpro
【記者の眼】 Unicodeは「使える」から「知らずに使う」フェーズへ Windowsにおいて「Unicode」は，長らく「使える」けれども「あまり使われない」存在だった。その状況が「Windows Vista」と「the 2007 Microsoft Office」で変わろうとしている。この2製品に付属する「Microsoft IME」で，「WindowsではUnicodeでしか扱えない文字」が，変換候補として頻出するようになったからだ。Unicodeはいよいよ，一般ユーザーが「知らずに使う」存在になるだろう。 【記者のつぶやき】 シフトJISを捨てられるか? これまで，Windows Vistaの文字の扱いに関する事柄を何度か取り上げてきた。同じキャラクタ・コードで，Windows XPのときと文字の形が変わったり，Unicodeでしか扱えない文字があったりするという話題だ。今
文字コード規格の基礎：ITpro
この記事は，日経ソフトウエア 1999年10月号に掲載したものです。それ以降の情報が盛り込まれていませんので，現在とは異なる場合があります。 文字コード規格の基礎を手早く理解したい場合などにお役立てください。 文字コードは間違いなく情報を交換するための「決まりごと」なので，正確を期すため厳密な仕様が規定されている。だが，その仕様そのものを実装するプログラムを作る場合を除けば，プログラマが仕様の詳細を隅々まで理解している必要はない。六法全書を読んでいなくても問題なく普段の生活ができるようなものだ。 ここでは，通常のプログラミングをするうえで必要と思われる範囲のことを，なるべく簡潔に説明したい。「半角カナ」のような呼び名は正確さを欠くものだが，多くの人に伝わりやすいので説明の中でも使っていく。説明を簡略化するため「正確な仕様を知りたいときは規格書そのものを必ず参照してほしい」と書きたいところだ
「Vistaの新文字セットが引き起こすトラブル」特集 - Cafe Babe
IT Proに特集ページができている． http://itpro.nikkeibp.co.jp/99/vista/index.html 私は，次の3つの段階で問題が発生すると予想している． 文字の表示（フォント変更に伴う字体変更） 内部でレガシーエンコーディングを用いたシステムの入・出力（新しく追加された文字） 内部でUnicodeを用いたシステムのテキスト処理のバグの顕在化（文字列操作，文字列長取得，未正規化文字列との比較，文字列合成など） この特集をざっと見て思うのは，最初の字体変更の問題に偏りすぎているようなこと．開発者にとっては，それ以降の問題の方が，まさに自分自身の責任になるので深刻かもしれない． 二番目に関しては将来的なシステムのUnicode化はもう避けられないと思っているので，その移行までをどううまく凌ぐかという問題に置き換えられるかもしれない． また，三番目は補助文字の登
MySQL 文字化け問題を本気で直す
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UnicodeのWAVE DASH例示字形が、25年ぶりに修正された理由 
http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT
Unicode table for you