The Unicode Standard 5.1 Code Charts
Mahjong Tiles Range: 1F000–1F02F The Unicode Standard, Version 5.1 This file contains an excerpt from the character code tables and list of character names for The Unicode Standard, Version 5.1. Characters in this chart that are new for The Unicode Standard, Version 5.1 are shown in conjunction with any existing characters. For ease of reference, the new characters have been highlighted in the cha
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
PDFと文字(16) –漢字統合の破綻 (PDF 千夜一夜: 2006年01月05日 アーカイブ)
PDFと文字（16) –漢字統合の破綻 Unicodeの漢字統合は、中国、日本、韓国で同じ字形の漢字をひとつのコードポイントにまとめた、と言いました(1月3日）。しかし、UnicodeV3.1の統合漢字拡張Bを調べてみますと、UnicodeのCJK漢字統合は破綻してしまったのではないかという印象をもちます。 ここにいくつかその例を挙げます。 １．一般統合漢字と同じ漢字が定義されている例 ○一般統合漢字 ○統合漢字拡張B この2つの漢字は字形が完全に同じものではないでしょうか？なぜ、まったく同じ字形を別のコードポイントに追加したのでしょう？ ２．一般統合漢字に統合されるはずの漢字が別に定義されている例 (1) ハネの有無 ○一般統合漢字 ○統合漢字拡張B この2組の漢字は、ストローク終端のハネの違いです。ストローク終端のハネの違いは、書体の違いとして統合するという例がUnicodeの仕様書に
Unicodeの漢字の不整合: 文字符号化blog
Unicodeの漢字といえば、かつては「CJK統合漢字」が槍玉に上がったものです。統合すること自体を問題にする意見から、統合自体は是としながらもそのやり方に疑問を呈する意見まで様々でしたが、それらに確たる答えが提示されないまま、今や別の面からUnicodeの漢字は批判されています。 それは主に、似たような字が重複して入っている、あるいは同じと思われる文字、統合されるはずの文字が紛れ込んでいる、といったことです。 「PDFと文字（16) –漢字統合の破綻」では、実例を挙げて疑問を提示しています。ここで挙げている例を見て、あるいは「それは別の字だ」と主張される方があるかも知れませんが、同じなのか違う字なのか、判定する根拠 (JISの包接規準のような) が示されていないことがまさにUnicodeの問題だろうと私は思います。 「漢字データベースプロジェクト」では、上記のブログで提示されているような
JIS漢字とUCS (Unicode)の文字の対応・変換について
セント記号 JIS漢字のセント記号(¢)はCENT SIGNである。対応するUCSのコードポイン トはU+00A2である。 ところが、これをUCSのFULLWIDTH CENT SIGNに変換するものがある。ASCII にもJIS X 0201にもセント記号はないので、これが「FULLWIDTH」になる理由 はない。従ってこの変換は不適切である。 ポンド記号 JIS漢字のポンド記号(£)はPOUND SIGNである。対応するUCSのコードポ イントはU+00A3である。 ところが、これをUCSのFULLWIDTH POUND SIGNに変換するものがある。 ASCIIにもJIS X 0201にもポンド記号はないので、これが「FULLWIDTH」になる 理由はない。従ってこの変換は不適切である。 否定記号 JIS漢字の否定記号(¬)はNOT SIGNである。対応するUCSのコードポイント は
安岡孝一の日記: YEN SIGN問題縁起
tarosukeの日記にもコメントしたのだが、YEN SIGN問題の歴史的経緯は、あまり知られていないように思える。そもそも、情報処理学会コード標準化委員会が1965年1月28日に完成した文字コード案では、「¥」は0x24に収録する予定だった。ところが、1966年4月のISO/TC97/SC2 + CCITT/GM ALPパリ会議において、ISO 7ビットコード最終案の0x24は「$」に固定されてしまい、1967年12月22日にISO R 646として制定された。やむをえず日本側は0x5Cに「¥」を移し、JIS C 6220として1969年6月1日に制定した。一方アメリカは、1970年10月のISO/TC97/SC2ロンドン会議において、ISO R 646の0x5Cを「\」にするよう要求してきたが、日本はこれに反対、ISO 646の1973年7月1日改正においても、0x5Cを国内使用箇所と
yasuokaの日記: WAVE DASH問題縁起
Encode - 規格のバグまでは直せませんにコメントしながら思ったのだが、JIS X 0208の1区33点「波ダッシュ」をUnicodeに変換する際、U+FF5EのFULLWIDTH TILDEに変換するのは明らかに間違いだ。この件に関して、私が知る限りのことを、ここに記しておこうと思う。 平成5年度のUCS調査研究委員会WG1において問題となったものの一つが、既存のJISの文字コードとISO/IEC 10646との対応をどうするかだった。JIS X 0208-1990の1区33点「波ダッシュ」に対しては、U+223C、U+223D、U+223E、U+223F、U+301Cが候補となったが、結局U+301Cと対応させることとなった。U+301Cの名前がWAVE DASHだったからである。ただし、ISO/IEC 10646-1:1993のU+301Cの例示字形は、JIS X 0208の「波
Unicode Character Search
Unicode Character Search Query: include Han codepoints? Cancel A-Z index | Search options
Unicode 簡単メモ
本稿は "ファイル名における Unicode" と題してもよい内容になっていて、Unicode の様々な側面のうち、Mac OS X でファイル名を扱う場合に必要となる事柄にのみフォーカスをあてています。そのようにした理由は、あらゆる Mac OS X アプリケーションがサポートすべき領域であるからです。もし Unicode を扱うようなワードプロセッサを作っているような場合には、Unicode に関してここで扱うよりもたくさんの様々な理解が必要になることでしょう。本稿記載の情報の大部分は、Richard Gillam 氏の手になる素晴らしい書籍 "Unicode Demystified" に基づいています。しかし、Mac OS X でファイル名を適切に扱いたいというだけなら、800 ページもあるこの本のボリュームはちょっと多すぎるかも知れません。 訳注："Unicode Demystif
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://people.debian.org/~kubota/unicode-symbols.html
http://www.asahi-net.or.jp/~ez3k-msym/comp/acccoll.htm
既存の日本語文字コードと Unicode の間のマッピングルール
JIS記号の UCS BMP へのマッピングの問題および MS漢字とシフトJISの違い (JIS-UCS mapping issues and difference between JIS and MS-KANJI)
http://www.asahi-net.or.jp/~ez3k-msym/charsets/suppucs1.htm
An Unicode vendor-specific character table for japanese (日本語のUnicodeベンダ依存文字表)
Unicode HOWTO
IBM Developer
全角半角を問わない検索 - サバニFRP
http://www.opengroup.or.jp/jvc/cde/ucs-conv.html
日本の文字コードとUnicodeとの変換についての標準化検討