芝野さん、安岡さんへのお答え - もじのなまえ
前のエントリへのコメントが長くなったので、新しいエントリを作りましょう。 まずは、ぼくの原稿を読んでくださったことにお礼申し上げます。その上でいただいたコメントを整理しようと思います。一番大きいと思われる問題の部分は、「第2部 新常用漢字表と文字コード規格 第5回 なぜUnicode正規化は生まれたか」にある、1988年9月時点のUnicodeの骨子をまとめたうちの、以下の部分です。 合成ずみ文字を排除し、合成列により符号化する つまり、最初期のUnicodeはアクセント記号付きのラテン文字を符号化する方法として合成列方式だけとしていたのが、UCSと合流する過程の中でISO 8859-1との互換をとらなければならなくなり、1990年3月にこれを廃棄、合成ずみ文字も収録したというのが上記の原稿内容でした。 前のエントリへのコメントでぼくが「ケアレスミス」と書いたものこそケアレスミスで、このコ
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第2部 新常用漢字表と文字コード規格第5回 なぜUnicode正規化は生まれたか
● 互換用文字は、存在するはずのなかった文字 前回までは互換漢字が追加提案しにくくなっている現状について述べた。規格の上から互換用文字／互換漢字といった文字がどのように考えられているかは、次のUnicode規格書の一文に明らかだ。 Conceptually, compatibility characters are those that would not have been encoded except for compatibility and round-trip convertibility with other standards.（概念上からは、互換用文字とは他の規格との互換性及び往復の保全性の目的以外には、符号化されるはずのなかった文字である。） 『Unicode Standard 5.0』2.3 Compatibility Characters（http://www.uni
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第2部 新常用漢字表と文字コード規格第4回 互換漢字をめぐる非漢字圏諸国との「波風」
● 7年前の4月1日に出されたある提案 前回は互換漢字というものがUCSの中では例外的な存在であり、非漢字圏の国々から厄介者扱いをされていることを述べた。今回はまずその実例を見るところから始めよう。少し前になるが2001年4月1日、WG2にアメリカ代表団が提出した文書番号n2326『Proposal to encode additional grass radicals in the UCS』（草冠をUCSに追加して符号化する提案）という書類だ（図1）[*1]。これは新しい文字をUCSに追加する正式な提案書だ。 図1 アメリカ代表団が2001年4月1日に提案した草冠のバリエーション94文字（n2326『Proposal to encode additional grass radicals in the UCS』） 見てわかるとおり、草冠のさまざまなバリエーションが、じつに94文字も提案さ
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第2部 新常用漢字表と文字コード規格第3回 互換漢字という「例外」
JIS X 0213が制定された2001年と現在を分けている大きな状況の変化、それはUCS（＝JIS X 0221＝ISO/IEC 10646≒Unicode）を審議する国際機関WG2で、互換漢字に対する風当たりがより強くなってきていることだ。 将来もしも常用漢字に追加される漢字が新字体だった場合、前回書いたような漢字政策の玉突き現象によって、JIS X 0213で包摂分離せざるを得なくなる文字がある。この場合、分離前と分離後の字体の違いはわずかなものだ。したがってこれをUCSに新しい文字として提案する際は互換漢字になると思われる。ところが最近では、WG2において互換漢字はなるべく認めないようにしようという空気が強くなってきている。だからその審議には強い抵抗があることが予想される。 ● UCSと往復の保全性 そもそもこの互換漢字とはいったい何なのだろう。もともとUCSは、多国間で使用可能な
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第2部 新常用漢字表と文字コード規格第2回 常用漢字表の改定で発生する、漢字政策の玉突き現象
前回はJIS文字コードへの影響をまとめた安岡孝一氏の発表「常用漢字表の拡大はJIS漢字にどういう混乱をもたらすか」を紹介した。これをまとめると、特定の文字を常用漢字表に追加した場合、「漢字政策の玉突き現象」が起き、JIS X 0213で不整合が起こる。 （1）新常用漢字表に文字が追加 ↓ （2）人名用漢字が新常用漢字表に対応し、同じ文字を追加、1字種2字体になる ↓ （3）JIS X 0213は従来包摂していた2字体を区別しなければならなくなり、包摂を分離、その結果不整合が発生する 今のところ一応は安定しているJIS X 0213における包摂の範囲が、他の漢字政策の都合によって分離せざるを得なくなり、これにより不整合が起きてしまうというのが安岡氏の指摘の趣旨だ。これを安岡氏が例に挙げた「箸」で図にしてみた（図1）。 これが発生する条件は「常用漢字表に印刷標準字体と違う字体＝略字体が追加され
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第2部 新常用漢字表と文字コード規格第1回 常用漢字表に、点のない「箸」が追加されると困る理由
ところで、常用漢字表の改定を審議する漢字小委員会や文化庁の人々は、「情報化時代の文字」についてどのように考えているのだろう？ まさかとは思うが、「読めるだけでいい漢字」（第1部第3回参照）を常用漢字表に追加すれば「情報化時代」に対応したことになると思っているのだろうか。あるいは、Webや電子掲示板の漢字使用頻度（第1部第2回参照）を調査しただけで、「情報化時代の文字」の実態がつかめると思っているのだろうか。 ここまで5回にわたり、漢字小委員会がどのように常用漢字表を改定しようとしているのか、具体的な審議経過をたどりながらお伝えしてきた。そこで明らかになったように、改定の理由は「情報化時代」の到来――パソコンや携帯電話等の爆発的ともいえる普及により、人々の間で「文字を書く」ことがキーボード等で「文字を打つ」ことへと変わってきたというような、書記環境の激変に対応しようとするものだった。 では、
第10回 ファイル名の文字コード
これまでファイル・システムを3回にわたって解説してきました。今回はファイル名の文字コードについて解説します。 ファイル名の文字コードは，WindowsやMac OSなどとファイルを交換する場合にしばしば問題になりますので，知っておいて損はありません。今回は仕組みよりも，機能の使い方に重点を当てて紹介します。 Linuxの多言語機能の基本 Linuxのユーザーは世界中にいます。そのため，英語だけでなく，日本語を含む多くの言語をサポートしています。日本で販売されている日本語版の Linuxディストリビューションでも，設定を変更するだけで他の言語を利用できるようになっているものがほとんどです。では，どのようにして多言語をサポートしているのでしょうか。 Linuxは，locale（ロケール，またはロカール）と呼ばれる仕組みで多言語をサポートしています。localeには，どの国のどの言語か，文字コー
Vista で導入される JIS X 0213:2004(JIS2004) のまとめ（お勉強編）
「日本語文字セットがVista最大の問題として急浮上：ITpro」 が初めのネタになったのですが、なかなか時間もとれず、この記事を書き始めてはや３週間も経ってしまいました・・・orz Windows Vistaは、新しい文字セットに関するJIS規格「JIS X 0213:2004」に準拠した日本語フォントを標準で搭載する。これにより、既存の漢字のうち122文字の字形が変更になり、約900文字の漢字、約200文字の非漢字（英語の発音記号や記号、アイヌ文字など）が新たに表示可能になる。 〜中略〜 さらに、追加される新しい文字の一部をUnicodeで表現すると、通常の2バイトではなく4バイトで表現されるものがある。 をみて、SJIS → UTF-8 → SJIS とかやると文字化けするものとかでるじゃん！大丈夫だっけ？大丈夫じゃなかったら、どんな対策をとったらいいんだっけ？ってのを考察しています
シフトJISの拡張文字
JISコードの区点では、9~15区と85~94区を未定義とされてゐる。然し、シフトJISでは、13区と89~92区と115~119区の部分に対し独自に漢字などの文字の割当てを行つてゐる。 此処では、この件についてunicode(utf-8)と絡めて説明し、併せて正漢字の使用についての留意点を纏めておきたい。 本論 「拡張文字」の一覧表 13区(0x8740~0x879E) ①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ・㍉㌔㌢㍍㌘㌧㌃㌶㍑㍗㌍㌦㌣㌫㍊㌻㎜㎝㎞㎎㎏㏄㎡・・・・・・・・㍻〝〟№㏍℡㊤㊥㊦㊧㊨㈱㈲㈹㍾㍽㍼≒≡∫∮∑√⊥∠∟⊿∵∩∪・・ 89区(0xED40~0xED9E) 纊褜鍈銈蓜俉炻昱棈鋹曻彅丨仡仼伀伃伹佖侒侊侚侔俍偀倢俿倞偆偰偂傔僴僘兊兤冝冾凬刕劜劦勀勛匀匇匤卲厓厲叝﨎咜咊咩哿喆坙坥垬埈埇﨏塚增墲夋奓奛奝奣妤妺孖寀甯寘寬尞岦岺峵崧嵓﨑嵂嵭嶸嶹巐弡弴彧德 90区
PDF 千夜一夜: 2008年04月15日 アーカイブ
日本語ワープロやエディタのビジネスは成立するのだろうか？続き 昨日のブログを、今、読み返してみますと、タイトルと本文の記述内容が随分と食い違っていたようです。 エルゴソフトの沿革を見てみますと、EGwordは本当にすばらしい評価を得ていますね。残念ながら私は足元にも及びません。脱帽するしかありません。 しかし、エルゴソフトは、ワープロ事業を終了してしまったわけです。これは一体なぜなのか？どうしたら良かったのでしょうか？ 少し前になりますが、2月7日～14日にかけて「コンピュータ組版の奇跡２」についてお話しましたときも、同じようなことを考えました。 アンテナハウスは、XSL-FOとかPDFとか、ワープロなどと比較的近い分野のビジネスが中心ですので、この問題は、実は、ほとんど毎日のように自問自答している課題なのですが、なかなか、簡単な回答を出すことはできません。 市場ということで言いますと、1
Shift_JISにおける危険な文字まとめ
今時Shift_JISでプログラミングするバカな奴はいないだろうけど折角まとめたので公開 2バイト目がアスキーコードど丸被りしているものを列挙する@[\]^_`{|}~405B5C5D5E5F607B7C7D7E81 ー―‐／＼??＋??±×82・・・・・・Ａ・・・・83ァゼソゾタダチボポマミ84АЪЫЬЭЮЯклмн85・・・・・・・・・・・86・・・・・・・・・・・87????????・????・・・??88・・・・・・・・・・・89院閏噂云運雲荏閲榎厭円8A魁骸浬馨蛙垣柿顎掛笠樫8B機擬欺犠疑祇義宮弓急救8C掘啓圭珪型契形鶏芸迎鯨8D后梗構江洪浩港砿鋼閤降8E察纂蚕讃賛酸餐施旨枝止8F宗充十従戎柔汁旬楯殉淳90拭深申疹真神秦須酢図厨91繊措曾曽楚狙疏捜掃挿掻92叩端箪綻耽胆蛋畜竹筑蓄93邸甜貼転顛点伝怒倒党冬94如納能脳膿農覗倍培媒梅95鼻票表評豹廟描府怖扶敷96法房暴望某棒冒本翻凡
第1回: Unicode から Shift_JIS への変換(その1) - 葉っぱ日記
Windows 上で Unicode を扱う場合に発生するセキュリティ上の問題点などについて不定期に書いていくことにします。以前の内容と重なる部分も多いですし、時間的にもどこまで書けるかわかりませんけれど…。 さて第1回目は、 Windows 上で Unicode を扱う際のもっとも基本とも言える WideCharToMultiByte を使用した Unicode から Shift_JIS (コードページ932)への変換についてです。 WideCharToMultiByte を使用する際に発生しやすい問題点は以下の2点です。 バッファサイズの指定ミスによるバッファオーバーフロー Unicode から Shift_JIS への変換における多対一のマッピング バッファサイズの指定ミスによるバッファオーバーフロー 変換前の Unicode の文字列は「文字数」で指定するのに対し(cchWideC
ディベロッパー製品開発統括部 Blog : Silverlight 4 Runtime がリリースされました
マイクロソフトのディベロッパー製品開発を担当している部署です。 Silverlight 4 SDK/Tools 正式版が公開されました 先週からになりますが、 Silverlight4 SDK および Visual Studio 2010 用の開発アドインが公開されました。... Author: DDJPNVS Date: 06/15/2010 Small Basic 0.9 がリリースされました 前回のリリースから大幅に機能強化を施して、Small Basic の最新バージョンである 0.9 がリリースされました。 今回の強化ポイントは、第一にパフォーマンスが大幅に高くなったことです。... Author: DDJPNVS Date: 06/13/2010 VS フィードバックのツイッターを始めました まだ試験運用中ですがhttps://connect.microsoft.com/Vis
常用漢字刷新へ | スラド
5年ほど前に戸籍に使える漢字が増えるという話題があったが、各社の報じるところ（リンク先はとりあえず日経）によると、文化審議会国語分科会漢字小委員会が2010年に制定される新常用漢字表に「鹿」「阪」「奈」「岡」など、都道府県名にも使われている11字を含める事を決定した。 また、このほか約4000字についても常用漢字表に含めるか検討し、総字数の結果によっては「準常用漢字表」を制定することも検討するとの事。 学生時代に小説を読み漁って漢字を覚えたタレコミ子としては新聞等での「ぜい弱性」などといったかな交じり表記に違和感を覚えていたのですが、逆に言えば新聞しか読まないと「脆弱性」という本来の漢字表記を目にする機会すら奪われる（奪われていた）のではないかと危惧します。 常用漢字表はあくまで目安として、必要であればフリガナ併記、PCや携帯の普及を鑑み一般的にはJIS第二水準程度まで制限なしといった運用
第2回：C#プログラムでサロゲート・ペアの動作を検証する（前編）
.NET Framework対応のアプリケーションが扱う文字列に，4バイト長で1文字を表す「サロゲート・ペア」が含まれる場合，文字列操作にどのような影響があるだろうか。.NET Frameworkの文字列操作には，ユーザー・インタフェースやファイル操作，プログラム内部での処理など様々な形態が考えられる。ここでは，基本的な振舞いを見極めるために，文字列処理において最も基本的で頻繁に利用されるStringクラス（Stringオブジェクト）に着目し，2回に分けて検証する。 Stringクラスには，メソッドやプロパティなどの構成メンバーが，50個くらい定義されており，それを一つひとつ詳細に解説するのはきりがない（注1）。ここでは，今後皆さんが，.NET Framework環境でサロゲート・ペアに対応したアプリケーションを構築する際にヒントや留意点を導き出せるように，Stringクラスの代表的な機能
第1回：進まないJIS2004への移行，その原因は？
2004年に制定された最新の文字コード規格「JIS X 0213:2004（通称：JIS2004）」。このJIS2004に対応したWindows Vistaがリリースされて，早1年が経過した。JIS2004自体は，フォントやIMEの普及に合わせて，ユーザーに順調に浸透している。しかし，ユーザーからのデータを受け取る企業情報システムの側では，JIS2004への対応が進んでいないのが実情だ。なぜJIS2004への対応が進まないのか。その現状をまとめてみよう。 JIS X 0213:2004（JIS2004）は，2004年に制定された最新の文字コード規格。過去の文字コード規格に対して多くの文字を追加しており，従来扱えなかった日本の地名・人名などが表現できるようになった（JIS X 0213の概要や，2004年に改訂された経緯については，ITproの記事「VistaでUnicode以外の選択肢はな
Windows Vistaの「文字セット」問題を解決、富士通が新ソフト
富士通は12月7日、Windows Vista/XPなどOSのバージョンが違っても、Webブラウザで表示する漢字の字体を統一できるようにした新ソフト「Interstage Charset Manager Web入力 Agent」の説明会を開催した。文字コード体系の新規格「JIS2004」を採用しているWindows Vista上で、同XPと同様の「JIS90」規格に従った漢字を入力・表示できる。反対にXP上で、同OSが未対応のJIS2004に従った字体を入力・表示することも可能だ。新ソフトは、11月に出荷を開始している。 仕組みはこうだ。Webサーバー上で動作する新ソフトは、文字コードと漢字の変換テーブルを保持しており、OSによって字体が異なる漢字については、画像データに変換してWebブラウザに送信する。このため、どちらのOS上で動作するWebブラウザでも、同じ字体が表示される。文字入力時
文字列 → 数値実体参照変換
入力した「文字列」を数値実体参照の形に変換します。 入力された文字列はサーバに送信されません。 (基本的にはローカルで処理されます。) 文字列
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WordPress › Error
文字コード