タグ

unicodeに関するyifeのブックマーク (16)

  • クメール文字とUnicode

    無 @LGRikka 今日の4限は、Unicodeにクメール文字を入れたとき、どれだけ揉めたかという話だったのだけれど、なかなかそれが複雑な問題を孕んでいたので、自分用の整理がてら連続ツイートしようかなと。 2014-12-01 21:51:00 無 @LGRikka 「主にカンボジアで使われるクメール文字をUnicodeに入れようとしたとき、カンボジアの言語学者どころかカンボジア人が誰もいない状態で、文字コードの専門家(外国人)だけが集まってリストを作ったせいで、ワケわからん文字は入ってるわ、必要な文字はないわのウンコードになった」っていう。 2014-12-01 21:53:36

    クメール文字とUnicode
  • 最近のruby-core (2016年2月) - Money Forward Developers Blog

    こんにちは。卜部です。 ruby-coreというRuby体の開発の議論がされているメーリングリストがあります。 新機能やバグ報告などがだいたいここに集約されてくるので購読しておくとRubyの動きが分かります。 最近興味深かったトピックを紹介します。 [#12039] Fixnum#infinite?/Bignum#infinite or Numeric#infinte, consistent with Float#infinite? and BigDecimal#infinite? Float と BigDecimal には #infinite? メソッドがあるのに Fixnum と Bignum には存在しないので困る/欲しい、という提案です。これはあると便利ですね。 [#12040][Win32] File.stat fails on a mounted volume Windows

    最近のruby-core (2016年2月) - Money Forward Developers Blog
    yife
    yife 2016/03/04
    #4044がすごすぎる。Unicodeと正規表現の闇だ
  • 合成用区分符号 - 備忘録のような何か

    <2013.01.21追記> スマホからこのページ見てみると、 意図したとおりに表示されてないことに気がつきました^^; 表示がおかしい箇所については画像にして置き換えています。 ブラウザが対応してないんでしょうかね? 文字コードの問題にはいつも悩まされます。。。 から「Twitterで行をはみ出した顔文字があるんだけど、これはなに?」 と聞かれました。 どれどれと見てみると、 なんだこれは?私も初めて見ました。 調べてる過程で見つけた情報はかなり前のものもあったので こういうもの自体はずっと前から使用されてたんでしょう。 私の目には止まらなかっただけで。 で、調べた結果これは「合成用区分符号」というものが使われている模様。 合成用区分符号の正体は UnicodeでCombining Diacritical Marksと呼ばれる一連のコード (U+0300からU+036Fまで) のことら

  • HFS+のテキストエンコーディング – ものかの

    HFS+はファイルやフォルダなどのアイテム名をどのテキストエンコーディングで扱っているのでしょうか? Appleは最近までこの情報をドキュメントに記載して公開していたのですが、今はしていません(2016年10月現在)。それでも第三者によるアーカイブがかろうじて残っており、典拠として貴重なのでここに記録しておきます。 2009年時点のFile Systems and Unicode Support 追記:いつのまにかリンク切れしていました。キャプチャを貼っておいてよかった…。 見ての通りUTF-16ですね。インターネット上ではUTF-8-MACであるとの説明が散見されますが間違いです。 HFS+のUnicode正規化形式 Unicode正規化形式はUAX#15で4種類が正式に決められています。HFS+はそのうちのNFDをさらにAppleが改変した特殊な正規化形式を実装しています。アイテム名は

    HFS+のテキストエンコーディング – ものかの
  • LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog

    LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回

    LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
  • python2.xでの日本語(マルチバイト文字)問題を一掃する!(その1) — ExSoft

    python2.xを使い始めて、必ずと言って良いほど遭遇するのが日語(マルチバイト)関連の問題です。 ネットで同様のケースを調べて、あまり理解をせずに、対処療法的にその場の問題を回避している人も多いように思いますが、一度腰を据えて理解すれば、それほど難しくないですし、python以外の言語にも応用ができます。 マルチバイト問題については、概念だけではなく、実際に手を動かし、目で確かめる(文字コードそのものを見る)事が重要です。 今回は、python2.xで遭遇する文字コード関連のエラーを実際に発生させ、その理由を理解した上で対処を行ってみましょう。 文字コードの定義 ケース1 [ 再現 ] pythonスクリプトファイルのencodingをcp932にし、以下を記述します。 ustr = u'い' [ 現象 ] SyntaxError: Non-ASCII character '\x8

  • 文字コード地獄秘話 第1話:Unicodeにおける全角・半角 - ALBERT Engineering Blog

    ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか

    文字コード地獄秘話 第1話:Unicodeにおける全角・半角 - ALBERT Engineering Blog
  • モリサワのIVS対応とするアップデータ…

    IVS対応のアップデートとしかアナウンスしていないアップデータですが、それ以外にも異なる部分があったようで…実際に問題に遭遇した方のツイートから多くの方にその問題が共有される結果となりました(twitterの良いところですね)…詳細は直井さんがブログにアップしてくださるでしょう…期待して待たれよ! ↓公開されましたよ! http://d.hatena.ne.jp/NAOI/20140114/1389667156 ※このまとめに対するものかのさんのコメントも重要です。 (都合により、2段落削除…気にするほどのことではありません)

    モリサワのIVS対応とするアップデータ…
  • 最近、モリサワのようすがちょっとおかしいんだが。 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    ところで、モリサワのPr6Nフォントがやばいらしいですね。 twitterで話題になってたね。 まとめを読んでも、ちょっとわかりにくかったんですけど、どういうことなんですか? リュウミンとかのPr6/Pr6Nには複数のバージョンが存在して、新バージョンで作ったデータを旧バージョンの環境で開くと、豆腐になっちゃう文字があるんだよね。 うー、それはかなりイヤですね。 だよね。新バージョンのほうは、IVS(異体字シーケンス)対応版なんだけど、cmapも新しいのになってるから。 しーまっぷ? cmapっていうのは、符号位置とグリフの対応表。DTP用の日語OpenTypeフォント(Adobe-Japan1フォント)には、Unicodeに入ってないグリフもたくさん入ってるでしょ。 入ってますね。 「Unicodeに入ってない字」はcmapには載ってない。でも、そういう字が後からUnicodeに収録さ

    最近、モリサワのようすがちょっとおかしいんだが。 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Masato Kinugawa Security Blog: U+2028/2029とDOM based XSS

    ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ

  • Uhyohyo web 2011 - Unicodeの文字まとめ

    普段文章を打っているだけではあまり目にしない、珍しい文字がUnicodeにはたくさんあります。使えるようになると表現力が増すので、使えるようになりましょう。 環境によっては一部正しく表示されないことがあります。 文字コードポイント名前例説明・備考 上付き・下付き文字

    yife
    yife 2013/07/21
  • なぜUnicodeには分数の「0/3」が入っているのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    Adobe-Japan1の分数は(特にUnicodeとの関係において)けっこうぐしゃぐしゃなので、ちょっと整理してみよう。下図は、横棒を使う分数のリスト*1。Proフォントでは「分数(afrc)」フィーチャで用いられる。分母が2から12までの約分できない真分数と「0/3」と「1/100」。 上図と同じ字種について、数字を斜めに配置するグリフも用意されている(下図)。これらはProフォントでは「スラッシュを用いる分数(frac)」フィーチャで用いられる*2。 上図のグリフはすべて全角だが、斜めに配置する分数の一部には、プロポーショナル・グリフも用意されている(下図)。 下図は、Unicodeに含まれる分数を、Mac OS Xの文字ビューアからInDesignに入力したもの。Adobe-Japan1ではプロポーショナル(黄色地)優先のマッピングであるため、「2/5」などの全角グリフ(グレー地)

    なぜUnicodeには分数の「0/3」が入っているのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • ダブルミニュートにご注意 - なんでやねんDTP・新館

    ※文字そのもののユニコード位置は正確には情報パレットのモノを参照する必要があるが、この記事の一部のユニコード表記は字形パレットを参照したため正確さに欠ける。(100320追記) タテ組の文をテキストデータで支給される場合、最終的にはダブルミニュート(いわゆる「ちょんちょん」)にしなければならない部分にUnicodeの201C(Shift-JISの8167)/201D(8168)を入力してある場合と301D(8854/8780)/301F(8855/8781)を入力してある場合がある。 ご存知の方も多いと思うが、これがちょっとややこしいことになっている。 これらを入力したものを並べてみた。 3つめはShift-JISの8780と8781である(これも301D/301Fになる)。 ご覧のようにモリサワのPro書体やマティスなどUnicode3.0準拠の比較的古い書体は201C/201Dもダブ

    ダブルミニュートにご注意 - なんでやねんDTP・新館
  • UnicodeDecodeError/UnicodeEncodeErrorに悩まないPython 2.x プログラミング - atsuoishimoto's diary

    最近、ときどきTwitterで「Python」を検索して眺めていたのだが、Pythonの分かりにくいところとして「UnicodeDecodeErrorが出てうざい」という不満をよく見かけるようだ。 確かに、Pythonでは、数字やアルファベット以外のユニコード文字を使おうとすると、対応する処理を書かなければUnicodeEncodeErrorやUnicodeDecodeErrorが出てしまう。Python3では色々改善されているのだが、Python2では分かりにくい点も多い。 このUnicodeDecodeErrorを見て、「Pythonは日語が苦手だ」と考えてしまう人も多いだろう。確かにそう思ってしまっても仕方がないが、それは正しくない。日人だけでなく、アメリカ人でもフランス人でもドイツ人でも、ユニコードを使う時はみんな等しく平等にこのエラーを出しているのである。 もちろん、慣れてし

    UnicodeDecodeError/UnicodeEncodeErrorに悩まないPython 2.x プログラミング - atsuoishimoto's diary
  • 日本語環境でのPython (for Python 2.3 or later)

    語環境でのPython (for Python 2.3 or later) - Pythonで日語処理を行うために(for Python... 皆さんがPythonを使いはじめるとき、なんと言っても気になるのは「ちゃんと日語使えるのかなぁ」ということではないかと思います。 結論から言えば、現在のPythonは日語環境で利用可能です。 しかし、快適に日語を使うためには、ちょっとした準備が必要です。 ここでは、Python 2.3 を基に説明を行います。 Python の文字列型 まず、Python の文字列型データは 8 ビット透過ですので、文字列の中に文字コードが 0 から 255 までのどんな値が含まれていても処理することが出来ます。 Python の文字列型データに日語が含まれていても、ビット落ちなどの障害が発生することはありません。 いったんデータとして日語文字列を

  • 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/

    UnicodeとUTF-8の違いは? - Humanity
  • 1