分析業務等でデータを集約する際、OS環境間等を移動させるファイルの「文字コード」や「改行コード」がクローズアップされる事は往々にしてある事と思います。「移行先の環境に於ける文字コードが◯◯◯◯だが、移行元のDB環境の文字コードは△△△なのでどこかで変換を掛けておく必要がある」等ですね。この場合DB側でデータをエクスポートさせる際に変換を掛けてしまえるのであればコトは簡単ですが、必ずしもそういう訳にも行かないと思います。また、DB由来のものでは無い場合(ログファイル等)そもそも変換を掛けるタイミングが無い状態で取り込まなければならないという事もあるでしょう。 当エントリではそんな時に使えそうな「文字コードや改行コードを確認・変換を掛けるツール」について、コマンドラインツールでどんなものがあるのかざっくり調べてみた内容をご紹介したいと思います。 ※見出し横にある[]括弧での記載は「[文]：文字
自分の知らないCJK Ideographのバリエーションがまだあったことに戦慄している pic.twitter.com/kUlyRLDDTM— moriyoshit (@moriyoshit) March 9, 2017 などというツイートをしたところ、思ったより反響があったのでまとめておく。 上記ではあいまいに「バリエーション」などと書いたが、Unicodeとそれを扱う環境においては、バリエーションと一口に言っても次のような状況がある。 意味論的に等価な異なる字形の集合 同じ字形で異なるコードポイントの集合 aは結構なじみ深いと思う。 a-1. 異なるコードポイントにそれぞれ異なる字形が割り当てられているもの 例: 「東」(U+6771) ⇔「东」(U+4E1C) 「斉」(U+6589) ⇔「齊」(U+9F4A) 「高」(U+9AD8) ⇔「髙」(U+9AD9) a-2. 同じコードポイ
*1…現状どのブラウザでも表示できないっぽい。フォントが用意されていないのかも？ 文字セットと符号化方式の関係¶ ここ超重要。 ┏文字セット(JIS) ━━━━━━━━━━┓ ┏文字セット(Unicode) ━━━━━━━━┓ ┃ ┃ ┃ ┃ ┃┌JIS X 0213(JIS2004) ──────┐┃ ┃┌UCS4──────────────┐┃ ┃│ 第三水準 │┃ ┃│ 4byteで表現できる文字の範囲 │┃ ┃│ 第四水準 │┃ どんな文字を ┃│ │┃ ┃│ +10文字 │┃ 取り込むか ┃│ │┃ ┃│ │┃ インプットに ┃│ │┃ ┃│┌JIS X 208(JIS90)─┐ │┃ なってる ┃│┌UCS2───────┐ │┃ ┃││ 第一水準 │ │┃ →→→→→→ ┃││2byteで表現できる │ │┃ ┃││ 第二水準 │ │┃ ┃││文字の範囲 │ │┃ ┃││ │
UnicodeとUTF-8の違いを理解していない方が結構居るようなので、文字コードの考え方を元に解説してみようと思う。 文字コードとは何か？ 文字コードとは、コンピュータ上で文字を扱うために、文字に対して割り当てられた数値のことであり、文字と数値の対応付けと呼べる。 この対応付けの種類は沢山あって、Shift-JISであったり、UTF-8であったりする。 以上！と言いたいけど、文字コードはこんなに単純ではない。文字コードを複雑にする要素は沢山あるが、今回の記事ではUnicodeとUTF-8の違いに焦点を絞って解説してみたいと思う。 文字コードの構成要素 文字コードの世界は以下の2つの要素で構成されている。 この違いを意識しておかないと混乱を招くだろう。 （１）．文字集合 – 表現したい文字の範囲（”あ”、”い”・・・といった文字の集合体） （２）．符号化方式 – 文字集合を構成する個々の文
起きたこと csvをダウンロードする機能を作っていたんだけども、ダウンロードしてみたら例外が発生。 Encoding::UndefinedConversionError in HogesController#index U+2212 from UTF-8 to Windows-31Jエンコーディング的な？？ で、調べてみたら全角マイナス、っていうのが変換できてなくて怒られていた。 とりあえずやってみたこと ・CSV.generateのオプションに :encoding => 'sjis' を指定 ⇒効かない(変化なし) ・force_encoding使ったりcharsetいじってみたり ⇒効かない(変化なし) ・data.encode(Encoding::SJIS)にオプション :undef => :replace を追加 ⇒変換できないものを ？ に置き換えるのでダウンロード自体はできる
※本記事は自鯖Blogの転載です ※元記事は2012/10/15に書かれました http://blog.parrot-studio.com/2012/10/ruby19-euc-cp51932/ 古いシステムがEUC-JPで動いていて、 そこからのリクエストをRubyのSinatra（あるいはPadrino）で受ける・・・ ・・・そんなこと、よくありますよね(´･ω･)？ *1 文字コードの変換は面倒なもので、ここがネックになることが多いのですが、 携帯絵文字まで対応しているRuby1.9系ならきっと大丈夫 ・・・そんな風に考えていた時期が私にもありましたΣ(・ω・ノ)ノ [1] pry(main)> RUBY_VERSION => "1.9.3" [2] pry(main)> 'あ'.encoding => #<Encoding:UTF-8> [3] pry(main)> 'あ'.enc
さくらのレンタルサーバスタンダードプランにSSHログインしてVimを使おうとしたがUTF8なテキストが文字化けしてどうにもよろしくない。 手元のMacに入れてる.vimrcをコピーしてもダメ。 これはイカンとぐぐってみるとさくらのレンタルサーバのVimはUTF8が化けるので自分でコンパイルしたという話がぞろぞろ出てきた。 そこで俺もと最新のソースを取ってきてやってみるがそれでもうまくいかない。 どうしたらいいのよ、と頭を抱えたところでターミナルの文字コード設定をEUCにしてみると綺麗に表示できる。 これはサーバのシステムの文字コードがEUCになってるんだなと。 ということは、LANG環境変数か。で、export LANG=ja_JP.UTF-8を.bashrcに書いて、ターミナルはUTF8にしてみる。うまくいく。 もしや、これは、と思って、最初から入っているVimでUTF8のテキストを開い
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
はじめに：「なぜ漢数字は数字順に並ばない！？」 先日、こんなツイートをしたところ、結構たくさんの人にリツイートされました。（執筆時点で50件以上） 「漢数字はソートしても数字順に並ばない」という事実を生まれて初めて知った。まさかのサプライズ。 pic.twitter.com/Eqx3ltIfHs— Junichi Ito (伊藤淳一) (@jnchito) 2014年11月27日 「なぜ漢数字は数字順に並ばないのか」という問いに対して、表面的な回答をするなら「数字順に並ばないのは、数字の大きさではなく文字コード順でソートされているから」ということになります。 いや、もちろんそれはわかってるんです。 問題は「そもそもなんで数字順に文字コードを振らなかったの！？」ということです。 感覚的には「一郎、二郎、三郎」って並んでほしいじゃないですか。でも、プログラム上でソートすると「一郎、三郎、二郎」
PostgreSQL から pg_dump した EUC_JP のファイルを UTF8 の PostgreSQL に読み込ませるとエラーになる。 ●文字コード表(EUC-JP) [12836/12836] - [技術資料] ぺんたん info http://pentan.info/doc/euc_list2.html F9F5 FAB1 EFA891 FA11 粼 﨑 FACB FAE5 E6A081 6801 胗 栁 FCE2 FBFC E9AB99 9AD9 郄 髙 FAF0 FB4D E6BFB5 6FF5 444926 茺 濵 F9A4 FA5F E98A88 9288 446378 硑 銈PostgreSQL は内部に文字変換テーブルを持っているが、各エンコード間で混乱している文字は登録されていないらしい。 ●
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
vimエディタでテキストファイルを開いた時に、 ファイルのエンコーディングや改行を正しく解釈できない場合があります。 この記事では、そのような場合のファイルの読み直し方について説明します。 この機能は、他のエディタの「文字コードを指定して読み直す」「改行コードを指定して読み直す」 の機能にあたります。 (Windows, Mac) 概要 vimエディタでテキストファイルを開いた時に、 ファイルのエンコーディングや改行を正しく解釈できない場合があります。 この記事では、そのような場合のファイルの読み直し方について説明します。 この機能は、他のエディタの「文字コードを指定して読み直す」「改行コードを指定して読み直す」 の機能にあたります。 （機能の名称はエディタによって異なるでしょう）
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\）、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
