icu-project.org is now icu.unicode.org clicky > https://icu.unicode.org < clicky
icu-project.org is now icu.unicode.org clicky > https://icu.unicode.org < clicky
昨日(6月20日)付でUnicode 10.0.0がリリースされたとの連絡を、日本時間の今日(6月21日)にいただいた。今回のリリースでは8518字が追加されていて、うちCJK統合漢字拡張Fが7473字(U+2CEB0~U+2EBE0)、変体仮名が285字(U+1B002~U+1B11E)の追加である。 私(安岡孝一)個人としては、これで戸籍統一文字と住民基本台帳ネットワーク文字がほぼ一段落したのがありがたいが、5月23日・24日の日記にも書いたとおり、多少、問題が積み残しとなってしまった。また、絵文字の追加(U+1F900~U+1F9E6)や、「BITCOIN SIGN」の追加(U+20BF)は、今後、微妙な禍根を残す気がしないでもない。 まあ、とりあえずは、戸籍統一文字と住基統一文字のIVS提案を、早急に進めてもらうべきかしら。
ページ内リンク 美乳テーブルとは 各文字エンコーディングの事情 それでは本題 探索 その文字は ちなみに 付録 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 での話。 一応、文章の先頭付近に日本語の文字を書いておくのは、他の
Python の unicodedata モジュール - bkブログ を読んで,それ Perl だとどうよと思ったんで対応をまとめてみました。utf8 flag や Encode モジュールについては特に解説しませんので。 文字の名前を取得する charnames モジュール(Perl 5.6 より付属)の viacode 関数を使うと文字の名前を取得することができます。引数として文字列ではなく文字コードを渡すところが要注意です。 use utf8; use charnames qw( :full ); print charnames::viacode(ord 'A')), "\n"; # 'LATIN CAPITAL LETTER A' print charnames::viacode(ord 'あ')), "\n"; # 'HIRAGANA LETTER A' 文字列リテラルとして標準
CMapの系統図を描いてみた。 上図左上、源流となっているUniJIS-UCS2は、Adobe-Japan1-4(AJ14)をレパートリとするCMapである。 Appleは、2001年9月リリースのMac OS X 10.1でApple Publishing Glyph Set(APGS)を投入し、JIS X 0213:2000をサポートした。APGSはレパートリとしてはAJ14のスーパーセットだが、主にJIS X 0213との整合性を高めるために、既存のマッピングに変更が加えられている。 2002年9月、AdobeはAPGSを追認する形でAdobe-Japan1-5(AJ15)を策定したが、Appleによるマッピング変更の一部(主としてプロポーショナル・グリフの採用)には追随しなかった。このためAJ15以降のCMapには、Apple用のもの(UniJISX0213系)とそれ以外(UniJ
Unicode Character 'MOYAI' (U+1F5FF) Browser Test Page Outline (as SVG file) Fonts that support U+1F5FF Unicode Data Name MOYAI Block Miscellaneous Symbols and Pictographs Category Symbol, Other [So] Combine 0 BIDI Other Neutrals [ON] Mirror N Comments Japanese stone statue like Moai on Easter Island Version Unicode 6.0.0 (October 2010) Encodings Emoji :moyai: HTML Entity (decimal) 🗿 HTML E
Pyhton の XML/HTML パーサ・ライブラリ BeautifulSoup を使って、Google の検索結果を整形する Python スクリプトを書いたところ、Python の日本語処理で UnicodeEncodeError、UnicodeDecodeError ではまった。いい機会なので、Python で日本語処理に関して、自分なりに整理してみる。 この記事は Windows での Python 2.5.1 で動作確認している。Python 3.x では改善しているかもしれないので、この記事を読む方はご注意を。Python 3.x については時間があれば確認したい。というより、早くバージョンアップしなさい!という感じですが。 [2009.09.22 追記] Python 3.0 で Unicode まわりがかなり修正かかっていました。この記事を読む方は、Python 2.5.
CNetの記事によると、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクトを進行中だそうである。 しかしこれはデータの設計という観点からすると極めて愚かな行為である。今日は声を大にしてこのような愚行に対して異を唱えたい。絵文字をUnicode化してはいけない理由は次の通りである。 1. 絵はあくまでも絵であって文字ではない。 絵文字は言語の一部を形成するものではない。単語に利用することも出来ないし、文字自体を発音できるわけでもない。文字コードに文字以外のデータを導入するべきではない。 2. 別の解決法が存在する。 そもそも絵文字の問題はマークアップ処理すれば解決する。例えば端末自体がHTMLメールを送信することが出来ればまったく問題にならない。 3. 互換性の問題。 文字を利用するアプリケーションはなにも携帯メールだけではない。Go
2024.5.18更新 まともに Unicode のテキストを扱おうとすると、結合文字列はどうしても避けることのできない問題です。ここではあまり深く掘り下げずに、ユーザの眼を通してこれを見ていこうと思います。 まずはじめに、Unicodeには「特殊な文字」があることを知っておきましょう。 上図を見てください。これは macOS のテキストエディットに入力した2つの「ポ」です。同じ文字が並んでいるだけのように見えます。でも実はこの2つ、文字データとしてはまったく違うものなんです。 左はいつも私たちが使っている1文字の「ポ」ですが、右は「ホ+半濁点」の2文字のデータで1文字になっています。これが Unicode の特殊な文字 “結合文字列” です。見た目が同じなので違いがまったく分かりません。 そこで違いが分かるように簡単なソフトを作ってみました。 Unicode Normalization
一昨日は駅前の喫茶店にて文字コードについてのインタビューをうけました。なんでも文字コードについて面白い読み物にしたいとのこと。X だとか02いくつだとか、訳の分からない数字やアルファベットが続くのに強い違和感を抱いている様子。うーん、いいなあ、ぼくも昔はそういうこと考えていたんだよなあ、正確さよりも面白さが大事だって。どこで間違っちゃったんだろうなあ。 で、乞われるままにASCIIからISO R 646、ISO 2022からISO/IEC 10646への流れ、そしてその中で日本が果たした役割、あるいはJIS X 0208がISO 2022に基づいた構造であること。もともとISO 2022は事前の二者間の合意を前提とした情報交換のために作られた符号化方法であり、合意のない情報交換や、コンピュータ内部の情報処理用としては向いてなかったこと、そしてこれがUCS≒Unicodeの登場を促すことにな
2010年05月05日 22:37 カテゴリPython Pythonで日本語文字列 (UnicodeとUTF-8, Shift-JIS, EUC-JPなどの相互変換) Posted by yawamen No Trackbacks Tweet ※2.*系の話です.3.*系は違うので注意. Pythonで日本語を扱う場合,UTF-8やShift-JIS, EUC-JPなどの各種文字コードが使えますが, これらとは別にPythonにはUnicode文字列というものが存在します. ※PythonではUTF-8とUnicodeは別物です. 詳しくはマニュアルを読んで頂くとして,ここではソースコードの書き方やいろいろな変換について紹介します. 【ソースコード中に日本語を書くために】 まず最初に,基本的なこととして,何も考えずにソースコード中に日本語文字を書いてしまうと次のようなエラーが出る場合があ
LEFTWARDS TRIANGLE-HEADED ARROW WITH DOUBLE HORIZONTAL STROKE
進化の過程で煩雑な文字コード体系になっているUnicodeは、プログラミングでの取り扱いが面倒だ。C#とUnicodeの関係はどうなっているのか? C#が抱える課題とその解決策について見てみよう。 ← 前回 連載 INDEX 前編では、文字コード、そしてUnicodeがこれまでにどのような進化の道程を歩んできたかを見た。そこで説明したように、文字コード自体が結構な複雑さになっている。当然、プログラミング言語における文字列の扱いにも面倒が付きまとう。 後編である今回は、C#のstring型がどういう実装になっているかや、現状抱えている課題、それに対して検討している解決策などについて説明していく(以下、文字コードは全て16進数で表記する)。 文字列型 まずは、プログラミング言語内部での文字列の扱いについて話そう。Unicodeの歴史で話した通り、もともと、Unicodeは2Bytes固定長の文
Unicodeでは、意味的に同じ文字を複数の方法で表現することができます。しかし、表現がバラバラなままだと、検索などで問題が発生することは容易に想像できます。そのため、表記を統一する仕組みとして「正規化」が用意されています。本稿ではPEARのI18N_UnicodeNormalizerを用いて、PHPでUnicodeの正規化を行う方法を紹介します。 はじめに 与えられた文字列を含む文書を返す検索機能を実装しているところを想像してください。 検索語として「ページ」が与えられれば、「ページ」という文字列を含む文書を返します。これは特に難しいことではありません。 半角の「ページ」が与えられたらどうでしょう。「ページ」と「ページ」を区別する必要がないような、一般的な文書検索においては、「ページ」という文字列を含む文書を返すのが望ましいはずです(もちろん、この2つは常に同一視できるわけではあ
これまで何度かUTR50(Unicode縦書きの文字の向き仕様)を話題にしてきましたが、2013年8月31日に正式版が出て、CSS3 Writing Modes仕様(現在最終草案)でも、このUTR50仕様が縦書きの文字の向きのデフォルトになることが確定しました。 今後はEPUBリーダーなどでの縦書きの文字の向きのデフォルトとして、これが標準になっていくものと思われますが、現在はそれぞれ独自であったりドラフト版のUTR50ベースであったりして、実装によって向きがまちまちです(それを解決しようとしたのがUTR50なのですが)。新しい標準に切り替わるまでのあいだ、電子書籍制作側ではいろいろ注意が必要です。 これについて、「電書魂」の次のブログ記事など参考になるかと思います: InDesignとEPUBの縦書き時の文字の向きの差について/電書魂 また、UTR50とCSS3 Writing Mode
InD-Boardで出ていた「複数行にまたがる括弧」の話が興味深かったので、ちょっと調べてみた。皆さんの指摘に付け加えるような知見はないのだけれど、以下、文字コード的な雑談として。 Unicodeには、複数行にまたがる丸括弧、角括弧、波括弧がある(下図)。このうち2文字で作る波括弧は、左上と右下、左下と右上のパーツが共通なので、文字数としては、ここまでで16文字。 これらの括弧には、拡張用の直線パーツ(下図、グレー地)が用意されている。丸括弧用と角括弧用はそれぞれ左右別々、波括弧用のみ左右共通で、文字数としては5文字。しかしAdobe-Japan1では、これら5文字がすべてCID+12167に集約されており、区別してデザインすることができない。 下図は小塚明朝。角括弧の拡張はうまくいっているが、丸括弧と波括弧は直線部分がズレている。また、2文字分の波括弧のパーツは、おそらく左右共用ではなく
主に携帯電話のメールなどで利用される「絵文字」のUnicode標準化を進めてきたGoogleは、3月18日に「絵文字のUnicode符号化に関するアップデート」を発表した。これによると、絵文字の符号化はUnicode技術委員会で正式了承され、4月下旬にアイルランドで開催されるISO/IEC SC2/WG2標準化会議で審議・承認される運びという。 携帯電話の絵文字は、docomo、au、Softbankなどのキャリアがそれぞれ独自に仕様を決めて運用していたため、キャリアを越えてメールを送受信する場合や、全キャリアに対応した掲示板システムなど携帯向けWebサービスを構築する際に、これまで大きな弊害となっていた。 標準化のプロセスは、Googleが提供するWebメールサービス「Gmail」で絵文字送受信に対応したことと前後して、昨年11月から「emoji4unicode」プロジェクトとしてスター
日本語などのマルチバイト文字を、「¥uXXXX」形式のユニコードエスケープに変換します。 ユニコードエスケープからの逆変換も出来ます。 下記テキストエリアに入力したのち、[変換]ボタンを押すと、画面下部の結果ボックス内に変換結果が表示されます。 変換に使ってるJavascriptの解説はこちら。 テキストをここに入力する: ¥uXXXX形式に変換(Escape) 日本語に変換(Unescape) 結果:
[連載1回目へ] こんにちは、hachi8833です。まだbyobu-configが自分の環境で動いてくれないので、ctrl-aだけ殺してデフォルトキーバインドでbyobuを使い始めているところです。 先週に引き続いて正規表現のUnicode文字プロパティについて調べていきます。改めて調べ始めてみるといろいろと奥深い世界であることに気付き、一人で勝手に盛り上がってます。 早速はてブでツッコミをいただきました。初回連載で[\p{Ideographic}]の記述がいきなり間違っていました。失礼いたしました。Ideographicは日中韓ベトナム(CJKVと略されます)のみが対象となります。前回分も修正いたしました。 Pの一族 正規表現向けのUnicode文字プロパティの解説として、日本語で読めるそこそこまとまった資料は、今のところマイクロソフトの .NET Frameworkの「正規表現での文
unicodeの変換表はユニコードコンソーシアムのものを使用しています JIS X 0208 (1990) to Unicode UTF-8、UTF-16のコードがない文字は実体で表示されていても自分の環境に依存している可能性があります 機種に依存しない観点より、HTMLでUTF-8、UTF-16のコードがない文字は使用すべきではありません 逆にUTF-8、UTF-16のコードがあるのに実体が表示されない場合は(無いと思いますが)SJISでの自分の環境がよほど悪いと考えるべきです JIS X 0208 (1990) to Unicode 漢字コード表 区 点 JIS SJIS EUC UTF-8 UTF-16 実体(SJIS) 01 01 2121 8140 A1A1 E38080 3000 01 02 2122 8141 A1A2 E38081 3001 、 01 03 2123 814
Unicode正規化(ユニコードせいきか、英語: Unicode normalization)とは、等価な文字や文字の並びを統一的な内部表現に変換することでテキストの比較を容易にする、テキスト正規化処理の一種である。一般に、正規化はテキストの文字列を検索や整列のために比較(照合、英語: collation)するときに重要である[1]。 Unicodeの正規化手段の基礎は、文字の合成と分解という概念である。文字の合成とは、基底文字と結合文字の組み合わせによる結合文字列を、単一の符号位置である合成済み文字にする手続きである。たとえば、基底文字 n と結合文字 ~ の組み合わせを単独の ñ 文字に変換する、仮名文字と濁点の結合文字の組み合わせを単独の濁点つき仮名とするなど。分解はその逆で、合成済み文字を結合文字列にする。分解は単一の符号位置を別の単一の符号位置に変換することもある。 Unicod
top > 開発ブログ > PHP > Laravel > [Laravel] JSONレスポンスのUnicodeエスケープ無効化はミドルウェアで! こんにちは、ナカエです。Unityの記事を書こうと思っていたのですがネタを見つけてしまったので今回もLaravelについての記事です。 PHPユーザーズ(日本語)の#laravelチャンネルのログで JSONレスポンスをブラウザで確認するときにUnicodeエスケープされているので解除したい いちいち個別にJSON_UNESCAPED_UNICODEオプションを指定してまわるのは避けたい LaravelのJsonResponse生成が直でnewされていたりするのでフレームワークの該当箇所を全て差し替えるのも辛い という会話を見つけました。ブラウザ以外のツールを使ってレスポンスを確認するという解決策のほか、フレームワークの各所の依存を差し替える
現代において、文字を書くということは、コンピュータやケータイのキーを打つことと、ほぼ同義になってきています。そして、現代のコンピュータにおいて文字を扱うためには、文字コード、それもUnicodeの助けを借りるしかなくなってきています。でも、Unicodeは日本語に特化して作られたわけではないので、日本の文字を扱おうとした場合、色々とヤヤコシイ点があったりします。それらのヤヤコシイ点を、できるだけ平易に説明するこのシリーズ、第4回は、漢字とUnicodeの関係です。 Unicodeには、漢字が大量に収録されています。 ざっくり言えば、Unicodeに収録されている文字のうち、 およそ3分の2にあたる70,000字強が、漢字なのです。 最初はU+4E00~U+9FFF(コード表参照)に、約20,000字の「CJK統合漢字」が収録されているだけでした。 次にU+3400~U+4DBF(コード表参
(C)copyright ffortune.net 1995-2016 produced by ffortune and Lumi. お問い合わせはこちらから
Unicodeに収録されている文字について、各種エンコーディング(文字コード)でのデータ並び(バイトシーケンス)を調べることができます。 調べ方は、3通りの中から選べます。 データ並びは、すべて%xx形式(URLエンコード、パーセントエンコーディングともいう)で表示します。 併せて、JIS漢字コード、区点コード(面区点番号)、JIS漢字水準も調べられます。 目次 文字列を入力して調べる 文字番号を入力して調べる 1文字入力して調べる その他 詳しい説明 文字列を入力して調べる 文字列(最大200文字)を入力して、URLエンコード、もしくはユニバーサル文字名またはHTML数値文字参照へのエンコードを行います。 異体字セレクタ(IVS)等のUnicode制御文字も文字数としてカウントされます。 ↓(1)エンコードしたい文字列を入力する。(例:北欧) ↓(2)エンコードの種類を選択する。 URL
共にEncode::JP::Mobileのdat/*-table.yamlのデータで検証。 SoftBankのShift_JISからUnicode規則が分かったのでスッキリした。これでShift_JIS(cp932)⇔Unicode⇔UTF-8を機械的に変換できる。 def softbank_sjis_to_unicode(sjis): high = sjis >> 8 low = sjis & 0xff if high == 0xf7: if low else: base = 0xe200 elif high == 0xf9: if low else: base = 0xe300 elif high == 0xfb: if low else: base = 0xe500 else: raise ValueError("not softbank emoji") if low elif lo
イントロ Python2.6/3.0共にRC版がリリースされ、正式リリースが近づいて来ました。Python3.0の大きな変更の一つが、 Python2.xのstrとunicodeがunicode文字列のstrに統合され、従来のstrの代わりにbytesを導入することで、バイト列と文字列が明確に分けられたことです。 現在、Python2.5では、unicode文字列の内部表現がucs2のものとucs4のものがあり、それぞれの間では拡張 モジュールの互換性がなくなっています。Python2.6/3.0でこの状況がどう変化するのか調べてみました。 Python2.xのunicode内部表現について Python2.5/2.6では、configureオプションに、--enable-unicode=ucs[24] というものがあり、デフォルトでは2になっています。 また、FedoraやUbuntuの
Perl › バージョン情報 › here 2017年5月30日にPerl 5.26がリリースされました! Perlの登場が1987年ですから、ついに30年目を迎えます! 機能の追加 Perl 5.26におけるいくつかの機能の追加です。便利そうなものをピックアップしてみます。 インデント可能ヒアドキュメント インデント可能ヒアドキュメントの構文が追加されました。これは便利そうです。 my $message = <<~EOS; Hello World EOS 末尾の文字(ここではEOS)の位置が、左の位置になって、出力結果は以下のようになります。 Hello World エディタで、ソースコードの色付けがうまくできるようになるとさらによい感じです。 Unicode 9.0のサポート Unicode 9.0がサポートされました。Unicode 9.0でさらに追加された顔文字などを扱うことができ
欧文組版で用いられる一般的なエリプシスは、3つのドットをベースライン上に配したもので、日本語組版で用いられるセンターライン上の三点リーダとは位置が異なる。 しかしJIS X 0208やJIS X 0213は、(1面)1区36点の三点リーダを、U+2026 HORIZONTAL ELLIPSISと対応付けている。このため、U+2026 HORIZONTAL ELLIPSISをどちらの形状とするかは実装依存ということになり、一般に和文フォントではセンターライン形状、欧文フォントではベースライン形状となっている。 下図における長方形の枠内は、Unicode Standardのコード・チャートの画像。ただし、枠内の正方形の色地は、目安として追加したもの。 Unicodeには、U+2026 HORIZONTAL ELLIPSISの他に、センターライン形状のU+22EF MIDLINE HORIZON
背景 多言語対応アプリケーションでは、文字列を扱う場合に内部でUnicodeを用いることが一般的に行われています。しかし、ファイルとして保存する場合や、ネットワークを通す場合には、ISO-2022-JP・EUC-JP・シフトJISが使われるため、入出力の段階で変換する必要があります。特定のプラットフォームを対象としたアプリケーションの場合は、プラットフォームの変換モジュールを利用できますが、クロスプラットフォームのアプリケーションのために、言語処理系やアプリケーション自身が、Unicodeと既存のエンコーディングとの変換モジュールを持つことが多くなっています。 シフトJISなどのエンコーディングは、 JIS X 0201 や JIS X 0208 などの文字集合を元にしていますが、これらの文字集合とUnicodeとの対応は、規格として厳密には定まっていないため、実装ごとに変換表が違っていま
省コストとパフォーマンスの高みを目指す孤高のターミナルエミュレータ urxvt こと rxvt-unicode は xterm や gnome-terminal などと並ぶ代表的なターミナルエミュレータのひとつ。その特徴としてよく言われるのが軽快なことである。 ただ軽い小さいという事では後発の st (simple terminal) に軍配が上がる可能性も示唆されるが、 urxvt はなお高いパフォーマンスと必要機能の維持を両立しており、その成熟のスタビリティで多くの支持を集めている。 もっとも成熟ということでは xterm という大御所の存在を忘れてはならないのだけれど、その御大もついに持ち得ていないデーモンモードを urxvt は備えている。すなわちよくある複数ターミナルの運用において、サーバとクライアントターミナルを駆使してシステムリソースの消費量を抑えながら、起動時間も短くすると
「Unicode IVS Add-in for Microsoft Office」(http://ivsaddin.codeplex.com)をインストールしてみた。環境は、Vista + Office 2007*1。インストール後、用意されているサンプルファイルをWordで開いてみると、最初はアドインなしの環境と変らない表示だったが、カーソルがぶるぶる震えながら、徐々に異体字に置き換わっていった。 これらの異体字は、アドインが生成した外字フォントのPUA(私用領域)に割り当てられている。オリジナルのフォント(この例ではipamjm.ttf)をまるごと(すべてのグリフデータを含めて)コピーして外字フォント(IPAmjMincho_EUDC.ttf)を作り、符号位置とグリフの対応表(cmap)を一度白紙にした上で、PUAの符号位置とGID(グリフID)の対応を順次追加しているかんじ。 PUA
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く