Rubyのエンコーディング - tmtms のメモ
Ruby 1.9 から文字列や正規表現オブジェクトはそれぞれエンコーディング(いわゆる文字コード)を保持するようになりました。 たとえば 0xB1 0xB2 という２バイトは EUC-JP エンコーディングでは「渦」、SHIFT_JIS エンコーディングでは「ｱｲ」という文字になります。つまり同じバイト列でもエンコーディングが異なれば異なる文字として解釈されます。 1.8 では文字列はただのバイト列でした。なので、それがどのような文字を表しているのか、つまりエンコーディングが何なのかはプログラムが知っている必要がありました。 1.9 では文字列オブジェクト自身が自分が何のエンコーディングかを知っています。同じ 0xB1 0xB2 というバイト列でも、それが EUC-JP の「渦」なのか SHIFT_JIS の「ｱｲ」なのかは、文字列自身が知っています。 スクリプトエンコーディング スクリプ
Shift-JISなCSVを読み込む・書き出しするときにエラーを起こさない数少ない方法 - Qiita
CSV.foreach("/path/to/file", encoding: "Shift_JIS:UTF-8") do |row| p row #->UTF-8な日本語 end が。 Encoding::UndefinedConversionError - "\x87U" from Shift_JIS to UTF-8: とエラーが出てしまいます。 文字コードのオプションを付けてみる File#openの場合には、 {encoding: "Shift_JIS:UTF-8", undef: :replace} というオプションをつけて対応できますが、CSV#foreachなど、読み込み系のメソッドではこのオプションに対応しておらずに、エラーが出てしまいます。 ArgumentError - Unknown options: undef.: というわけで、csvモジュールにモンキーパッチを当
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
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のときのデフォルト
漢数字が数字順にソートされない理由を調べてみた - give IT a try
はじめに：「なぜ漢数字は数字順に並ばない！？」 先日、こんなツイートをしたところ、結構たくさんの人にリツイートされました。（執筆時点で50件以上） 「漢数字はソートしても数字順に並ばない」という事実を生まれて初めて知った。まさかのサプライズ。 pic.twitter.com/Eqx3ltIfHs— Junichi Ito (伊藤淳一) (@jnchito) 2014年11月27日 「なぜ漢数字は数字順に並ばないのか」という問いに対して、表面的な回答をするなら「数字順に並ばないのは、数字の大きさではなく文字コード順でソートされているから」ということになります。 いや、もちろんそれはわかってるんです。 問題は「そもそもなんで数字順に文字コードを振らなかったの！？」ということです。 感覚的には「一郎、二郎、三郎」って並んでほしいじゃないですか。でも、プログラム上でソートすると「一郎、三郎、二郎」
JIS X 0212 (1990) to Unicode 陬懷勧貍｢蟄励さ繝ｼ繝芽｡ｨ
unicode縺ｮ螟画鋤陦ｨ縺ｯ繝ｦ繝九さ繝ｼ繝峨さ繝ｳ繧ｽ繝ｼ繧ｷ繧｢繝縺ｮ繧ゅ�ｮ繧剃ｽｿ逕ｨ縺励※縺�縺ｾ縺� JIS X 0212 (1990) to Unicode JIS X 0212 陬懷勧貍｢蟄励�ｯ螳溯｣�縺輔ｌ縺ｦ縺�縺ｪ縺�迺ｰ蠅�繧ょ､壹＞縺ｨ縺翫ｂ縺�縺ｾ縺� Shift-JIS縺ｯ諡｡蠑ｵ諤ｧ縺後↑縺�縺ｮ縺ｧJIS X 0212 縺ｯ螳溯｣�縺ｧ縺阪∪縺帙ｓ Windows荳翫〒縺ｯunicode(UTF-8縲ゞTF-16)縺ｫ螳溯｣�縺輔ｌ縺ｦ縺�繧九′縲゛IS縺ｫ縺ｯ螳溯｣�縺輔ｌ縺ｦ縺�縺ｪ縺�遲峨�ｮ髯仙ｮ夂噪縺ｪ繧ゅ�ｮ縺ｨ縺ｪ縺｣縺ｦ縺�縺ｾ縺� JIS X 0212 (1990) to Unicode 陬懷勧貍｢蟄励さ繝ｼ繝芽｡ｨ 蛹ｺ 轤ｹ JIS UTF-8 UTF-16 螳滉ｽ�(UTF-8) -32 -32 0000 実体(UTF-8)
ＨＴＭＬ文字コード表
ＨＴＭＬ文字コード表 ＨＴＭＬ内では例えば"<"や"> を使いたくても、タグと見なされて思ったように表示されないばかりか、グチャグチャな表示となってしまう場合もあります。 こんな場合は"&#"と";"で対応する数字を書いておくと、その対応する文字が表示されます。 "<"、">"以外はあまり使うことも有りませんが、後半を見ると変わった記号も有りますので、何かに使えるかも知れません。 気付いた人は気付いたと思いますが、このコード自体を表記するには&と#の間にampと入れています。ソースを見るとそれ以外にも見えてくると思います。
2010-02-14 - 未来のいつか/hyoshiokの日記
例えば、次の言葉の意味を知りたい、聞いたことがあるけどよく分かっていないプログラマにとって、お勧めの書籍だ。Unicode/UTF-8/UTF-16/USC-2/JIS X0208/JIS X0212/JIS X0213/SJIS/EUC-JP/CP932/ISO-2022-JP/ASCII/Latin-1/ISO 10646/ISO 8859-1/サロゲートペア/文字化け/機種依存文字/半角カナ/絵文字… JIS X0208やJIS X0213の解説などは圧巻である。書籍にはWebにない利点がある。Webには即時性があるが、文字コードの解説においては、即時性はそれほど求められない。字体ないし字形の差異についてWebではその字体ないし字形がなければ表現しようがないが、書籍であれば細部までこだわって表現できる。 例えば、包摂された「辻」という字の一点しんにょうと二点しんにょうの字体の差はWe
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
String#getBytes()ではまる。 - うなの日記
文字列をバイト配列に変換するString#getBytes()ですが、環境によってエンコードで使われるデフォルトの文字セットが違うため、注意が必要です。「デフォルトはUTF-8」とか思い込んでいて、だいぶさまよってしまいました・・・。String#getBytes()の実装をみると、「Converters.getDefaultEncodingName()」(※注:sunパッケージのクラス)で文字セットを解決しているようなので、確認するコードを書いてみました。 public static void main(String[] args) throws UnsupportedEncodingException { // String#getBytes() で利用している文字セットを表示 System.out.println(Converters.getDefaultEncodingName()
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://collective-docs.takanory.net/troubleshooting/unicode.html
文字コードに起因する脆弱性とその対策