もうすぐお正月だし、こんな図を作ってみたんだけどね。 十二支ですか？ いろんな国の十二支？ そうそう。実はこれ全部、「どこの国の十二支の何番目の動物」という情報まで含めて、Unicodeのコードチャートに載ってるものなんだよね。 いちばん左の列が標準的な十二支ってことですね。 うん。日本だと、12番目のイノシシだけが独自仕様だな。それが標準仕様だとブタ。 カザフスタンでは、来年の干支はカタツムリですか。 よくわからないけど、そうなのかな。 このペルシアのネズミは、どうして小さいんですか？ 標準仕様のネズミの絵を縮小したみたいに見えますけど。 それはネズミの種類が違うんだよ。ドブネズミとハツカネズミ。 え？ でもこれ、文字なんだから、たとえばゾウでもアリでも同じ大きさに描かれるものですよね。 原則は、そうだね。 じゃあ、どうしてドブネズミを縮小したのがハツカネズミなんですか？ まあ、ちょっと
入力「×」のブラウザでは、「𠮷」が2文字とみなされるため、2文字目まで、つまり「𠮷野」までしか入力できません。 Mozillaの文書には、Unicode code pointsで数えると書いてあるので、そのうち改善されるのかもしれませんが、現時点ではTwitterのために「maxlength="140"」を使うことはできません。 pattern属性 Firefox 21とChrome 27、IE 10、Opera 12.15は、「pattern=".{0,3}"」（任意の文字からなる0から3文字）のような正規表現を使った検証にも対応していますが、やはり「𠮷野家」は4文字とみなされてしまいます。 JavaScript 追記：javascript – でBMP以外のUnicode文字をきちんと扱う（404 Blog Not Found） JavaScriptでは、文字列strの長さをst
ページ内リンク 美乳テーブルとは 各文字エンコーディングの事情 それでは本題 探索 その文字は ちなみに 付録 EUC-JP 固有の文字 0208 0212 0213-1 0213-2 Shift_JIS 固有の文字 UTF-8 固有の文字 美乳テーブルとは 「美乳テーブル」という物がある。 「EUC-JP の文章を Shift_JIS だと誤認識されない様に、EUC-JP 固有のバイト値を文章先頭付近に埋め込んでおく」という物。 具体的に、Shift_JIS には 0xFD と 0xFE が現れず、EUC-JP にはそれが現れるので、その値を含む文字コードを書いておこうという事で、その文字の集合に付いた名前。 “美” = 0xC8FE、“乳” = 0xC6FD。 各文字エンコーディングの事情 但し、これは EUC-JP での話。 一応、文章の先頭付近に日本語の文字を書いておくのは、他の
導入 機種依存文字と呼ばれる文字があります。 例えばWindowsでは、 大文字のローマ数字(ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ)、 小文字のローマ数字(ⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹ)、 丸囲み数字(①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳)、 丸囲み文字(㊤㊥㊦㊧㊨)、 カタカナ表記の単位(㍉㍍㌔㌘㌧㌦㍑㌫㌢)、 単位記号(㎝㎏㎡)、 複数のアルファベットを合成した文字(㏍℡№)、 元号(㍻㍼㍽㍾)、 会社名等で用いられる括弧囲み文字(㈱㈲㈹)等が機種依存文字と呼ばれています。 機種依存文字は一般的に、異機種間でデータの交換を行った場合、 例えばWindowsで作成したテキストファイルをMacintoshで表示した場合に文字化けしてしまうので、 これら異機種でデータ交換することを前提としたインターネットでは利用するべきではないと言われています。 しかし、これらは機種依存文字と呼ばれているものの、 その意味はあ
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
という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/
最終更新: 1998.12.20 目次 はじめに 似た文字 旧JISと新JIS ベンダー固有文字 「全角」「半角」 ASCIIとJIS X 0201ローマ文字 おわりに 余談 1. はじめに ISO/IEC 10646とUnicode(以下Unicode)は、いろいろと論議をかもしてきましたが、 すでにいろいろなところで陰に陽に使われるようになってきました。 Windows NTの内部コードがUnicodeであるのはよく知られています。 BeOSでは、内部だけでなく全面的にUnicodeが使われています。 また、Javaのchar型もUnicodeです。 しかし、とくに入出力においては、当分は従来の文字コードと共存することになります。 すなわち、意識するしないに関わらず、Unicodeと従来コードの変換が頻繁に行われます。 変換といっても、Unicodeコンソーシアムが提供しているテーブル
制限は特にないという認識なんだけど、仕様書英語でよくわかんない。 とりあえず2文字でないサンプル http://www.unicode.org/versions/Unicode5.0.0/ch03.pdf 仕様書のP6 くっつける順番で、丸の位置に前の文字までの結合した結果が入るというサンプルですね。 ＝丸囲み数字という日本語のグリフは不要になりそう。 ① ← これは表現できる 2桁数字の ⑪ はできないかも・・・ 結合文字としての最大の生かす場所である音符エリアの説明 http://www.unicode.org/versions/Unicode5.0.0/ch15.pdf 実に6文字で1文字を表すサンプルが出ています。 音符系は基本的に玉の位置と、棒の組み合わせから始まっているので、結合文字の嵐です。 投稿日時 : 2007年9月9日 10:49 コメントを追加 # re: Unico
ラテンアルファベット、アラビア文字を初めとして、世界の文字にはひとつの文字の上下、あるいは左右に別の文字または記号をつけて発音の変化や声調の変化を表すものが数多くあります。 これらの文字はUnicodeでは結合文字(Combining Character)と言われています。結合文字とはプレーンテキストの文字列を表示・印刷・PDFにするとき、文字列の中で先行する基底文字にくっついて図形的にひとつの塊になる文字ということができるでしょう。 結合文字には次のようなものがあります。 ・アラビア文字のHarakat： 2006年01月22日PDFと文字 (30) – アラビア文字Harakatの結合処理 ・ラテンアルファベットのダイアクリティカルマーク：2006年01月26日PDFと文字 (33) – ラテンアルファベット ・キリルアルファベットのダイアクリティカルマーク：例えば、ロシア語のやは、基
キモすぎなんだけどマジ！誰こいつを流行らそうとしている奴は！ 誰だよこいつを面白いって言った奴は出てこいよ！ぶっころしてやるよ俺が！ きーめーなまじキモカワイイとか言ってまじで！ その顔文字、俺の顔にクリソツなんだよ！そういうタグ要らねぇからこれ！ [（ ･ิω･ิ）]ってタグは付けるな！ [（ ･ิω･ิ）]ってタグは付けるな！ はてなブックマーク - [（ ･ิω･ิ）]ってタグは付けるな！ はてなブックマーク - はてなブックマーク - [（ ･ิω･ิ）]ってタグは付けるな！ え？ 別にかわいいと思うんだけど……（ ･ิω･ิ） ちなみに眉毛【 ิ】の正体は、U+0E34 の “THAI CHARACTER SARA I”。前にある子音字にくっつき、短母音 [i] を表すらしい。これが半角中黒（U+FF65; HALFWIDTH KATAKANA MIDDLE DOT）の眼【･】と
Characters: A to Z Index and Search Blocks Fonts - check Unicode characters support in a specific font. Explanation of UTF-8 encoding and a UTF-8 browser test page. Categories Versions All of this information comes from the Unicode Consortium, and is also available from them directly free of charge.
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2017年4月） 独自研究が含まれているおそれがあります。（2017年4月） 出典検索?: "東アジアの文字幅" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 「東アジアの文字幅」（英: East Asian Width）は、Unicode標準の附属書 (英: Unicode Standard Annex) の一つ。Unicodeに収録されている各文字の文字幅に関するヒントを与える East_Asian_Width 参考特性（英: informative property）を定めている。 東アジアのマルチバイト文字コード規格は必ずしも文字幅を
A Unicode font is a computer font that maps glyphs to code points defined in the Unicode Standard.[1] The vast majority of modern computer fonts use Unicode mappings, even those fonts which only include glyphs for a single writing system, or even only support the basic Latin alphabet. Fonts which support a wide range of Unicode scripts and Unicode symbols are sometimes referred to as "pan-Unicode
Real UTF-8 On MySQL 6.0
現在のバージョンのMySQLでは、UTF-8を完全にはサポートしていない。 というと、そのことを知らなかった人は驚くかも知れない。UTF-8は1文字あたり1〜4バイトのサイズを消費する可変長文字コードなのだが、MySQLのUTF-8では4バイトを消費するようにマッピングされている文字を格納したり、取り扱ったりすることが出来ないのだ。（厳密にいうとUTF-8では6バイトまで定義できることになっているが、文字の割り当ては4バイト目までである。）MySQL 5.xまでで対応しているのは、3バイトにマッピングされた文字までである。 UTF-8はUnicodeの符号化方式の一種なので、基本的に世界各国の言語をUnicodeだけで扱うことができる。日本語に関していえば、4バイト目に割り当てられた文字は第3、第4水準漢字だけなので、3バイト目までしか使えなくても実用上は問題がないように見える。しかし地名
完全フリーな日本語漢字フォント、花園明朝がCJK統合漢字拡張Cに対応した。拡張Cは、2008年12月に発行されたISO/IEC 10646:2003 (UCS)の追補5に含まれる4,149文字の漢字集合。日本からは国字が主に追加提案され、収録された。さまざまな漢字が紹介されている動画「なんだかとっても!いいかんじ」で使われている[魚+嵐]（ブリザード）も収録され、「ガンダム」以外は歌詞のUCSによる符号化が可能となった。 UCSとUnicodeは同期することになっているため、CJK統合漢字拡張CはUnicodeの次期バージョン（5.2）にも追加される予定であるが、現時点の最新バージョン（5.1）にはまだ含まれていない。そのためか拡張Cをサポートしたフォントはまだほとんどなく、花園明朝のページには世界初と書かれているほどである。実際には海峰五筆という中国語IMEに付属のフォントSun-Ext
先ほど，日本の携帯で使われている「絵文字」のUnicodeへの収録を検討していることと，そのためのデータがGoogleのブログで発表された．詳細は以下を見て頂きたい． Emoji for Unicode: Open Source Data for the Encoding Proposal（Google Code） Googleの日本語ブログでも，もうすぐ日本語訳（？）を公開するそうである（追記：公開された．）．この案は，将来的にISO/IEC JTC 1/SC 2に提案することになると思われる． この提案で誤解して欲しくないことは，この提案は，既存の携帯の変更を伴わないことである．つまり，この提案は，例えばGmailのような複数の携帯キャリアの絵文字を扱わねばならないシステムを意図したものであり，従来私用領域（Private Use Area）に割り当てていた文字を正式に符号化すると共に
この規格は制定の一歩手前の段階までは、現在の姿とはかなり異なる仕様だった。4オクテットの符号であり、各オクテットをそれぞれ群、面、区、点とする。各面には従来のコントロール領域を避けた0x20 - 0x7Fと0xA0 - 0xFFの範囲に文字を割り当てる。その範囲にISO/IEC 2022に従った構造の各国コード（ISO/IEC 8859やJIS X 0208、GB 2312など）を平行移動してそっくり収容するという、従来のコード系との互換性を最大限に尊重した構成をとっていた。 この案は1990年に国際標準の一歩前の段階のDIS (Draft International Standard) として作成されたが、1991年6月の投票で否決された。その理由は、同じ時期にアメリカの企業群がUnicode仕様を作成したため、同じ目的の規格が2つ作られることを避けることだった。 その後、DIS 106
● 国際化ドメイン名で互換漢字が使えない理由 Unicode正規化が規格に盛り込まれている例として、国際化ドメイン名（IDN）が挙げられるだろう。ドメイン名はいわばインターネット上の番地表示だが、従来はラテン文字のaからz（大文字／小文字は区別しない）、数字の0から9、それにハイフン「-」の計37文字だけに限定されていた。国際化ドメイン名とは、これをUnicodeの範囲に拡大し、それにより世界の人々が自分の使っている言語でドメイン名を表現できるようにしようとするものだ。具体的にはインターネットの規格であるRFC 3490～3492の3つで規定されている。 ここでは「Punycode」（RFC 3491[*1]）と呼ばれる一定の規則に従って、Unicodeの文字列を現在使われている37文字に変換することにより国際化ドメイン名が実現されている。しかしこの変換をする前に「Nameprep」（RF
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
