サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
2019年8月6日に開催されたヤフー名古屋Tech Meetup #3の内容です。 #3 は「Webフロントエンドを支えるノウハウ」をテーマに開催しました。 JJUGCCC 2019 fall g3のセッション資料です。 「ちょっと凝ったことをしようとすると大量のXMLを書かなきゃいけない」「プラグインを並べてもうまく動いてくれない」など、Mavenは誤解され敬遠され、Gradleなどの他のビルドツールにシェアを奪われてきました。 が、依然としてMavenはJavaのデファクトスタンダードなビルドツールに位置づけられており、マスターする価値は十分にあります。そして良く学んでみると、そもそもXMLで過度なカスタマイズしようというのが誤った使い方だったのに気づきます。そこへ至るにも、タスクランナーの延長線上にある他のビルドツールと異なり、Maven独特なライフサイクルとプラグインの関係性もき
日本語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のレパートリと符号
先ほど，日本の携帯で使われている「絵文字」のUnicodeへの収録を検討していることと，そのためのデータがGoogleのブログで発表された．詳細は以下を見て頂きたい．Emoji for Unicode: Open Source Data for the Encoding Proposal（Google Code）Googleの日本語ブログでも，もうすぐ日本語訳（？）を公開するそうである（追記：公開された．）．この案は，将来的にISO/IEC JTC 1/SC 2に提案することになると思われる． この提案で誤解して欲しくないことは，この提案は，既存の携帯の変更を伴わないことである．つまり，この提案は，例えばGmailのような複数の携帯キャリアの絵文字を扱わねばならないシステムを意図したものであり，従来私用領域（Private Use Area）に割り当てていた文字を正式に符号化すると共に
2007年04月23日01:30 カテゴリLightweight LanguagesTipsperl tips - Encodeを速く使う方法 はっきり言ってこれはフェアではない。 みかログ: ErlangとPerlの速度比較Perl側は，Encodeが遅い． Encode::from_toがinplaceでコンバートしてしまうために，直前に文字列コピーがあるのも影響しているのかも なぜなら、Encode::from_to()は速度ではなく、安全性に最適化しているから。 そもそもはじめからUTF-8、それもutf8フラグがたっている文字列にfrom_toを使うのはばかげている。 for(my $i = 0; $i < 0xffff; $i++) { my $str2 = $str; Encode::from_to($str2, "UTF-8", "Shift_JIS"); } は単に
UTF8 フラグについてわかってるつもりだったんですが，utf8::is_utf8 considered harmful - Bulknews::Subtech - subtech を読んで混乱したので，自分なりにまとめてみました。間違いがありましたらご指摘よろしく。 まとめ スカラー変数の内部表象の状態を示すものとして UTF8 フラグというものがある スカラー変数は（リファレンス等は別として）下記のものを格納できる (A) 文字列（内部表象:UTF-8） (B) 文字列（内部表象: ISO-8859-1） (C) バイナリ列 純粋なバイナリストリーム（画像ファイル等）かもしれないし，UTF-8 octet stream かもしれないし， CP932 octet stream かもしれないし，etc,etc ...Perl は（後方互換性確保などの理由から）ISO-8859-1
2007年01月11日21:00 カテゴリLightweight Languagesruby|perl - 文字コードのちょっと高度な判定 これははっきり言って悩ましい。ですが、判定が曖昧な場合はその旨をきちんと通知するのがBetter Practiceではないかと思います。 Matzにっき(2007-01-03) 手元のcalkiがUTF-8の「》」相当の文字(U+8BB)を含むエントリが文字化けするので、 nkf-utf8のソースを見てみた。 どうも自動判定の優先順位がEUC-JP,SJIS,JIS,UTF-8で固定されていて、 EUCの範囲内に収まる文字列はすべてEUC-JPとみなすことになっている。 で、UTF-8の「》」はEUC-JPの「損」と同じバイト列なのだ。例えば、以下を行ごとにコード判定すると、以下のような結果になります。 son.utf8 » 損 »損 »Son nk
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のようなHTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
基本的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えばRuby の場合、不正なUTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです（昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ
2004.10.17 新規作成。2004.12.19 加筆。2005.04.02加筆。 最近、コンピュータで扱う文字列の文字コードがUnicodeでなければならない場面が増えてきた。UnicodeとシフトJIS、EUC-JPを変換する機会が多い。この変換は変換表で行うが、変換表が実際的なものでなければ、文字化けが発生することになる。 おかしな変換表は、これまでは、特にLinuxなどの上で動作するオープンソースソフトウェアで多く見られた。おそらく規格原理主義者が多かったためだろう。そもそも、規格どおりに変換表を作ると、実用的な変換表にはならない。しかし、最近ではまともな変換表を実装しているものも増えてきて、うまく選ぶだけでいいようになってきている。 変換表の違いをまとめたページはよく見かけるが、実際にどのような条件を満たして変換するものを選べばいいか不明なので、まとめてみた。 変換表に求めら
前回の記事について、説明が不足していたようで、404Blog Not Found様からmultipart/form-data を忘れている とお叱りを頂いてしまいました。 えっと、誤解です。 multipart/form-dataを使っても状況はまったく変わらないことが分かったので説明を省略しただけです。 誤解をとくために前回の調査結果を簡単にまとめさせてください。 ・Webの世界でEUCといったらCP51932がデファクトスタンダードである ・これは本来のEUCから補助漢字をなくして、かわりにWindows機種依存文字を 追加したものである。 ・しかし、FirefoxだけはCP51932+補助漢字という独自拡張EUCを採用している。 ・これはURL Encoding の％エスケープを解いたあとのデータが補助漢字に ついて生EUCとするか、数値文字参照とするか、という違いとして現れてくる
美しき日本語の悲しい定め なにがなんでも社長の名前はこの漢字で！ ほとんどの制作現場で、困った経験があると思われるのが「旧漢字問題」である。企業Webサイトの役員一覧などの氏名表記を、「社長の苗字はこの漢字で表示して」と旧漢字を指示されることだが、はっきりいって、悩ましい展開になる場合が少なくない。とりわけ会社案内などの印刷物を拡大コピーし、「この漢字」とFAXで送られてくると、間違いなく厄介な状況が長引く。 既にお気づきかもしれないが、要するに、JIS第一水準・JIS第二水準にはない漢字を表示せよ―とのご指示である。正直なところ、これには困ってしまう。 どういうわけか、役員などの皆さまには、旧漢字の氏名をお持ちの方が多い。いや、逆に旧漢字の氏名をお持ちだからエラクなるのか、とにかくフォントがない文字を表示せよとの厳命なのだ。まるで錬金術ならぬ錬文字術で、無から有をつくれと指示され
限定された「文字コード」の影響で、デジタル・データとして利用できる漢字が限定されてしまう、という問題は古くからある。ところが、最近はあまり聞かれなくなったようだ。しかし、この古い問題はいまだに健在なのだ。今回は、筆者の名字からこの問題を考えてみたいと思う。 名前を間違えられる 唐突だが、筆者の名前は「渡邉利和」である。基本的には面白くも何ともない、何の変哲もない名前であるが、唯一引っ掛かるところがあるとすれば、それは「邉」の字だろう。この字はさまざまな異体字があることでも知られており、戸籍の記録を調べたら20種だか50種だかの異体字が確認されたとかで話題になったこともあったはずだ＊1。 ＊1 詳しい情報を覚えておらず、残念に思っている。こうした調査結果に心当たりがある方がいたら、ぜひ参照先をお教えいただきたい。なお、イーストが販売している「人名外字1500V2」という外字フォント集には、ワ
2004 JIS （ JIS2004 ）について、問題となる混乱を解説します。 ［ 2005.08.12. ］ ※ この文書の目的は、誰かを非難または攻撃することではなくて、 世間にある誤解または錯覚をほどくことです。 ★ 「個々の文字をどう使えばいいのか」という 実用的な結論については、 下記のページをご覧ください。 → Open ブログ 「文字使用の指針・まとめ」 このページには、「指針１」「指針２」「指針３」というリンクもあります。 ★本文書では、学術的 ・理念的 ・原理的 な 話題 を主に扱います。本文書を公開したあとの新しい情報ついては、次のページをご覧ください。 → Open ブログ 「文字規格」 ここには、細々とした話題がいろいろとあります。 「2004 JIS をめぐる混乱」について語ろう。 新しい漢字規格の問題については、2005年７月末にマイクロソフトが方針を示して
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
