いろんな日本語EUCについてのまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
日本語EUC（EUC-JP）にはいろいろあって頭がこんがらがってきたので、サルにもわかるように（つまり、自分があとから見て理解できるように）まとめてみた*1。まず、EUC-JPにはどんな種類があるのだろうということで、わたしの環境で実装例を確認できるものをピックアップしてみた。下図のうちeucJP-openとIANAのEUC-JPについては身近な実装例を思いつかなかったが、これを外すわけにはいかないだろうと思って入れておいた。 各EUC-JPのレパートリをまとめたのが、下図。eucJP-openには上図に示したようなバリエーションがあるが、レパートリは共通。「JIS X 0208の国際基準版・漢字用8ビット符号 + JIS X 0201片仮名」については、これを一言で表現できる呼称を思いつかないので、以下の図では仮に「TextEdit」と表記する。 下図は、各EUC-JPのレパートリと符号
Re:思想の問題なら、もっと早い段階で判断すべきだったのでは？ (#1735682) | 開発中の PHP 6、UTF-16 化に失敗。開発ブランチも 5.3 系に巻き戻し | スラド
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1260 [xml.gr.jp] > これだけPCの容量が大きくなったのだから32bitにしてもいいじゃないか、と > いう意見がありますが、これは一種の錯誤です。 続きはリンク先をどうぞ。 最近ではスマートフォンとかiPadとかネットブックとかの、PCよりメモリ要求が厳しい端末も無視できませんからなおさらですね(主要なWebブラウザはどれも内部エンコーディングにUTF-16を採用しています。これは理由のないことではありません)。 UTF-32にしても固定長で処理が済むわけでは全然なく、メリットはありません。UTF-32だろうと(サロゲートペアを無視した)UCS-2だろうとWindows←→Mac OS X間のファイル共有を実装しようとするだけで文字合成(「タ,U+3099←→ダ」とか)の考慮は必
URLで使うためにNSStringの文字列をエンコードしてエスケープ - 電子趣味の部屋
NSStringの文字列を指定した文字コードでエンコードし、エスケープするには、NSStringのインスタンスメソッド stringByAddingPercentEscapesUsingEncoding:(NSStringEncoding)エンコードの種類 でできます。 例："あいう"を各種文字コードでエンコード＋エスケープしてデバッグコンソールに出力 NSString *urlstr = [[NSString alloc] initWithString:@"あいう"]; NSLog(@"UTF-8 : %@",[urlstr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]); NSLog(@"EUC-JP : %@",[urlstr stringByAddingPercentEscapesUsingEncod
Snow LeopardのMailはUTF-8のメールを量産する - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Apple Mail（Mail.app）がcharset=ISO-2022-JPのメッセージを表示する際の変換テーブルが、おかしい。 WindowsとMacでは、JIS X 0208に含まれる文字の範囲において、下図のようなUnicodeマッピングの相違が存在する。たとえばWindowsはJIS X 0208の1区33点「〜」（波ダッシュ）をU+FF5E FULLWIDTH TILDEと解釈し、Macは同じ文字をU+301C WAVE DASHと解釈する。 ところがMac OS X 10.6 Snow LeopardのMail 4.1（1076）は、Apple製の（そしてもちろんMac専用の）アプリケーションであるにもかかわらず、上図のすべての文字について、Windows側のマッピングによってcharset=ISO-2022-JPのメッセージを解釈する。 その一方でMailは、「Unico
ファイル名は「左から右に読む」とは限らない?!
ファイル名は「左から右に読む」とは限らない?!：セキュリティTips for Today（8）（1/3 ページ） 私たちの常識が世界では通用しないことがあります。攻撃者はそんな心のすきを狙って、落とし穴を仕掛けます。今回はそれを再認識させるかのような手法と、その対策Tipsを解説します（編集部） 皆さんこんにちは、飯田です。先日、セキュリティ管理者の方々と「今後のウイルス対策のあり方」について意見交換をする機会がありました。参加者からは活発な意見や質問も飛び交い、盛り上がりを見せた意見交換会となりました。私自身も多くの気付きや学びを得ることができ、貴重な時間を過ごすことができました。 その意見交換会の中で、Unicodeの制御文字を利用したファイルの拡張子偽装の話題が出ました。この手法は目新しい手法ではなく、数年前からすでに指摘されていたものです。しかし、久しぶりに本手法について議論するこ
備忘録: Unicode, UCS, and UTF : 404 Blog Not Found
2005年12月20日11:45 カテゴリiTechLogos 備忘録: Unicode, UCS, and UTF まだ混乱が収まっていらっしゃらないようなので、備忘録を兼ねてここでまとめておきましょう。 電脳社会の日本語 加藤 弘一 quinta essentia - del.icio.us買収, Yonahあってるかな? Character Set (文字集合) vs. Encoding (符号化) まずこの二つが別物だということを抑えましょう。UCSというのは名前からわかる通り、Character Set (文字集合)です(とはいえ、Unicode.orgのGlossaryを見ると、符号化の一手段にも見えなくはない)。この段階では、各文字は「背番号」を持っているに過ぎません。狭義の「Unicode」はこの「背番号」を指します。 これをどう実際のデータにするのかがEncoding (
何故かあたり前にならない文字エンコーディングバリデーション
Last Updated on: 2018年8月8日私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けにもう
Unicode - JISマークは一文字! : 404 Blog Not Found
2009年08月07日15:00 カテゴリCode Unicode - JISマークは一文字! 私もびっくりしたのですが、事実です。 まずは以下をご覧下さい。 〄は一文字です(U+3004)。 フォントまわりをカスタマイズしていないIEでも表示を確認できました。UbuntuのFirefoxでは空白でしたが。 なぜ気がついたかと言えば、unicode@unicode.org にこんな書き込みが登場したからです。 At http://en.wikipedia.org/wiki/Japanese_Industrial_Standards, a new symbol for JIS is shown and discussed. Will there be a new character in the Standard? (Not a new glyph in the same codepoint
Variable Byte Code と UTF-8、またはUTF-24が存在しないわけ : 404 Blog Not Found
2009年08月05日00:30 カテゴリLightweight Languages Variable Byte Code と UTF-8、またはUTF-24が存在しないわけ 実は、これに非常に良く似た符号化を、我々は日々目にしています。 γ符号、δ符号、ゴロム符号による圧縮効果 - naoyaのはてなダイアリー 通常の整数は 32 ビットは 4 バイトの固定長によるバイナリ符号ですが、小さな数字がたくさん出現し、大きな数字はほとんど出現しないという確率分布のもとでは無駄なビットが目立ちます。 UTF-8です。 UTF-8は、0x0から0x10FFFFまでの整数を、以下のようにしてバイト列に変換します。 Range/Offset0123 0x00-0x7F0xxxxxxx 0x80-0x3FF110xxxxx10xxxxxx 0x400-0xFFFF1110xxxx10xxxxxx10xx
UTF-8→SJIS/EUC-JPの重複文字をまとめてみた - hnwの日記
文字エンコーディングの変換を行うと、異なる2文字が同じ文字に変換されることがあります。このような文字を重複文字と呼ぶことにします。UTF-8→Shift_JISおよびUTF-8→EUC-JPについて、重複文字を自分用の資料としてまとめてみました。 MacOSX上のPHP5.2.9での実験結果ですが、プログラミング言語や環境によらず気をつけるべき文字一覧ということになると思います。 色のついている部分が重複している部分です。「-」となっているのは変換できなかった文字です。また、ヘッダのカッコ数字ごとに文字エンコーディング変換に利用した関数が異なります。詳細は下記の通りです。 (1) mb_convert_encoding($char, "Shift_JIS", "UTF-8") (2) mb_convert_encoding($char, "SJIS-win", "UTF-8") (3) i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Q. UTF-8 の冗長性問題は、設計上の問題なのか? - kazuhoのメモ置き場