Route 477(2010-07-10)
■ [ruby] Ruby 1.9と波ダッシュ問題に関するメモ ややこしすぎるのでメモ 参考資料： http://gihyo.jp/dev/serial/01/ruby/0004 http://mkosaki.blog46.fc2.com/blog-entry-130.html http://blog.livedoor.jp/dankogai/archives/50488765.html 超参考書： 477414164X UnicodeにはWAVE DASH(U+301C)という文字がある(波ダッシュ) 波ダッシュは、「0時から6時」みたいなときに使われるアレ UnicodeにはFULLWIDTH TILDE(U+FF5E)という文字もある(全角チルダ) チルダは、ダイアクリティカルマーク*1の一種。スペイン語でnの上に付いたりするやつ 見た目はだいたい同じ フォントによっては、波打ち方が
unicode の大文字小文字は大変だなあ - まめめも
ちょっと調べただけですが、面白かったのでメモ。世界は広いですね。バベルの塔ですね。 ß ドイツ語では、ß (U+00DF 、エスツェット) を大文字にすると SS になるらしい。 鬼車 (Ruby や PHP で使われている正規表現エンジン) はこれに対応していて、ignore case にすると、一文字が複数の文字にマッチして驚く。 # coding: UTF-8 p "-SS-"[/-\u00DF-/i] #=> "-SS-" p "-\u00DF-"[/-SS-/i] #=> "-\u00DF-" こういう関係の字は他にもあるみたい。 ref: ftp://ftp.unicode.org/Public/UNIDATA/SpecialCasing.txt İ と ı トルコ語やアゼルバイジャン語では i と I が別の字らしい。i の大文字は İ (U+0130 、点つきの I) で、
ISO/IEC 10646（≒Unicode）でなぜ「ゴミ文字」が増えていくのか?
小形克宏 @ogwata 日本の携帯絵文字を収録する国際会議に出席した話のつづき。この件は書こうか迷ったけど、書いておこう。ISO/IEC 10646（≒Unicode）で構造的に「ゴミ」文字が増えていく件。おかしな点があればぜひご指摘ください。 2010-04-25 23:46:39 小形克宏 @ogwata 一昨日のツィートで、WG 2会議は「対立を前提とした共同作業」だと書いた。自分が通したい主張を相手に呑ませるため、可能な限り妥協する。「ISO/IEC 10646のより良い改訂」という目的から、妥協は美徳とされる。互いに妥協しながら落し所を探る。これがWG 2会議の流儀だった。 2010-04-25 23:52:40
第14回「尭」と「堯」 | 人名用漢字の新字旧字（安岡 孝一） | 三省堂 ことばのコラム
新字の「尭」は、昭和56年10月1日の戸籍法施行規則改正で、人名用漢字になりました。旧字の「堯」は、平成16年9月27日の戸籍法施行規則改正で、人名用漢字になりました。つまり現在では、「尭」も「堯」も出生届に書いてOK。でも、「堯」が子供の名づけに使えるようになったのは、「尭」より23年も後のことでした。 昭和53年11月、法務省民事局は全国の市区町村を対象に、子供の名づけに使える漢字として追加すべきものを調査しました。昭和54年1月25日に発足した民事行政審議会では、この調査をもとに、人名用漢字の追加が議論されました。この時、追加候補となった漢字の一つに、旧字の「堯」がありました。 ただ、旧字の「堯」をそのまま人名用漢字に加えるわけにはいかない、と、民事行政審議会は考えました。というのも、この時点の常用漢字表案(昭和54年3月30日、国語審議会中間答申)には、「暁(曉)」と「焼(燒)」が
円記号問題とウェブブラウザ - はてなるせだいあり
起源 円記号問題の始まりは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 日本
絵文字が開いてしまった「パンドラの箱」第7回--そして舞台はダブリンから東京へ
つまり、キャリア3社が作ってきたサービスロゴの類なのです。しかし、それだけではありません。なぜかこの資料にある「Emoji compatibility symbols」の中には、文字の形が空白になっているものがあります。それを独自に調べて追加したのが以下の表です。といっても、この資料にある符号位置をGmailで送信し取得しただけ。興味深いことに、Gmailではこれらの文字が使えるのですね。 内容を見ると、キャリア3社以外が作ったチケットぴあ関連や、ソフトバンクモバイルの前身であるJフォン関連のロゴなどがあります。これら商用ロゴは、企業が商標登録していたり、企業の著作物だったりするので、ロゴそのものの掲載は避けざるを得ません。そこで「Dashed Box」を使い、「Emoji Compatibility Symbols」という文字の名前にしたのです。 しかしどのような形であれ、商用ロゴが文字
グーグルが絵文字を世界標準に提案した理由--国際化エンジニアに聞くプロジェクトの舞台裏（前編）
はじめに 2008年11月27日、Googleは日本の携帯電話の絵文字をUnicodeに収録する計画を公表した。これまで7回にわたってお伝えしてきた連載「絵文字が開いてしまったパンドラの箱」は、この公表から後の動きを追ったものだ。 では、それ以前の同社は何をしていたのか？ つまり、Googleはどんなプロセスを経て絵文字をUnicodeに提案すると決めたのだろう。今回ご報告するのはこのことだ。 インタビューに答えてくれたのは桃井勝彦氏。氏は大学時代にスカラシップ（奨学金）で渡って以来米国に暮しつづけている。言語学・日本語学を専攻する大学院生、大学教員などの経歴も持ち、1996年に学術界からNetscape国際化部門に入社。2004年にMozilla Japanの設立にかかわった後、2005年にGoogleに移った経験豊かな国際化エンジニアだ。マウンテンビューにある米本社にあって、今回の符号
「プログラマのための文字コード技術入門」書評 - はてなるせだいあり
珍しく書評です。まだ書きかけなんですが、完成を待つと忘れそうなのでとりあえず。 断片的に見た感じとして、現在ある文字コード本では最高峰なんじゃないでしょうか。人に勧める文字コード本としては*1、長らく文字コード超研究がベストだったと思うのですが、今後はこれでしょう。 Ruby 1.8/1.9 ざっと見た限りでは誤りを見つけられませんでした。と、いうわけでこれはよい記述だと思います。 UCS-2 下記で引用を交えつつ紹介していますが、UCS-2は「文字集合」ではなく「文字符号化方式」でしょう。ISOの文書自身でもUCS-2を文字集合であるかのように扱っている記述があるのがアレなんですが、定義を見ればISO/IEC 10646を見てもUnicodeを見ても文字符号化方式だと解釈するのが妥当です。 http://d.hatena.ne.jp/nurse/20090325 http://d.hat
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
「漢字1文字は2バイト」という常識が、大きく変わろうとしている。現在改正中の「常用漢字表」に対応するためには、Unicodeの4バイト文字を使用する必要があるが、それだけでは済まない恐れがある。今後、戸籍や住民基本台帳で使われている文字がUnicodeに追加されると、漢字1文字が最大8バイトになるかもしれない。文字コードに詳しい京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。（日経コンピュータ） 先日公開した『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』の読者から、「今後のシステムでは漢字1文字を最大4バイトで処理すればいいのか」という質問を頂いた。実は、UTF-8あるいはUTF-16で漢字を表す場合、最新のUnicodeにおけるIVS（Ideographic Variation Sequence）を考慮すると、漢
「美乳」で文字化けが直るって本当？
・「美乳」で文字化けが直るって本当？ オンラインＤＶＤ＆ＣＤレンタルなら月々1980円で借り放題のＤＭＭがお得！ えっ？ って聞きなおしたくなるようなタイトルですが、「この『美乳』という文字をヘッダー部分にコメントとして挿入しておくと、文字化けが直る」という話は確かに存在します。ただし、これは大前提としてEUC-JPのページを作成するならば、という話になります。 <HTML> <HEAD> <meta http-equiv=Content-Type content="text/html; charset=EUC-JP"> <!-- 美乳 --> <TITLE>テスト1</TITLE> </HEAD> <BODY bgcolor="#FFFFFF"> このページはアダルトサイトとは無縁です。ヌード画像などは一切ありません。 </BODY> </HTML> では、なぜ、この「美乳」がおまじない
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
Web Encodings - WHATWG Wiki
Goals Document existing practices by describing for each browser The list of supported encodings. The list of supported labels for those encodings. The matching algorithm for labels. Converge the various used algorithms by Defining a list of encodings everyone has to support. Browsers must not support more encodings than on that list. Defining a list of supported labels for those encodings. Browse
「絵文字の議論は、これでいいのだろうか。」へのお答え - もじのなまえ
山本太郎さんのウェブページに以下のような記事が公開されました。 絵文字の議論は、これでいいのだろうか。 「うーん困ったなぁ」というのが最初の印象。絵文字の件については、じつは山本さんにいささかの恩義があるのです。まあそれはともかく、このような議論を提起していただいたことはありがたい限り。なるべく正面からお答えしようと思います。 何に対して「勝った」のか？ 前掲記事中の、以下のご指摘。 審議をした結果、修正提案が受け入れられたことが「勝った」ことに、なぜなるのだろうか。もし「勝った」人がいるなら「負けた」人がいるはずなのだが、一体誰が負けたというのか。それが、不明なのだ。 この「勝った」という認識は、誰かからの攻撃に対抗して修正提案を通すことで反撃し「勝った」ということなのだろうか。しかし、そんな攻撃的な意図を持つ主体とは、一体誰だったのか。GoogleやAppleといった、原提案者のことを
『新常用漢字表（仮称）』の議論の正常化を要望したい
絵文字の議論は、これでいいのだろうか。 Unicodeに携帯電話で用いられる絵文字が提案されてから、絵文字の議論が盛んだ。最近も、小形克宏氏のブログ「もじのなまえ」が、ISO/IEC 10646のAmendment 8の審議状況について報告している。いつもながら詳細な議論をしていて感心するのだが、疑問な点もいくつか見受けられる。 小形氏を含む何人かの人が共同で修正提案をしたN3711が審議されて、グリフの形やコードのマッピングに関する提案が受け入れられた経緯を説明している箇所があり、そこで「われわれは、なぜ勝ったのか」という問いかけをしている。審議をした結果、修正提案が受け入れられたことが「勝った」ことに、なぜなるのだろうか。もし「勝った」人がいるなら「負けた」人がいるはずなのだが、一体誰が負けたというのか。それが、不明なのだ。 この「勝った」という認識は、誰かからの攻撃に対抗して修正提案
文字コードまめ知識
■ JISX0208 → SJIS コードから 0x2121 を引く (コード & 0x100) が０でなければ コードに 0x9E, ０ならばコードに 0x40 を足す 下位バイトが 0x7F 以上ならば コードに 1 を足す [上位バイトだけの処理] 上位バイトを右に１ビット シフトし、それに 0x81 を足す (0xA000 ■ SJIS → JISX0208 (0xE000 [上位バイトのみ] 上位バイトから 0x81 を引き １ビット左にシフトする 下位バイトが 0x80 以上ならコードから１を引く 下位バイトが 0x9E 以上ならコードに 0x100 を足し、 コードから 0x9E を引く。 そうでなければコードから0x40 を引く コードに 0x2121 を足す。
ISO/IEC 2022 ‐ 通信用語の基礎知識
ASCIIの上位互換で、多種ある文字コードを任意に切り替えて使う符号化法を規定する。 7ビットだけで文字を表現する「7ビット符号」と、8ビットを使って文字を表現する「8ビット符号」がある。 7ビット符号は、32個または33個の制御文字基本集合の領域(C0)、および94個または96個の図形文字集合の領域(CL領域)を持つ。 8ビット符号はこれに、32個または33個の制御文字補助集合の領域(C1)、および94個または96個の図形文字集合の領域(CR領域)を追加する。
未来情報産業ブログ
BMLなる放送業界の特殊仕様で使われている符号のようです。 対応するための仕様検証に入りました。 エスケープシーケンス 以下は標準なので良いとする ESC 2/8 F 1バイトGセット G0 ESC 2/9 F 1バイトGセット G1 ESC 2/10 F 1バイトGセット G2 ESC 2/11 F 1バイトGセット G3 ESC 2/4 F 2バイトGセット G0 ESC 2/4 2/9 F 2バイトGセット G1 ESC 2/4 2/10 F 2バイトGセット G2 ESC 2/4 2/11 F 2バイトGセット G3 問題は下。 ESC 2/8 2/0 F 1バイトDRCS G0 ESC 2/9 2/0 F 1バイトDRCS G1 ESC 2/10 2/0 F 1バイトDRCS G2 ESC 2/11 2/0 F 1バイトDRCS G3 ESC 2/4 2/8 2/
絵文字の修正提案をめぐる、ひとまずの総括 - もじのなまえ
ここ数回、ISO/IEC 10646の追補8（Amd8）として審議中だった絵文字に対し、ぼくもふくめた5人が提出した修正案（N3711）にについてご報告してきました。 正確にはまだ最終決着とは言えない段階なのですが、ひとまずここまでの総括をしたいと思います。 WG2東京会議の審議結果について われわれの文書については、絵文字を一括して審議した分科会「Emoji Ad-Hoc meeting」で取り上げられ、その結果は「Emoji Ad-Hoc Meeting Report」の第17条（p.4）に明記されました。 17. In reference to documents N3711, N3713: The Ad-hoc agreed on a basic goal that names and glyphs for Emoji symbols in the UCS should refle
UTF-JP
UTF-JPの特徴 UTF-JPは、UTF-8と同様に、1バイト単位で可変長の多バイト文字を構成し、理論上、全てのUNICODE文字を表せますが、日本語テキストを扱うのに特に優れています。 UTF-JP符号では、ASCII文字(0x00-0x7f)は、1バイト、日本語のうち、JIS第一、第二水準の文字は、2バイト、その他のUNICODE文字は、3バイト以上で表されますので、UTF-8と比べて、日本語を短い符号で表せます。 また、UTF-8同様、テキストを逆戻り可能であり、検索する際も、多バイト文字の途中でヒットすることを簡単に防ぐことが可能です。 日本語の部分は、JIS符号と対応関係のある符号が割り当てられますので、UNICODEへは、変換テーブルを介する必要がありますが、日本語以外の部分は、UNICODEへ直接対応付けることが出来ます。 UCS-2までは、最大3バイトで、UCS-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
asp-edita.jp