タグ

文字コードに関するs1251のブックマーク (7)

  • Unicode正規化 用語の混乱について 第4.2版 – ものかの

    初版 2010/4/5 第2版 2013/5/10 誤解を修正。全面的に書き直し。 第3版 2014/7/13 なるべく分かりやすく全面的に書き直し。 第4版 2015/5/20 さらに分かりやすく全面的に書き直し。 第4.1版 2015/5/27 まだ分かりにくいと不評なので書き直し。 第4.2版 2015/5/27 さらに分かりやすく調整。 Unicode正規化の考え方自体はとてもシンプルです。でも、よく知ろうとしていろいろ調べると、用語がハイコンテキストすぎて、混乱してワケがわからなくなります。日で一般的に見られる用語を図にしてみましょう。 混乱するのはどこだと思いますか? “合成済み文字” と “合成文字” の2か所です。どちらも言葉として同じ意味です。それなのに、異なった状態を表す用語として無理矢理に使い分けようとしています。ここから、以下のような奇妙な文章ができあがります。

    Unicode正規化 用語の混乱について 第4.2版 – ものかの
  • 全角チルダ問題

    「JJUG CCC 2017 Fall」(Japan Java User Group Cross Community Conference 2017 Fall)で発表しました。 ローカルのテストが遅い、CIでのテストが遅すぎてあまり回せていないことなどありませんか? 私のプロジェクトでは、1回のCIに4時間かかるようになってしまい、深夜に一度CIを回すような運用になっていました。 時間がかかりすぎるため、段々とCI自体が負債化していっていました。 今回はCI時間を劇的に短縮するまでにやった10のことをお話します。

    全角チルダ問題
  • Unicodeを斬りたい

    ※2014/4/17 記事の内容に関していくつか訂正させていただきました。 ご指摘いただいた皆様ありがとうございました。 誤字脱字を修正しました。 ソースコードの間違いを修正しました。 BOMの記述を分かりやすい表現に修正しました。 合字に関する記載を追記いたしました。 こんにちは。 Yahoo! JAPANで通知プラットフォームの開発をおこなっています佐々木海(@Lewuathe)と申します。 普段は全社向けのPush通知プラットフォームやメール配信プラットフォームの開発、保守をしています。通知というのはPush通知にしろ、メール配信にしろ基的には「テキストデータ」を送ることになります。プラットフォーム内ではこれらのテキストに対してさまざまな処理をかけることになるのですが、さすが日語といったところでしょうか、一筋縄ではいかない部分が出てきました。具体的にはUTF-8でエンコーディング

    Unicodeを斬りたい
  • はてなブログ

    出雲大社までヒッチハイク旅したら自己発見できた[出雲大社ヒッチハイク体験記/前編] ふとした思いつきから内省と思索の旅へ。神奈川から出雲大社までのヒッチハイクで、予期せぬ自己発見を経験した4泊5日の記録。 はじめに - 旅の動機 - 10年友達関係が続いて、昨年頭から1年間付き合った恋人と年末に別れた。 失恋の詳細はどうでもいいので省く。付き合…

    はてなブログ
  • Python 2/3 両対応のために `unicode_literals` を使うべきか - methaneのブログ

    背景 Python 2 用のコードを書くときは、 Python 3 対応を見越して # -*- coding: utf-8 -*- from __future__ import division, print_function, absolute_import をテンプレとして書いています。 __future__ はファイルごとにバラバラだと混乱を招くので、今関わってるプロジェクトでもこれを新規ファイルのテンプレとして登録してもらってます。 Python 3 の構文、リテラルを有効にする __future__ のうち、 unicode_literals だけは今まで使っていなかったのですが、ふと「あ、やっぱり使うべきだな」と思いついたので、そのへんをまとめます。 第三の文字列型 native string Python 2 には2つの文字列型 str (bytes) と unicode が

    Python 2/3 両対応のために `unicode_literals` を使うべきか - methaneのブログ
  • 「ユニコードは犯罪だからやめてください」の衝撃 - yanok.net

    新年早々、大笑いしてしまったこと。 下らないといえば下らないので書くまでもないかと思ったのですが、後で忘れた頃に読み返すと面白いかもしれないので書きとめておくことにします。 何があったのかは下記のページに詳しく書かれてあります。こちらを読んでいただければ、ぶっちゃけそれ以上のことはないです。 「LINEウイルス」の正体とは―LINE内で流行する「ウイルス攻撃」の現状について 簡単にまとめていうと、 LINE上で「ウイルス」なるものを送りつけることができるという噂があって、実際にそれを送りつけられるとLINEのアプリが誤動作(重くなる)らしい 実際のところ、ここで「ウイルス」と呼ばれているものはある特定の文字列である (プログラムではない。であるからしてウイルスでもない) 特定の文字列を受け取ると動作が極端に重くなる不具合のあるアプリがある、というのが真相らしい 問題を引き起こす文字列は、U

  • ssh接続先の文字コードが接続元と違うときの対処法 - 文字っぽいの。

    問題 自分の環境:UTF-8 SSH接続先:EUC-JP とかよくありますね。 $ export LANG=eucJP とか $ export LANG=ja_JP.UTF-8 してあげてもいいんですが、わざわざやるのも面倒ですし、「ログイン先とこっちのどっちで設定するといいんだ?」みたいに悩みます。 解決法 cocotというツールを使います。 $ brew install cocot でインストール終わり。後は $ cocot -t UTF-8 -p EUC-JP ssh tarou@example.com とすると、手元のUTF-8環境に合わせて向こう側のEUC-JPをコンバートしてくれます。 参考 Ubuntu日語フォーラム / GNOMEの文字コードを常にEUC-JPにする方法

    ssh接続先の文字コードが接続元と違うときの対処法 - 文字っぽいの。
  • 1