タグ

文字コードに関するhiroto-kのブックマーク (16)

  • ウノウラボ 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)がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう (ひらがな・カタカナのみの暫定的な対処に過ぎませんが)。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ

  • サロゲートペア入門:CodeZine

    はじめに Windows VistaのJIS2004対応により、WindowsのUnicode環境で使用できる日語漢字の数が増えました。従来、12238字(Windows XP)だったのが13145字(Windows Vista)になり、907字追加されることになりました。これによって、JIS第3水準、JIS第4水準の漢字がすべてサポートされることになったのです(Windows XPまでは一部サポート)。 またWindows XPでも、パッチさえ当てれば、Windows Vistaと同じように追加907字を加えた13145字の漢字が使用できるようになりました。 ところが、この追加された907字の中には「サロゲートペア」という特殊な文字が304字あり、これらは今までのUnicodeの文字とは扱いが少し違います。この点について解説していきたいと思います。 対象読者 Unicode

  • 波ダッシュ Unicodeに関連する問題 - Wikipedia

    波ダッシュ(なみダッシュ、wave dash[注釈 1])とは、日語表記における約物のひとつで、波線「」(はせん、なみせん)を指している。ダッシュ記号(—)の波形であることからそう呼ばれる[注釈 2]。 日語における用法の多くはダッシュ記号としての用法と長音符としての用法であり、中国語でも長音符などとして使われることがある。 Windows XP等における日語環境下では、表示字形が「」ではなく、波形の反転した「」に変わってしまう問題が発生していた[注釈 3]。これに付随して、波ダッシュの代用として音声記号等として用いられる全角チルダが不適切に使われることがあるため、混乱の元となっている[1][注釈 4]。 波ダッシュは、範囲を表すために用いられる[注釈 5]。 場所に対して: 東京〜大阪 時間に対して: 5時〜6時(もしくは5〜6時) 数量に対して: 100人〜150人(もしくは10

  • Universalchardet - やる気向上作戦

    universalchardet / juniversalchardet Mozillaのエンコーディング判別ライブラリであるuniversalchardetを切り出して、Cライブラリ化してみた。さらにJavaにもポーティングしてみた。エンコーディング判別なのにcharacter set detectorとはこれいかに。 C版はLinux/Windowsに対応。Linuxでのインストールは make && make install で。autoconfなどという高尚なものは使っておりません。 文字コードの変換はこちら EncodingConversion Related Works jchardet (Java,旧バージョンのchardet) juniversalchardet(Java,universalchardetのJavaポート) Universal Encoding Dete

  • http://openblog.meblog.biz/article/61959.html

    hiroto-k
    hiroto-k 2007/03/23
    データ交換用、内部処理用そしてデータ蓄積用のエンコーディングをごっちゃにしている模様
  • 19. マルチバイト文字とXSS脆弱性

    比較的新しい攻撃方法に、不完全なマルチバイト文字列を送信することでHTMLに 記述されているクォートを無効化する方法があります。この攻撃はHTML エス ケープのみでは防げない事に注意が必要です。では、どのように対策をすれば良 いのでしょうか? まずは、不完全なマルチバイト文字を利用してクォート(")を無効化できるこ とを確認しましょう。次のスクリプトをブラウザから実行して下さい(最後の ダブルクォテーションとPHPタグの間にスペースを入れないで下さい)。 <?php $str = urldecode('%81'); header('Content-Type: text/html; charset=SJIS'); ?> <?php echo htmlentities($str, ENT_QUOTES, 'SJIS') ?>" コードが分かりづらいので注意してください。PHPタグを2つに大別

    19. マルチバイト文字とXSS脆弱性
  • 新しいUnicode符号化方式

    新しい文字符号化方式 戻る リンク 文字符号について ユニコード UTFCP UTFCP2 UTFCP-TABLE 文字符号化方式比較 文字コード用語 UTFCPとUTF-JP 新しいUNICODE符号の必要性 UTF8では、日語に対応する文字(ひらがな、カタカナ、全ての漢字)の符号長が3バイトです。一方、Shift_JISやEUCでは、2バイトで表せます。この意味で、UTF8は、今までの文字コードよりもある意味において改悪されています。この事情は、他国の文字に置いても同様で、例えば、中国語の文字(漢字)においても、今まで2バイトで表せていた物が、UTF8では、3バイト必要になります。これは、欧米/中東圏以外の世界のあらゆる国や言語の文字において言えます。今まで2バイトで余裕を持って扱えていたものを、突然3バイトで扱わなければならないと言われれば、誰でも納得しがたいものでしょ

  • シフトJISを捨てられるか? - 記者のつぶやき:ITpro

    これまで,Windows Vistaの文字の扱いに関する事柄を何度か取り上げてきた。同じキャラクタ・コードで,Windows XPのときと文字の形が変わったり,Unicodeでしか扱えない文字があったりするという話題だ。今回は,エンコーディングについて考えてみたい。 これまでの記事でも書いてきたが,文字処理とエンコーディングに関する問題は,何もWindows Vistaに始まったわけではない。Windows XPやWindows 2000など,既存のWindowsでも同様だ。例えば,「鴎」の旧字である「シナカモメ」は,Unicodeでしか扱えない文字だが,Windows XP以前のMS-IMEでも入力できる。石鹸の「鹸」の旧字もそうである。これらの文字を扱うには,アプリケーション・ソフトが,文字列をUnicodeで処理しなればならない。シフトJISに変換した瞬間に,文字情報が無くなってしま

    シフトJISを捨てられるか? - 記者のつぶやき:ITpro
  • UTF-8 エンコーディングの危険性 - WebOS Goodies - 葉っぱ日記

    UTF-8の非最小形式による代替エンコーディングの話。古典的な攻撃方法なので、知っていて当然の話だと思っていたのですが、意外にまだ知られていないんですね。古くは Nimda の攻撃でも利用されていました…というのを調べていたら、たまたま「セキュリティホールのアンチパターン」という資料がひっかかったので紹介しておきます。あとは、ばけらさんによる説明「用語「Unicode Web Traversal」@鳩丸ぐろっさり (用語集)」がわかりやすいです。 個人的には、「UTF-8」というからには、こういうおかしなバイト列が含まれていた時点で入力全てを捨ててしまって例外などを発生させるべきで、無理やり UTF-32 とかに直すのは間違っているように思います。そうでないと、0xC0 0x32 のように、完全に壊れている UTF-8 をどうするの?とかにもなりますし。 あと、どうでもよい話: そもそもU

    UTF-8 エンコーディングの危険性 - WebOS Goodies - 葉っぱ日記
  • UTF-8 エンコーディングの危険性の補足 - WebOS Goodies

    えー、昨日投稿した「UTF-8 エンコーディングの危険性」の記事ですが、なにを間違ったのか過去最高のアクセスを記録しています。その前の Ruby 用 JSON クラスの反響がさほどでもなく、今回も大したことないだろうと思っていたので、かなりびびってます(((゜Д゜;)))ガクガク。はてぶコメントでも多くのご指摘をいただきまして、私自身反省している点もあるので、少し補足しておこうかと思います。 昨日の記事の意図は、まず単純に不正な UTF-8 シーケンスの存在を知ってもらい、そして具体的な対策として、入力の水際で不正な UTF-8 シーケンスを潰してしまおうというものです。ここが説明の足りなかった部分ですが、入力段で HTML などのエスケープをしようということではありません。 UTF-8 の正規化は HTML などのそれと違って二重にかけても結果が変わりません。また、目的はクライアントの保

  • banned interdit verboden prohibido vietato proibido

    このドメインを購入する。 hawklab.jp 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy

  • 「痴」「稚」が一杯。英語サイトを作ったら文字化け

    URLエンコードを求めるには、今まで何度か紹介しています自作Flashフォームを利用します。こちらにあります。 左の文字化け一覧から明らかなことは、文字化けするのは「‘(シングルクォテーション)」や「’(アポストロフィー)」、「“(ダブルクォテーション)」であることが分かります。ただ、よく見ると、このアポストロフィーやダブルクォテーション、何だか変です。妙に空白が目立ちます。 実は、これは日語のOSで普通に入力して表示される「'(アポストロフィー)」や「"(ダブルクォーテーション」とは別物です。 iso-8859-1(Latin-1)一覧表を参照していただき、「9」の列に注目してください。グレーになっている部分です。91番(9の列。1の行。LEFT SINGLE QUOTATION MARK)と92番(9の列。2の行。RIGHT SINGLE QUOTATION MARK)、93番(9の

  • PHPの文字化けを本気で解決する - ぎじゅっやさん

  • VistaをXPの字体に戻すというjp90タグの罠

    JIS C 6226が最初に制定されたのは1978年。6802字を収録した漢字コードとして制定され,規格票の例示字体は写研の石井明朝体で印刷された。ところがJIS C 6226は,1983年に改正された際,漢字300字の字体を変更した。この改正で「同じ文字コードでも違う字が表示されてしまう」という現象が頻繁に起こった。いわゆる「83JIS改正の悪夢」だ。 さらにJIS C 6226は,1987年にJIS X 0208という名前に変わっているが,このときには規格そのものの変更は一切おこなわれていない。次の1990年の改正では,規格票例示字体を平成明朝体に変えたので,1983年版とは微妙に字体が変わってしまった。これに懲りて,1997年の改正では,規格票例示字体は一切いじることなく,字数も全く変更せず,あくまで規格そのものの明確化につとめた。 一方,1990年にはJIS X 0212(補助漢字

    VistaをXPの字体に戻すというjp90タグの罠
  • ハタさんのブログ : scriptタグのcharsetはデキる子

    scriptタグのcharsetは何気にデキる子なんです。ホント 何かの手違いでcharsetの違うjsファイルとかを動的に読み込みたいなんて事があった場合でも結構素直。 via - JavaScriptとたわむれる : memo-space (function (){ var scripts = [ {'src': 'path/to/hoge.js', 'charset': 'UTF-8'}, {'src': 'js/foo.js', 'charset': 'Shift_JIS'}, {'src': 'http://labs.s2php5.jp/s2dao.js', 'charset': 'EUC-JP'} ]; var temp = document.createElement('div'); temp.style.display = 'none'; document.body.a

  • yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須

    (Last Updated On: 2016年3月3日)最近PostgreSQLMySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考:セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQLMySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト~6バイト必要なのか

    yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
  • 1