rsyncでiconvオプションをつけると、deleteオプションの挙動が変わる？？(Mac) - 或る阿呆の記
rsyncでiconvオプションをつけると、deleteオプションの挙動が変わる？？(Mac) 2013 8/21 2023-10-10追記: 時代は変わって、APFSになり正規化されなくなり、ようやくこの問題に悩まされることもなくなりました。 Mac版の話です。Macではファイルシステムの都合上、濁点が一文字扱いになってしまうため、他のOSのマシンにファイルをコピーするときは、文字コードに気をつけてやらないといけません。rsyncにおいてはiconvオプションを付ける必要があるのですが、どうも、これをつけるとdeleteオプションの挙動が変わってしまような感じです。 今回使ったソフトウェアは、MacのHomebrewでインストールした、rsync 3.0.9です。 MacをUnixマシンとして愛用する者の間では有名な仕様として悪名高い（？）UTF-8-MACがあります。Macでは濁点はそ
python3のbytes型とstr型の比較と変換方法
3では文字列はunicode文字列として扱われるようになったので、すべてpython2でいうところのu''になりました。u''表記してもエラーにはなりませんが(python3.3以上)同じ意味です。 バイナリデータを扱うときには、bytes型に変換します。bytes型は文字列っぽく扱えますが、strとbytesの連結などはできないので用途に合わせて適切な型で持つようにします。 例えば特定の文字コードの文字列を持ちたい場合はbytes型になります。str文字列として加工などをして最終的に出力する際に、任意の文字コードのバイト列としてエンコードして出力するという使い方になります。 strからbytes encodeでbytes型(utf-8)に変換します。 >>> 'あいう'.encode('utf-8') b'\xe3\x81\x82\xe3\x81\x84\xe3\x81\x86' #ut
Python3で文字列を処理する際の心掛け - Qiita
昨日の記事に引き続き、今度はPython3で文字列を扱う場合の自分なりの方針をまとめてみる。 個人的結論 ほとんどの場合は文字列を扱い、標準入出力とも文字列でやり取りする。 ただし外部プログラムからバイト列が渡される、などバイト列を扱わなければいけないこともありうる。逆に言うと、そういう場合を除いてはバイト列を扱わない。 これが良い悪いということではなく、現状自分の書くコードではバイト列を扱わなければならないケースが少ないというだけ。 バイト列と文字列 バイト列は特定のエンコード方式でエンコードされており、リテラルではb'a'のように表現する。一方、文字列はUnicodeのコードポイントを並べたものであり、リテラルでは'あいう'のように表現する。 さらっと書いたが、この時点でPython2との扱いの違いが分かる。 「Python3のバイト列」は「Python2のバイト文字列」と扱いが似てい
Python2のstr/unicodeとencode/decode - Qiita
２種類の文字列 Python2には文字列が2種類ある。 ここではその2つを str文字列 および unicode文字列 と呼び、これらをまとめて 文字列 と呼ぶ。 公式ドキュメントでも用語があまり統一されていないので、とりあえずこう呼ぶことにする。 先に言っておくと、基本的にunicode文字列を使うべき。 str文字列 '...' リテラルで生成されるオブジェクト UTF-8, Shift-JISなどの符号化方式によって各文字を符号化して得られるバイトを並べたもの 1文字が複数バイトで表現されることもある str文字列そのものは、符号化に使われた符号化方式の情報をもたない 符号化方式を知るには基本的に片っ端から試すらしい 対話環境で 'あいう' と入力すると、 \x で1バイトずつ区切られたバイト列が返る
unoh.github.com by unoh
Firefoxは内部的に変換処理を行うようになっているようです。 問題はSafariとOperaですね。 選択されたファイルのパスからJavaScriptで ファイル名を抜き出してタイトルに設定する部分で、 正しく扱えるような文字コードに変換することにしたいと思います。 基本的な流れとしては、UTF-8-MAC特有の「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）、 「U+309A」（COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK）がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう （ひらがな・カタカナのみの暫定的な対処に過ぎませんが）。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ
Mac OS Xの濁点ファイルがやってきた - miauのブログ
一ヶ月ほど前の話。Mac OS X を使っている人から Skype で送られてきた Excel ファイルが WinMerge でうまく開けなくて。「xdoc2txt が .xlsx に対応してない？いやそんなはずは・・・」とかいろいろ調べてて、ふと思い立って dir すると こんな感じと。今まで仕事で Mac OS X を使っている人には出会ったことがなかったので、「これが噂の濁点問題かー」とちょっと嬉しくなって、このファイルをいじりまわして遊んだのでそのお話。 簡単に現象＆用語を説明 詳しいことは Unicode正規化 紹介マニアどらふと版: Mac OS X におけるファイル名に関するメモ(NFC, NFD等) あたりを読んでいただくのが確実なんですが、今回問題になった濁点まわりに限定してかいつまんで説明すると・・・。 Unicode で「が」という文字を表したい場合、以下の二種類の表
いいから聞け！ 俺が文字コードについて教えてやるよ その１（前提知識編） - 谷本 心 in せろ部屋
ちょっと久々のJavaネタですが、 前から書き溜めていた、文字コードやエンコードについてのノウハウを書きます。 今回は、詳細な説明に入る前に、前提になる知識や用語について説明しておきます。 文字コードとエンコードって違うの？ 新人くん「では、HTMLの文字コードはUTF-8でお願いします」 先輩社員「文字コードじゃなくてエンコーディングでしょ？」 新人くん「えっ。あぁ、はい、それで」 文字コードとエンコード（エンコーディング）を混同して使ったりすると、 ちょっと原理主義的な人に怒られたりするんですけど、 大まかに言えば、「文字コード」は文字に割り当てられた「数字」のことで、 「エンコード」は文字と数字をマッピングする「方式」のことだと捉えていれば、大きくは外れません。 ただ、「文字コード」という言葉は、「数字」「方式」の両方で使われるほか、 文字一覧を示す「Charset」という意味で使わ
第1回 「個人番号」では串刺し検索ができない
マイナンバー法案が、国会で審議中だ。システム調達は巨額で、特需が生じると分析する向きもあるが（関連記事）、システム調達費用が巨額になるのには、それなりに理由がある。マイナンバーはかなり複雑なシステムであり、要求要件が非常に難しいからだ。 本連載では、マイナンバーのシステムが抱える複雑さや、システムを開発する上での難しさを解説する。連載第1回である今回は、マイナンバーがどのような設計原理に基づいているのか。以下に示した図を基に、例を挙げて説明しよう。 サーバーをまたいでの串刺し検索が許されていない マイナンバーの特徴は、「個人番号を使ったサーバーをまたいでの串刺し検索が、一切できない」という点にある。例として、「ある人物の年金加入記録を郵送したところ、転居先不明で日本年金機構に戻ってきてしまった」という場合を考えてみよう。 マイナンバーを導入すると、日本年金機構は以下の手順で、転居先を調べる
文字コード（UTF-8,Shift_JIS,EUC-JP,ISO-2022-JP）についての俺的まとめ - 今日もスミマセン。
「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか？ 日本語の文字コードは大きく以下の２つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング（文字符号化方式）」の事を指す。 文字符号化方式 文字集合って？ 読んでそのまんま”文字の種類の集まり”。「キャラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
