全角チルダ問題JenkinsとDockerって何が良いの？ 〜言うてるオレもわからんわ〜 #jenkinsstudyKazuhito Miura
fudist - Shift_JISのダメ文字
Shift_JIS(SJIS, cp932) の文字コードで、2byte目が0x5c の \ になっているものの俗称(だめ文字、駄目文字) 0x5cの \ は使用するフォントやロケールによりバックスラッシュまたは￥記号で表示されます。 ダメ文字を含む文字列やパス、ファイル名を処理する場合には文字化け、検索不可など様々な不具合が起きることがあります。 ダメ文字には ー ソ 十 表 など、使用頻度の高いものもあるので cp932を扱う場合には注意が必要です。 また広義には2byte目が 0x7c のパイプ文字 | になっている文字や、2byte目が正規表現などのメタ文字と重なる文字も含む場合もあります。 ダメ文字問題は正規表現をはじめとする様々な言語、システムで制御用のメタ文字として扱われる文字と同じバイト列が、SJISの漢字の2byte目に含まれていることにより起こります。 特に 0x5c
もう少し詳しく調べてみたよ http://linux.ohwada.jp/modules/smartsection/item.php?itemid=515 ..
もう少し詳しく調べてみたよhttp://linux.ohwada.jp/modules/smartsection/item.php?itemid=515 http://0xcc.net/pub/webdb/bk-05.html などのまとめが素晴らしいね 最近のブラウザはほとんどRFC2231に対応しているみたいだ IEは，8になってもまだ対応してなかったのかよ！ とか Safariは未対応かよ！ という突っ込みはあるけどね それと，自分の環境で確かめられる範囲でさきほどの投稿の表をもう少し充実させてみたよ生utf8生sjisurl_encode(utf8)url_encode(sjis)RFC2231chrome24 (win7-64bit)okxokxokfirefox18 (win7-64bit)okxxxokIE9 (win7-64bit)xokokxokfirefox18 (Ma
fudist - Shift_JIS(cp932)の「ダメ文字」
Shift_JIS(SJIS, cp932) の文字コードで、2byte目が0x5c の \ になっているものの俗称(だめ文字、駄目文字) 0x5cの \ は使用するフォントやロケールによりバックスラッシュまたは￥記号で表示されます。 ダメ文字を含む文字列やパス、ファイル名を処理する場合には文字化け、検索不可など様々な不具合が起きることがあります。 ダメ文字には ー ソ 十 表 など、使用頻度の高いものもあるので cp932を扱う場合には注意が必要です。 また広義には2byte目が 0x7c のパイプ文字 | になっている文字や、2byte目が正規表現などのメタ文字と重なる文字も含む場合もあります。 ダメ文字問題は正規表現をはじめとする様々な言語、システムで制御用のメタ文字として扱われる文字と同じバイト列が、SJISの漢字の2byte目に含まれていることにより起こります。 特に 0x5c
コンピュータとかバイクとか。 Ruby UTF-8 から Shift_JIS(Windows-31j) へ変換するときにエラー
残念ながら、世の中はWindowsを中心に回っているため、CSVをやりとりするときには、文字コードをShiftJISにすることが求められたりします。 RubyプログラムをLinuxで書いていると文字コードは基本的にUTF8になるので、文字コード変換をする必要が出てくるわけですが、kconvやString#encode（Ruby 1.9以降）を使ってSJISに変換する際にエラーを吐かれる文字がいくつかあります。 詳しくは、下記の参考ページに書かれていますが、全角チルダ（ウェーブダッシュ,wave-dash）やハイフン（hyphen）、セントやポンドなどの記号が当てはまります。 文字コードで言うと、U+301C、U+2212、U+00A2、U+00A3、U+00AC、U+2014、U+2016あたりですね。 参考：マニアックなプログラミング備忘録「文字化けについて」 というわけで、文字列をkc
ウノウラボ Unoh Labs: Mac OS X上のUnicode
Firefoxは内部的に変換処理を行うようになっているようです。 問題はSafariとOperaですね。 選択されたファイルのパスからJavaScriptで ファイル名を抜き出してタイトルに設定する部分で、 正しく扱えるような文字コードに変換することにしたいと思います。 基本的な流れとしては、UTF-8-MAC特有の「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）、 「U+309A」（COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK）がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう （ひらがな・カタカナのみの暫定的な対処に過ぎませんが）。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ
初代ポケモンの文字コード - しろもじメモランダム
初代ポケモン（要するに赤・緑）の文字コードの解説ページを読んだので紹介。 文字コードリスト(ポケモン版) これを読めばわかるが、外で一般に使うJISだの Unicode だのとは違い、まさにポケモン専用の文字コードになっている。8ビットコードのようだ。 [改行] や [改ページ] といった制御コードが入っているのはもちろんのこと、「わざマシン」や「ロケットだん」のような単語にコードが割り振られていたり、さらには [主人公の名前] や [（戦闘時に）行動しているポケモン] を表すコードまである。 （半）濁音は合成用の（半）濁点を表すコードを利用する（つまり（半）濁音単独のコードはない）のかと思っていたが、そうではないようだ。0x00–0x4F の範囲のうち、制御コードがない符号位置は（半）濁音ですべて埋まっている*1。ただし、（半）濁音が1コードで表されるといっても一度の処理で表示できるわけ
PHPの SJISと SJIS-WINの違い
SJIS-WINとは？ PHPで文字コードとして「SJIS-WIN」を指定すると、Microsoftが拡張したShift_JISであるWindows-31Jが使われる。 Windows-31Jは、Microsoftが「JIS X 0208-1990」をベースに、NECとIBMの独自拡張文字の一部（一般的にはSJISの「機種依存文字」と呼ばれる？）を取り込んだ文字コード。 （参考：Microsoftコードページ932 - Wikipedia） SJISとSJIS-WINで何が違うの？ SJIS-WINの方が文字が多い。 よく使うところでは、下記のような文字はSJISｰWINにはあるがSJISにはない。 丸数字 （①②③...⑳）ローマ数字 （ⅠⅡⅢ...Ⅹ、ⅰⅱⅲ...ⅹ）カッコ付きの株 （㈱）はしご高［はしごたか］ （髙）たつ崎［たつさき、たちさき］ （﨑） SJIS-WINにはあるがSJ
Twitter時代の文字の数え方 | 配電盤
入力「×」のブラウザでは、「𠮷」が2文字とみなされるため、2文字目まで、つまり「𠮷野」までしか入力できません。 Mozillaの文書には、Unicode code pointsで数えると書いてあるので、そのうち改善されるのかもしれませんが、現時点ではTwitterのために「maxlength="140"」を使うことはできません。 pattern属性 Firefox 21とChrome 27、IE 10、Opera 12.15は、「pattern=".{0,3}"」（任意の文字からなる0から3文字）のような正規表現を使った検証にも対応していますが、やはり「𠮷野家」は4文字とみなされてしまいます。 JavaScript 追記：javascript – でBMP以外のUnicode文字をきちんと扱う（404 Blog Not Found） JavaScriptでは、文字列strの長さをst
Twitterで見かけるハミ出した顔文字の正体 - RyoAnna
少し前からTwitterで見かけるようになった、上下に飛び出す変な顔文字。 気持ち悪いのであまり関わらないようにしていたのだが、この顔文字の謎が明らかになったのでお伝えしたい。 いつものようにiPhoneのApp Storeをぶらぶらしていた時のこと。 Unicoder Lite (App Store)というアプリが気になりダウンロードした。 起動するとなにやら見慣れた文字が。 顔文字でよく使われるギリシャ文字やキリル文字だ。 しばらく眺めているとこんな符号が。 合成用区分符号 これが上と下の行にはみ出す顔文字の正体だった。 ためしに作ってみよう。 ベースとなる顔文字を置く。 左目に合成用区分符号を入れる。 続いて右目に。 見事にはみ出す。 Unicode（ユニコード）とは、世界中のコンピュータの文字を符号化したもの。その "U+0300-036F" に配置されているダイアクリティカルマー
絵文字の正規表現 - Emo PHP携帯絵文字ライブラリ
絵文字の正規表現 各社絵文字の正規表現をまとめました。 一部自作なので間違えていたらご指摘ください。 キャリア別、文字コード別の絵文字の正規表現 // docomoの絵文字の正規表現 $emoji = '[\xF8\xF9][\x40-\x7E\x80-\xFC]'; // sjis $emoji = '\xEE[\x98-\x9D][\x80-\xBF]'; // utf-8 自作正規表現、間違いある？ // EZwebの絵文字の正規表現 $emoji = '[\xF3\xF4\xF6\xF7][\x40-\x7E\x80-\xFC]'; // sjis $emoji = '(?:\xEE[\xB1-\xB3\xB5\xB6\xBD-\xBF]|\xEF[\x81-\x83])[\x80-\xBF]'; // utf-8 自作正規表現、間違いある？ $
グーグルが絵文字を世界標準に提案した理由--国際化エンジニアに聞くプロジェクトの舞台裏（前編）
はじめに 2008年11月27日、Googleは日本の携帯電話の絵文字をUnicodeに収録する計画を公表した。これまで7回にわたってお伝えしてきた連載「絵文字が開いてしまったパンドラの箱」は、この公表から後の動きを追ったものだ。 では、それ以前の同社は何をしていたのか？ つまり、Googleはどんなプロセスを経て絵文字をUnicodeに提案すると決めたのだろう。今回ご報告するのはこのことだ。 インタビューに答えてくれたのは桃井勝彦氏。氏は大学時代にスカラシップ（奨学金）で渡って以来米国に暮しつづけている。言語学・日本語学を専攻する大学院生、大学教員などの経歴も持ち、1996年に学術界からNetscape国際化部門に入社。2004年にMozilla Japanの設立にかかわった後、2005年にGoogleに移った経験豊かな国際化エンジニアだ。マウンテンビューにある米本社にあって、今回の符号
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/
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
多Byte文字コードの圧縮 - シリコンの谷のゾンビ
ひょんなことから気になって調べてみたので結果を記録． Shift-JISやEUC-JPは日本語を2Byteで表現する．同じテキストをShift-JISで表現しようが，EUC-JPで表現しようがサイズは同じになる． けれど，多バイト文字コードのことなんて考えないASCIIな世界の人たちがLZ法のような辞書式アルゴリズムを実装した場合，1バイト単位で処理するから文字コードの差が出るのではないかとふと思った． そういうときは論よりRun． 同じテキストを異なる文字コードで表現した際の圧縮サイズを比較してみた． 対象テキストは，みんな大好き夏目漱石「こころ」 圧縮アルゴリズムはgzip (LZ77+Huffman) --bestオプション付き 元サイズ kokoro.txt.sjis 368051 byte kokoro.txt.euc 368051 byte 当然同じ． 圧縮後 kokoro.t
いわゆる機種依存文字とUTF-8
※ 「①」から「⑮」までの丸付き数字など一部の文字は正しく表示されます。 この一覧表を見ても分かりますように、文字化けするのはMacOS 9.2.2におけるNetscape4.7の場合及びMacOSXにおけるmozilla系ブラウザ（Firefox、Netscape、Mozilla）けでした※。なぜ、他のブラウザで文字化けしなかったかというと、このページはShift_JISではなく、UTF-8で書かれているからです。Shift_JISでは、漢字一文字を現すのに2バイトを使いますが、UTF-8では3バイト使用します。Shift_JISの「あ」は「0x82 A0」（「0x」とはその後に続く文字列が16進数であることを示しています）ですが、「0xE3 81 82」です。Shift_JISで扱える文字量とは比べ物にならない量の文字を同時に使うことが可能です。ですから、このNEC特殊文字 13区の文
PHPで名前を扱う場合、文字コード指定に注意が必要 - Affamative Way
CakePHP のおいしい食べ方: EUC-JPではなく、EUCJP-win!!! お客さんがWindowsを使うと分かっていて、日本語の名前に関するデータ処理をするようなプログラムを書く場合、 $str = mb_convert_encoding($str, "EUC-JP", "UTF-8"); なんてやっちゃだめです。 $str = mb_convert_encoding($str, "EUCJP-win", "UTF-8"); としないと、あとできっと、顧客からクレームが来ます。 知らずに中で使っていて、まさにご指摘いただきました。 具体的にどういうことが起きるかというと。 とか のような文字の文字コードを変換する場合 "-win"って指定してないとその文字が消えるんです。 これ、実はメールの本文の文字コード(ISO-2022-JP)でも同様のことが起きます。 PHP-dev -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ