| Name : perl-Test-Mojibake
| |
| Version : 1.3
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : lp154.1.1
| Date : 2023-01-27 16:42:20
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Test-Mojibake-1.3-lp154.1.1.src.rpm
|
| Size : 0.05 MB
| |
| Packager : https://www_suse_com/
| |
| Summary : Check your source for encoding misbehavior
|
Description :
Many modern text editors automatically save files using UTF-8 codification,
however, perl interpreter does not expects it _by default_. Whereas this
does not represent a big deal on (most) backend-oriented programs, Web
framework (at http://www.catalystframework.org/, at http://mojolicio.us/)
based applications will suffer of so-called at
http://en.wikipedia.org/wiki/Mojibake (lit. \"unintelligible sequence of
characters\").
Even worse: if an editor saves BOM (Byte Order Mark, \'U+FEFF\' character in
Unicode) at the start of the script with executable bit set (on Unix
systems), it won\'t execute at all, due to shebang corruption.
Avoiding codification problems is quite simple:
* Always \'use utf8\'/\'use common::sense\' when saving source as UTF-8;
* Always specify \'=encoding UTF-8\' when saving POD as UTF-8;
* Do neither of above when saving as ISO-8859-1;
* *Never* save BOM (not that it\'s wrong; just avoid it as you\'ll barely
notice it\'s presence when in trouble).
However, if you find yourself upgrading old code to use UTF-8 or trying to
standardize a big project with many developers each one using a different
platform/editor, reviewing all files manually can be quite painful.
Specially in cases when some files have multiple encodings (note: it all
started when I realized that _Gedit_ & derivatives are unable to open files
with character conversion tables).
Enter the Test::Mojibake \';)\'
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-T/15.4/noarch |
