Unicode 12では4つの言語(script)、554種類の文字が追加されました。これによりUnicodeに収録されている言語は150、文字は13万7292種類になりました。 追加された文字には日本語の文字が7種類、小さな文字としての「ゐ」「ゑ」「を」「ヰ」「ヱ」「ヲ」「ン」が含まれています(通常の大きさの文字は以前からありました)。これらは古い文書を記述するために使われるとされています。 そのほか、現在のイラン南西部に存在したアケメネス朝で使われていたアラム語のElymaic文字。南インドのサンスクリット語、カンナダ語で使われていたNandinagari文字。ラオス、タイ、ベトナム、フランス、オーストラリア、カナダ、米国などで使われていた現代White Hmong語、Green Hmong語のNyiakeng Puachue Hmong文字。インド、ミャンマー、ブータンの現代Wanc
C++標準化委員会、ついに文字とは何かを理解する: char8_tという記事が話題だってので、つらつらと書いてみました。 「グリフ」について グリフ(glyph)という言葉の定義をめぐって でも触れられていますが、「グリフ」という言葉が「字体」を指すのか「字形」を指すのかってのは議論がありますね。文字コードの文脈では普通「字形」の意味だとして話を進めることが多いように思います。 CJK統合漢字について Wikipediaの記事にまとまっていますが、実際に推進していたのは中国みたいですね。うまくやればあんまり問題なかったんでしょうが、あんまりうまく行かなかったんですが、それでも国ごとにその国の過去にあった文字コードとの互換性は取れているので、実際の所CJK統合漢字ってあんまり問題にはなってないと思うんですよね。中国語フォントと日本語フォントを切り替えないといけないって問題はありますけど、それ
C++ Advent Calendar 2018 この記事はC++ Advent Calendar 2018 15日目の記事です。 14日目: VTKライブラリ 16日目: C++のエラー処理との付き合い方 当初見積もりよりも大幅に長い記事となり、投稿したのは12/22で1週間遅刻です。すみません。 お知らせ cpprefjpにchar8_t型追加について解説を書きました。ぎゅぎゅっとコンパクトに、また査読を受けて中立的な表現で書いていますので、よければどうぞ。 UTF-8エンコーディングされた文字の型としてchar8_tを追加 - cpprefjp C++日本語リファレンス 追記 全ての開発者が知っておくべきUnicodeについての最低限の知識 - GIGAZINE Unicodeについて簡潔にまとまってるいい記事を見つけました。 Caution この文章には以下の要素が含まれます。苦手
UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
How to watch Polaris Dawn astronauts attempt the first commercial spacewalk
Unicodeにあるハイフン/マイナス/長音符/波線/チルダのコレクション 2015/06/18 Unicodeにある文字の中からハイフンのような横棒と波線を集めてみました。複数あるのはわかっていたつもりでしたが、こんなにたくさんあるとは思いませんでした。 横線に関しては、ハイフンや長音符(カタカナの長音記号)、罫線など、線が横に延びているものです。縦方向や斜めの線は除きます。ほとんど横線だけどほんのちょっとだけ斜め(主観)になっているものは含みます。点線や矢印、線が2つ以上に分かれているものは除きます。途中で曲がっているものも除きます。横線が上の方だったり下の方だったり、太さが途中で変わるものも含めています。 波線に関しては、横方向の線が、直線ではなくS字カーブになっているもので、縦や斜めのS字を除きます。 S字カーブを超えて複雑な曲線も除いています。ただ、文字の名前に “wave” と
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
※2014/4/17 記事の内容に関していくつか訂正させていただきました。 ご指摘いただいた皆様ありがとうございました。 誤字脱字を修正しました。 ソースコードの間違いを修正しました。 BOMの記述を分かりやすい表現に修正しました。 合字に関する記載を追記いたしました。 こんにちは。 Yahoo! JAPANで通知プラットフォームの開発をおこなっています佐々木海(@Lewuathe)と申します。 普段は全社向けのPush通知プラットフォームやメール配信プラットフォームの開発、保守をしています。通知というのはPush通知にしろ、メール配信にしろ基本的には「テキストデータ」を送ることになります。プラットフォーム内ではこれらのテキストに対してさまざまな処理をかけることになるのですが、さすが日本語といったところでしょうか、一筋縄ではいかない部分が出てきました。具体的にはUTF-8でエンコーディング
漢字の話とアラビア文字/インド系文字の話が混在してすみません。 現在Unicodeは実用されている文字をほとんど符号化して、新規の追加文字は昔の文字が大きな比重を占めています。複雑な用字系の表示環境も整って特殊絵文字で皆遊んでいる。しかし10年ほど前には全然状況は違っていたわけで……。
昨日のエントリ(「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ)読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね? うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と? いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ? 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「・」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな
「漢字1文字は2バイト」という常識が、大きく変わろうとしている。現在改正中の「常用漢字表」に対応するためには、Unicodeの4バイト文字を使用する必要があるが、それだけでは済まない恐れがある。今後、戸籍や住民基本台帳で使われている文字がUnicodeに追加されると、漢字1文字が最大8バイトになるかもしれない。文字コードに詳しい京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。(日経コンピュータ) 先日公開した『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』の読者から、「今後のシステムでは漢字1文字を最大4バイトで処理すればいいのか」という質問を頂いた。実は、UTF-8あるいはUTF-16で漢字を表す場合、最新のUnicodeにおけるIVS(Ideographic Variation Sequence)を考慮すると、漢
全盲やかなりの弱視のヒトとデータをやりとりする場合にわたしは困ることがよくある。 Unicodeで処理できない漢字 が含まれるからだ。全盲やかなりの弱視だと そこだけ画像データにして渡す というわけにも行かない。ましてや、 音声データとして出力されない程度の漢字 はいくつもある。従って、漢字の形を認識できない程度の視力になっている視覚障碍者は最初から ある程度以上のレベルのコードの漢字や、異体字や冷僻字のある文書を扱えない のである。異体字は普段使っている漢字に交換可能だが、冷僻字はそうはいかない。 いま 電子ブックが世界を変える という話になっているのだが、それでOKなのは Unicode内で処理できる場合 で、日本語の文献はそれでははみ出る場合が出てくる。中国語もそうだ。すべての冷僻字(滅多に使わない漢字)にコードが振られているわけではないから、どうしても落ちこぼれる文字は出てくる。
@檸檬の家 ブログ更新を停止しています 自己紹介 連絡先: 小川 創生 (motoyuki@bc4.so-net.ne.jp) このブログは個人的な「書きたいこと雑記帳」であり、現在または過去の所属の公式見解等を示すものではありません。 (2009年12月15日追記: MySQL 6.0 は5月に開発凍結となっており、この記事で述べている新機能の行方は不透明な状況です。「MySQLの改定常用漢字表対応が危うい件」もお読みください。) だいぶこの話題を書くのが遅くなってしまったが、新しい常用漢字表の議論がそろそろ佳境なので、このタイミングで書き記しておく。 オープンソースのデータベース管理システム「MySQL」は、特に Web システムを中心に、すでに国内外で多数の主要企業が導入している。しかし、マルチバイト文字については、たとえば商用の Oracle や、別のオープンソースの Pos
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 (日経コンピュータ) 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
という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/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く