UTF-8 の文字列をできる限り Shift_JIS に変換したい - きりきりやま
Shift_JIS の CSV で連携する外部サービスがあり、DB では UTF-8 でテキストを持っていたため文字コードを変換する必要が生じた。 ところが UTF-8 に存在する多くの文字は Shift_JIS に対応がないため変換することができない1。 そこで、事前に NFKC 形式で Unicode 正規化することで変換可能な文字を増やすことを試みた。 まずは Unicode 正規化の前提として、Unicode の正準等価と互換等価について説明する。 以降の U+16進数 という表記は Unicode のコードポイント (文字に ID のようなものが割り当てられている) を示す。 また、コードポイントに対応する文字の詳細は https://codepoints.net/ といったサイトで確認することができる。 正準等価 例として、ひらがなの「が」について考える。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. 同じコードポイ
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第1部 漢字小委員会の考え方と審議状況第1回 なぜ常用漢字表は改定されるのか？
彼等は必死に抵抗しようとしている。「新常用漢字表（仮）」（以下、この連載では新常用漢字表と略）を審議する漢字小委員会を傍聴していると時折そう感じる。何に？ ここ10年顕著になったパソコンや携帯電話の爆発的な普及と、それにともなう人々の急激な変化にだ。巨大なうねりとも言える社会全体のIT化により、私たちにとって「文字を書く」とは、紙に書くより情報機器を操作することを指す方が圧倒的に多くなっている。その状況は今後、進むことはあっても決して無くなることはない。影響は私たちの暮らし全体に及んでおり、すでに誰にも否定できない現実となっている。 国語施策の根本である常用漢字表が制定されたのは1981年、すでに27年もの歳月が流れている。今回の改定はその間に起きた「書く」環境の急激な変化に対応しようというものだ。常用漢字表は法令や公用文を書き表わす場合の指針になっており[*1]、改定されれば官公庁は新し
URI(URL)における非ASCII文字の憂鬱 - WebStudio
URI(URL)には、%7Eといった形式でASCII以外の文字を扱えます (RFC 3986 2.1では、これをパーセントエンコーディングと記述していますが、 この文書ではエスケープと記述しています。ご注意ください)。 これは同時にあらゆるバイナリデータの列をURIに含めることができることを意味します。 つまり、アンエスケープを行ったURIはどのような仕様にも依存せず、単なるバイナリ列となることを意味します。 通常、利用者の側から考えるとこの事実は何の問題もありません。 しかし、URIを扱うアプリケーションがURIをできる限り人間に読みやすい形で表示しようとした場合に様々な問題が発生します。 そういった情報を少しだけここで紹介したいと思います。 Webページの作成者の方も是非、一度目を通しておいてもらえれればと思います。 Webページの作成者はURIをHTML/XHTML等に記述する場合、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第2回 住民基本台帳ネットワーク統一文字