unicodeとpythonに関するmakoto15のブックマーク (2)
-
先日、ビジネスパーソン向けの Python 本を執筆したことを書きました。 t2y.hatenablog.jp 本稿では本書のことを﹁できるPy﹂と呼びます。 Amazon でいくつかカスタマーレビューもいただいて次のコメントをみつけました。 python3.7 対応ということで、pathlib を使ってる点が︵古いpython は切り捨てる!的なところは︶潔いと言えば潔いし、日本語のファイル名にも気を配っている記述はオライリーに期待するのは酷なところもある。でもこの本でもNFD問題は全くの記述無し。だめだろ、それじゃ。 Amazon CAPTCHA まさに仰る通りです。執筆時にそのことに気づかずご指摘いただいてありがとうございます。 ここでご指摘されている NFD 問題というのは、ファイル名のみに限った問題ではなく、Unicode の文字集合を扱ってエンコード/デコードするときに発生する
-
Pythonとlibiconv, nkf, Javaのコード変換を比較した記事がありました。 主な実装における EUC-JIS-2004, Shift_JIS-2004 から Unicode への変換結果の違い ASCIIとJIS X 0201の違いに起因する円記号問題とチルダ・オーバーライン問題、それにUnicodeのFTPサイトが原因と思われる全角ダッシュの件という既知の問題が多いので目新しくないのですが (﹃プログラマのための文字コード技術入門﹄をお読みいただければわかります)、Pythonについて目新しげな話がありました。 Pythonでは他と違って、二重(白抜き)の括弧をU+FFxxの位置にあるものでなくU+29xxに割り当てているそうです。うむ。そうか、そうきたか。 JISの公式な対応表ではU+FFxxの方になっています。文字名でいうとFULLWIDTH {LEFT|RIGHT
-
1