-
-
Notifications
You must be signed in to change notification settings - Fork 32k
Add alias for iso-8859-8-i which is the same as iso-8859-8 #62824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Emails and web pages may specify a character set of iso-8859-8-i, which has exactly the same code points as iso-8859-8. The -i has to do with how bi-directional text is handled, but doesn't affect the encoding: http://lists.w3.org/Archives/Public/www-validator/2001Apr/0008.html |
Here's a usable reference: http://www.w3.org/TR/html4/struct/dirlang.html#bidi88598 +1 on adding the alias. Also see http://lists.gnu.org/archive/html/lynx-dev/2012-02/msg00041.html for how Lynx does this. The URL also mentions "iso-8859-8-e", which should probably also be aliased to "iso-8859-8". Both names only apply to visual display characteristics of the text; the encoding is the same. |
I got the impression from what I read that -e included additional control sequences, but perhaps I misunderstood and that only meant that the data stream was expected to *use* additional control sequences but the control codes themselves are part of the base codec? I'm specifically thinking of this statement from the linked reference: "Because HTML uses the Unicode bidirectionality algorithm, conforming documents encoded using ISO 8859-8 must be labeled as "ISO-8859-8-i". Explicit directional control is also possible with HTML, but cannot be expressed with ISO 8859-8, so "ISO-8859-8-e" should not be used." The "cannot be expressed" seems to imply there are differences in the codec. |
On 02.08.2013 16:37, R. David Murray wrote:
No, not really. After some more research, I found that the -i and http://tools.ietf.org/html/rfc1556 At the codec level, these encodings are all the same. The suffixes |
Is it satisfactory to just add the -i and -e variants to ALIASES in charset.py? Or don't they qualify as "Aliases for other commonly-used names for character sets"? |
This issue is actually about adding the aliases to the codecs module. I'm not entirely sure at this point what the canonical character set name should be for email output (which is what the ALIASES table controls). |
I'm not sure about how the aliases are represented. I found some examples: http://web.mit.edu/Mozilla/src/mozilla/intl/uconv/src/charsetalias.properties So I wrote the aliases like this: 'iso-8859-8-i' : 'iso8859_8_I', But I'm not sure if I should write as shown in the example above or if it should looks like: 'iso-8859-8-i' : 'iso8859_8', And how about the tests? I couldn't locate the tests for this module. It it the tests inside the enconded_modules folder? |
Adding aliases to the set of iso-8859-8. |
From python's point of view they are both aliases of iso-8859_8, as discussed in this issue. Python does not have iso-8859_8-e and i codecs, which you changes to the alias table implies that it does (the target of the entry in the aliases table is the python codec name...and there is only iso8859_8.py, not iso8859_8_E.py or _I.py). |
The tests are in test_encodings.py. It is interesting that the tests pass with your patch applied; that indicates that there is a missing test, since we should be testing that all of the values in the aliases table are the names of existing codecs, and apparently we aren't. |
Added a patch with these two 8859-8 aliases and a corresponding test in test_codecs.py (couldn't find test_encodings.py mentioned in an earlier message). The test also found a missing 'tactis' codec (bpo-1251921), so I've commented it out in the aliases.py file. Please take a look. |
…h-134306) Co-authored-by: David Goncalves <[email protected]> Co-authored-by: Oleg Iarygin <[email protected]>
…859-8 (pythongh-134306) (cherry picked from commit 5ab66a8) Co-authored-by: Bas Bloemsaat <[email protected]> Co-authored-by: David Goncalves <[email protected]> Co-authored-by: Oleg Iarygin <[email protected]>
…8859-8 (gh-134306) (gh-134330) (cherry picked from commit 5ab66a8) Co-authored-by: Bas Bloemsaat <[email protected]> Co-authored-by: David Goncalves <[email protected]> Co-authored-by: Oleg Iarygin <[email protected]>
…dec files In Fedora, we install many codecs as .pyc files to save space. This test was failing when running from installed Python: ====================================================================== FAIL: test_alias_modules_exist (test.test_codecs.TransformCodecTest.test_alias_modules_exist) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python3.14/test/test_codecs.py", line 3115, in test_alias_modules_exist self.assertTrue(os.path.isfile(codec_file), ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Codec file not found: " + codec_file) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: False is not true : Codec file not found: /usr/lib64/python3.14/encodings/cp037.py ----------------------------------------------------------------------
…nstead of file checks (pythonGH-134777) (cherry picked from commit 8704d6b) Co-authored-by: Miro Hrončok <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: