電子ブックに完全移行できない場合 - 天漢日乗
全盲やかなりの弱視のヒトとデータをやりとりする場合にわたしは困ることがよくある。 Unicodeで処理できない漢字 が含まれるからだ。全盲やかなりの弱視だと そこだけ画像データにして渡す というわけにも行かない。ましてや、 音声データとして出力されない程度の漢字 はいくつもある。従って、漢字の形を認識できない程度の視力になっている視覚障碍者は最初から ある程度以上のレベルのコードの漢字や、異体字や冷僻字のある文書を扱えない のである。異体字は普段使っている漢字に交換可能だが、冷僻字はそうはいかない。 いま 電子ブックが世界を変える という話になっているのだが、それでOKなのは Unicode内で処理できる場合 で、日本語の文献はそれでははみ出る場合が出てくる。中国語もそうだ。すべての冷僻字(滅多に使わない漢字)にコードが振られているわけではないから、どうしても落ちこぼれる文字は出てくる。
cygwin-1.7のUTF8環境手順 - 三次元日誌
別のマシンにも入れてみたので手順。 setup-1.7.exe http://www.cygwin.com/ml/cygwin-apps/2008-07/msg00060.html C:\cygwin-1.7 に保存した。 RootDirectoryとLocalPackageDirectoryをC:\cygwin-1.7に指定。 インストールパッケージ gcc-4 make patchutils automake-1.9 vim git(ただし1.7のgitは壊れてるぽい) $ cd /usr/bin $ ln -s gcc-4 gcc .inputrc set convert-meta off set meta-flag on set output-meta on # historical backward search with linehead string binded to up
文化庁ホームページの文字コード | yasuokaの日記 | スラド
今日が「改定常用漢字表試案への意見」の〆切なので、景気づけに文化庁ホームページの「サイト内検索(e-Gov)」で、問題の4字を検索してみることにした。 「𠮟」検索不能 「塡」検索不能 「剝」検索不能 「頰」検索不能 …っていうか、このホームページ、そもそも文字コードがShift_JISなんだけど。その上、HIDDENパラメータの中に「JCODE=SJIS」ってのがあって、e-GovにはシフトJISしか渡せなくなってる。 仕方がないので、【改定常用漢字表試案への意見】テンプレートで最初に示した4字を、代わりに検索してみた。 「叱」31件ヒット 「填」65件ヒット 「剥」316件ヒット 「頬」6件ヒット ふーん。表外漢字字体表を9年前に答申して、5年10ヶ月前にはJIS X 0213まで改正させたのに、文化庁内部ですらまだこんな状態なのね。まあ、常用漢字表が改定されたら、e-Govの作り直し
Cygwin 1.7系初となるメジャーリリース「Cygwin 1.7.1」リリース | OSDN Magazine
12月23日、Windows向けのLinux互換環境「Cygwin」の新版「Cygwin 1.7.1」がリリースされた。Cygwin 1.7系では初となる安定版リリースで、IPv6サポートの追加やデフォルト文字コードがUTF-8になるなど、多数の変更が行われている。 CygwinはLinux APIをエミュレーションするDLL（cygwin1.dll）と、ツールコレクションから構成される「Linux風環境」。Cygwinを導入することで、Windows上でLinux/UNIX互換のシェルや各種ツール、ライブラリなどを利用できるようになる。また、Linux/UNIX向けソフトウェアをWindows環境に移植する際にも多く用いられている。 Cygwin 1.7.1では、従来レジストリに記録されていたマウントテーブルがLinuxと同様/etc/fstab以下に保存されるようになったほか、複数のC
常用漢字表のUnicode補助文字問題 - Cafe Babe
京大の安岡先生が常用漢字表でUnicode補助文字(Unicode Supplementary Character)の領域に割り当てられている文字がレガシーなシステムでうまく扱えないことを問題にしている． どうして常用漢字表を改定するハメになったのか（yasuokaの日記） まあ，Shift-JISや日本語EUCを使って実装しているシステムで扱えないのは当然だが，Unicodeを使っているシステムでも正しく扱えるとは限らない．というのは，Unicode補助文字というのは，U+10000〜U+10FFFFの領域に符号化されており，UTF-16ではサロゲートペアを使って表現され，UTF-8では4バイトに符号化されるからだ．文字がU+0000〜U+FFFFだけにあることを前提に実装された古いシステムでは，何が起こるかわからない．この辺は，我々がJava言語に対しておこなった話が参考になるとおもう
どうして常用漢字表を改定するハメになったのか | yasuokaの日記 | スラド
『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』(日経コンピュータ, No.745 (2009年12月9日), pp.89-93)の読者から、「そもそもどうして常用漢字表を改定しなきゃいけないんですか」と質問された。それはもちろん、平成17年3月30日に文部科学大臣から諮問第15号「情報化時代に対応する漢字政策の在り方について」が文化審議会に対して…、と答えかけて、私(安岡孝一)自身、途中で答につまってしまった。だって、文部科学大臣の諮問は、以下のようなものだったはずだ。 種々の社会変化の中でも，情報化の進展に伴う，パソコンや携帯電話などの情報機器の普及は人々の言語生活とりわけ，その漢字使用に大きな影響を与えている。このような状況にあって「法令，公用文書，新聞，雑誌，放送など，一般の社会生活において，現代の国語を書き表す場合の漢字使用の目安」である常用漢字表（昭和5
HTML/XMLの文字参照にサロゲートペアは使えない | emkの日記 | スラド
HTML 4 文字参照で使える符号位置(厳密には符号位置ではないのですがここでは深入りしません)の範囲はSGML宣言で定められています。
「シフトJIS」では対応不可能な新常用漢字表 | yasuokaの日記 | スラド
今日発売された『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』(日経コンピュータ, No.745 (2009年12月9日), pp.89-93)の読者から、早速、文化審議会国語分科会に陳情したいのだがどうしたらいいのか、という質問が複数あった。本文中の どうしても「𠮟」がサポートできそうにないなら、その旨を文化審議会国語分科会に陳情する、という手も残されている。新しい常用漢字表は改正案の段階であり、2009年12月24日までは一般からのコメント(パブリックコメント)を受け付けているからだ。「𠮟」ではなく「叱」を常用漢字にしてほしい、あるいは、「𠮟」の「許容字体」として「叱」を認めてほしい、と陳情するのだ。 に呼応したものだ。とりあえず、パブリックコメントのページをお教えしたが、うーむ、本文中にURLかメールアドレス(kanzihyo@bunka.go.jp)く
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
テキストエディタ Max
テキストエディタ Max Windows 2000/XP 用 テキストエディタです。 プログラムを書く道具としてのテキストエディタを目指しています。 まだα版。メモ帳の代わりになるかならないか、ギリギリ微妙な線でせめぎ合ってるような状態です。。 現在、以下の機能(特徴)を持ちます。 Shift-JIS、EUC-JP、ISO-2022-JP、UTF-8、UTF-16 が読めます(内部表現は、UTF-16LE の拡張) 定義ファイルでの、キーワード色分け 読み込んだファイルのバイナリレベルでの一貫性(変なの読んでも壊れないということ。。。これは目標) プロポーショナルフォント選択可 スクリーンショット
UnicodeとUTF-8の違いは？ - Humanity
という2chのスレがかなり勉強になったのでまとめ。 少しでも有用だと思ったものは載せてあるので結構長いです。 Unicodeのような文字集合(符号化文字集合？)やUTF-8のようなエンコーディング方式に限らず色んな文字コードにまつわる話があります。 たびたび話が繰り替えされますがそれは確認ということで。 (元スレ) 追記：簡単にまとめました。 1 ：デフォルトの名無しさん：2007/04/30(月) 20:02:37 ビッグインディアンとかなんとかかんとか 3 ：デフォルトの名無しさん：2007/04/30(月) 20:05:48 また、頭の悪そうなスレが・・・ >>1 それは魚とマグロの違いを訊ねるようなもんだ。 4 ：デフォルトの名無しさん：2007/04/30(月) 20:06:49 魚と鮪というよりは、魚と刺身の違いのような気がする。 5 ：デフォルトの名無しさん：2007/04/
「「絵文字の議論は、これでいいのだろうか。」へのお答え」へのコメント - Cafe Babe
小形克宏氏は，残念ながら山本太郎氏が「絵文字の議論は、これでいいのだろうか。」で言いたかった真意を誤解しているように見える． 「絵文字の議論は、これでいいのだろうか。」へのお答え（もじのなまえ） 山本氏の指摘にもあるように，実は小形氏の発言の「攻撃的な」姿勢と事実と異なる推測は，すでにいろいろなところで問題にされている．例えば，GoogleやUnicodeコンソーシアムは，本当に「世界征服を目論む陰謀組織」なのだろうか？（笑） この原因は，小形氏が今回の事情を勘違いしていることにあると思っている．いつかは直接の関係者から真実が知らされると思っていたし，今まで得られた情報を分析すれば容易に気が付くだろうとも思っていたが，さしつかえないと思う程度まで事情を書くことにする． 今回の提案の大元は，Gmailの携帯絵文字対応である．これは，日本のキャリアや日本の携帯ユーザからの要望を受けて，Goog
Life with Cygwin
沖ソフトウェア株式会社は、沖通信システム株式会社および株式会社沖インフォテックと平成22年10月1日をもって合併いたしました。新会社名は、株式会社OKIソフトウェアとなります。3社が行っております事業は新会社にて従来通り継続いたします。
ファイル名は「左から右に読む」とは限らない?!
ファイル名は「左から右に読む」とは限らない?!：セキュリティTips for Today（8）（1/3 ページ） 私たちの常識が世界では通用しないことがあります。攻撃者はそんな心のすきを狙って、落とし穴を仕掛けます。今回はそれを再認識させるかのような手法と、その対策Tipsを解説します（編集部） 皆さんこんにちは、飯田です。先日、セキュリティ管理者の方々と「今後のウイルス対策のあり方」について意見交換をする機会がありました。参加者からは活発な意見や質問も飛び交い、盛り上がりを見せた意見交換会となりました。私自身も多くの気付きや学びを得ることができ、貴重な時間を過ごすことができました。 その意見交換会の中で、Unicodeの制御文字を利用したファイルの拡張子偽装の話題が出ました。この手法は目新しい手法ではなく、数年前からすでに指摘されていたものです。しかし、久しぶりに本手法について議論するこ
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
INTERNET Watch “情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」バックナンバー
Copyright (c) 2009 Impress Watch Corporation, an Impress Group company. All rights reserved.
機種依存文字とUnicode - WebStudio
導入 機種依存文字と呼ばれる文字があります。 例えばWindowsでは、 大文字のローマ数字(ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ)、 小文字のローマ数字(ⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹ)、 丸囲み数字(①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳)、 丸囲み文字(㊤㊥㊦㊧㊨)、 カタカナ表記の単位(㍉㍍㌔㌘㌧㌦㍑㌫㌢)、 単位記号(㎝㎏㎡)、 複数のアルファベットを合成した文字(㏍℡№)、 元号(㍻㍼㍽㍾)、 会社名等で用いられる括弧囲み文字(㈱㈲㈹)等が機種依存文字と呼ばれています。 機種依存文字は一般的に、異機種間でデータの交換を行った場合、 例えばWindowsで作成したテキストファイルをMacintoshで表示した場合に文字化けしてしまうので、 これら異機種でデータ交換することを前提としたインターネットでは利用するべきではないと言われています。 しかし、これらは機種依存文字と呼ばれているものの、 その意味はあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
