タグ

unicodeとcodingに関するcu39のブックマーク (23)

  • Unicode正規化 (NFC, NFKC, NFD, NFKD) 変換 Online - DenCode

    Unicode正規化について Unicode正規化とは、文字を分解・合成することをいいます。Unicodeの文字は、見た目は同じでも複数の表現方法が存在するものがあります。例えば、「â」は「â」(U+00E2)の1つのコードポイントとしても表せますし、「a」(U+0061)と「 ̂」(U+0302)の2つの分解されたコードポイント(基底文字+結合文字)でも表せます。前者を合成済み文字、後者を結合文字列(combining character sequence, CCS)と呼びます。 Unicode正規化には、以下の種類があります。

    Unicode正規化 (NFC, NFKC, NFD, NFKD) 変換 Online - DenCode
  • C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita

    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 この文章には以下の要素が含まれます。苦手

    C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita
    cu39
    cu39 2018/12/23
    Unicode絵文字が当事者意識を持たせたと同時に、中国が無視できないほど存在感のある他者になってきたことも効いてそう。
  • Does Unicode have a defined maximum number of code points?

  • Ruby にて文字と Unicode コードポイントの相互変換を行う - vivid memo

    Unicode のコードポイントを指定して文字を得たり、逆にある文字のコードポイントを調べたり、ということをする機会は結構多いと思います。 が、Ruby でそれをやる方法をぐぐってもあまり上位に情報が出てこないなー、と思ったので簡単にまとめておきます。 Unicode コードポイントとは そもそも Unicode コードポイントとは何か。 Unicode というのは世界中の文字が集められた文字集合であり、Unicode に収録されている文字には順番に番号が振られています。 この番号のことをコードポイントといいます。 あるコードポイントが指す文字を表現するときに "U+" という文字の後ろに 16 進数表記のコードポイントを書いて表すことがあります。 例えば、コードポイント 0x3041 が指す文字 (ひらがなの 「あ」) を U+3041 と書いて表します。 各文字とコードポイントの関係は

    Ruby にて文字と Unicode コードポイントの相互変換を行う - vivid memo
  • Unicode 内のそれぞれの文字種の範囲 - みちのぶのねぐら 工作室 旧館

    郵便番号データを利用するサンプル を作っている最中に気になって、ひらがな、カタカナなどの文字種の Unicode の文字コードの範囲を調べました。 資料として http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/SHIFTJIS.TXT を使います。 “OBSOLETE” となっていますが参考にはなります。これを表計算のシートに貼り付けて Unicode 順に並べ替えるとわかりやすいです。以下の説明には unicode.org の対応する “Code Charts” の URL も記しておきましたので、個別の字面とコード値の確認のためにご参照ください。

  • 絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama

    UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語

    絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama
  • 漢字検索 - 読みや画数などから人名用漢字含む1万字を検索

    特徴: 読みが分からなくとも、漢字の部品(構成要素)や画数などから調べられます 子供の命名に使える漢字で絞り込むことができます JIS第1〜第4水準の10,053文字に対応し(非漢字領域の「〆、仝、々」含む)、日の漢字をほぼ網羅しています 検索結果には異体字もあわせて表示されます 問い合わせの入力方法 以下で、背景が黄色い文字列は入力例です。 よくある例 [金 高] → 「金」「高」の両方を構成要素として 含む漢字。検索結果として「鎬」がヒットし、読みや文字コードなどが表示されます。 [さんずい こう] → 構成要素にさんずいを含み、 読みが「こう」の漢字。例えば「江」などがヒットします。 [さんずい はん 5-6画] → 構成要素にさ んずいを含み、「はん」という読みを持ち、総画数が5〜6画の漢字。例えば 「汎」など。 [にんべん 常用] → にんべんを含む常用漢字。例えば「仁」や「仏

  • Python2.x/3.0のunicode内部表現について : DSAS開発者の部屋

    イントロ 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の

    Python2.x/3.0のunicode内部表現について : DSAS開発者の部屋
  • Regular Expression: Match Unicode Block Range | korp

    This is an online tool that builds a JavaScript regular expression that matches characters that fall in any number of specified Unicode blocks. [] Selected Code Range Block Name

  • Unicodeの似た文字を整理してみた - y-kawazの日記

    XMLやCSV等のデータをJavaで色々加工して出力したりといったことをしてると必ずハマるのが波線などの文字化け問題です。 文字化けが発覚するたびにググって場当たり的な対処を繰り返すのに疲れたのでよく問題になる文字と形が似た文字をリストアップして、更にそれをJavaで各種エンコーディングに変換したらどの文字になるかを頑張って纏めました。 ついでに文字化けしないよう上手いこと出力可能な文字に置換する関数も作ってみました。 Javaの変換テーブル 表中の U,S,W,E,J はそれぞれ、UTF-8、Shift_JIS、Windows-31J、EUC-JP、ISO-2022-JP で出力した際の文字です。 見た目で分からないくらい似た文字ばかりなので、各セルにマウスカーソルを乗せたらツールチップで確認できるようtitleにコードポイントを書いておきました。 分かりやすいよう、青は文字化けなし、黄

    Unicodeの似た文字を整理してみた - y-kawazの日記
  • 従来の文字コードとUnicodeの対応に関する諸問題

    最終更新: 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コンソーシアムが提供しているテーブル

  • 文字コード入門

    コンテンツ一覧 インデックスページ←いまここ コンピュータ上での数値の扱い コンピュータで文字を扱うには? ASCIIとJISローマ字 JIS漢字コード:JIS第一・第二水準 JIS補助漢字・第三・第四水準漢字 中国の文字コード 台湾の文字コード Unicode 大規模文字集合 参考資料(書籍) ページを作るにあたって参考にした書籍です。 川俣晶『パソコンにおける日語処理文字コードハンドブック』技術評論社 芝野耕司編『JIS漢字字典』日規格協会 漢字文献情報処理研究会編『電脳中国学』『電脳中国学II』『電脳中国学入門』好文出版 小池和夫/府川充男/直井靖/永瀬唯/『漢字問題と文字コード』 太田出版 1999 安岡孝一/素子『文字コードの世界』 東京電気大学出版局 1999 ユニコード漢字情報辞典編纂委員会編 『ユニコード漢字情報辞典』 三省堂 2000 小林/安岡/戸村/三上編 bi

  • 新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH(クロステック)

    普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。     (日経コンピュータ) 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ

    新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH(クロステック)
  • PythonのUnicodeEncodeErrorを知る - HDEラボ

    Pythonにはじめて触って、いつのまにか1年が過ぎたのですが、一番はまったのは、やっぱりunicodeの扱いだったと思います。 特に、 UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-12: ordinal not in range(128) のようなエラーにはさんざん悩まされました。ここがたとえばrubyなど他の言語と比べてわかりにくいために、Pythonが取っつきにくい言語になっているのではないか、と個人的には思います。 そこで、このエラーに関係するはまりどころとTipsをいくつか列挙してみました。これからPythonに触れられる方の参考になればと思います。 なお、環境はUNIX上のPython 2.4, 2.5を想定しています。 u1はunicode型で、s1はstr型です。s1にどのよ

  • 絵文字が開いてしまった「パンドラの箱」第5回--絵文字と日本マンガの親密な関係

    絵文字の収録をめぐって、国際規格で大論争--「Google提案」を振り返る 皆さんこんにちは、面白くてタメになる(?)文字コード漫談の時間がやってまいりました。2月からとびとびで書いてきた絵文字の報告も、いよいよ今回が最終回。どうかよろしくお付き合いください。 さて、前回はどこまでお話ししたのでしたっけ。日絵文字をUnicodeに収録しようとするGoogleAppleによる提案(以下、主導者の名をとりGoogle提案と略)ですが、去年の12月にパブリックレビューが開始されると、Unicode-MLで時ならぬ非難の嵐が吹き荒れたこと。そこでの反発を一言で言い表すなら、日文化に強く依存する絵文字を単純に国際規格に収録しようとした点にあったこと。 なぜなら国際規格の審議は参加各国の総意で成り立っており、特定の国しか便利に使えない文字を収録することは、当然強い反対をうけるからです。さらに

    絵文字が開いてしまった「パンドラの箱」第5回--絵文字と日本マンガの親密な関係
    cu39
    cu39 2009/09/22
    ど、どうなったんだー
  • Unicode正規化

    正しい並び替えでは、表示は(A)のままですが、間違った並び替えでは、正規結合クラスが互いに等しいMACRONとACUTEを並び替えたため、表示は(B)のように、eの上のアクセント記号の位置が入れ替わってしまいます。 正規分解・互換分解 ある文字列の正規分解 (Canonical Decomposition) を得るには、まず、それぞれの文字を正規マッピングによって再帰的に、可能な限り、分解します。すなわち、1回分解した後に現れた文字がなおも分解可能であればさらに分解します。分解マッピングがその文字自身である場合は、分解不可能なので、そのままです。 しかし、分解しただけでは必ずしも正しい結果が得られません。つまり、結合文字の順序の一意性を保証するため、分解後の文字列に対して正規順序アルゴリズムを適用しなければなりません。このように、正規マッピングによる再帰的分解と、正規順序アルゴリズムによ

  • Ingrid.org

    Ingrid.org This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Best Penny Stocks Best Mortgage Rates Anti Wrinkle Creams Top Smart Phones Healthy Weight Loss Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy

  • JIS漢字とUCS (Unicode)の文字の対応・変換について

    セント記号 JIS漢字のセント記号(¢)はCENT SIGNである。対応するUCSのコードポイン トはU+00A2である。 ところが、これをUCSのFULLWIDTH CENT SIGNに変換するものがある。ASCII にもJIS X 0201にもセント記号はないので、これが「FULLWIDTH」になる理由 はない。従ってこの変換は不適切である。 ポンド記号 JIS漢字のポンド記号(£)はPOUND SIGNである。対応するUCSのコードポ イントはU+00A3である。 ところが、これをUCSのFULLWIDTH POUND SIGNに変換するものがある。 ASCIIにもJIS X 0201にもポンド記号はないので、これが「FULLWIDTH」になる 理由はない。従ってこの変換は不適切である。 否定記号 JIS漢字の否定記号(¬)はNOT SIGNである。対応するUCSのコードポイント は

  • perlの波ダッシュの文字コード変換のまとめ - (゚∀゚)o彡 sasata299's blog

    2009年02月22日22:31 Perl perlの波ダッシュの文字コード変換のまとめ perlの文字コード周りはなかなかカオスです。外部エンコードとか、perl内部での文字コードとか、UTF8フラグとか。UTF8フラグ?なにそれ?な人は、こことかここを見てみると良いかも。(・∀・) 基的には外部から入ってきた時点でdecodeして、出力時にencodeしてやれば全て解決するんですが、「〜(波ダッシュ)」と「−(全角マイナス)」だけは特別です。注意が必要なのはこの2パターン。 ① utf8⇔shift_jis ② utf8⇔euc-jp ①については以前、perl utf8→sjisで文字化けという記事で紹介しましたが、encode時に、'sjis'では無くて、'cp932'を指定すればOK。※「〜」とか「−」はsjisには含まれていない文字なのが原因。 今回紹介したいのは②の場合です

  • Unicodeでも発生する文字化けの危機と回避

    漢字やひらがななど、数多くの文字を持つ日において、文字化けはいまだに避けて通れない問題だ。XMLでは、こうした文字化けを防止するための仕組みが備わっているが、それでもなお完全に封じ込めることはできていない。その理由について解説しよう。 文字化け防止ルールを持つXML XMLは、安全かつ安定した情報交換の手段として利用できることを目的にした、よく考えられたメタ言語である。XMLより以前のSGMLなどと比較して、格段の進歩が見られる。例えばSGMLでは、SGML文書を記述するためにどんな文字コード系を使用するか、標準的な規定が何もなかった。そのため、あるSGML文書が、ほかのシステムで正常に読めるかどうか、何の保証もなかったと言ってよい。これに対して、XMLでは文字コード系に関しても明確なルールを導入することで、交換性を保証するようになっている。これは、不特定多数の利用者が相互に情報を交換す

    Unicodeでも発生する文字化けの危機と回避