Как HTML избежать вьющихся кавычек в строке Java - PullRequest
Новая
       51

Как HTML избежать вьющихся кавычек в строке Java

2 голосов
/ 14 ноября 2009

У меня есть строка с фигурными кавычками. Я хотел бы заменить их HTML-сущностями, чтобы они не перепутали другие нисходящие системы. Для моей первой попытки я просто добавил соответствие для символов, которые хотел заменить, введя их непосредственно в мой код: 

public static String escapeXml(String s) {
    StringBuilder sb = new StringBuilder();
    char characters[] = s.toCharArray();
    for ( int i = 0; i < characters.length; i++ ) {
        char c = characters[i];
        switch (c) {
            // other escape characters deleted for clarity
            case '“':
                sb.append("&#8220;");
                break;
            case '”':
                sb.append("&#8221;");
                break;
            case '‘':
                sb.append("&#8216;");
                break;
            case '’':
                sb.append("&#8217;");
                break;
            default:
                sb.append(c);
                break;
        }
    }
    return sb.toString();
}

Это скомпилировано и отлично работает на моем Mac, но когда наш CI-сервер (который работает в Linux) попытался его собрать, он задохнулся: 

Out.java:[347,16] duplicate case label

Очевидно, что некоторая часть цепочки сборки на коробке Linux не может распознавать и различать эти причудливые символы.

Моя следующая попытка состояла в использовании экранирования Unicode. К сожалению, это даже не скомпилируется на моем Mac: 

...
            case '\u8220':
                sb.append("&#8220;");
                break;
            case '/u8221':
                sb.append("&#8221;");
                break;
...

Мой компилятор выдает эту жалобу: 

Out.java:[346,21] unclosed character literal

Я озадачен тем, как можно выполнить эту замену и обеспечить ее надежную работу на разных платформах. У кого-нибудь есть указатели? Заранее спасибо.

Ответы [ 5 ]

4 голосов
/ 14 ноября 2009

Литералы Unicode представлены в шестнадцатеричном формате: 

case '\u201c':
    sb.append("&#8220;");
    break;
....

И, как упоминалось в других ответах, у вас есть / вместо \ в одном из ваших литералов.

4 голосов
/ 14 ноября 2009

Вы можете использовать буквальный символ (т.е. '‘'), но ваш процесс сборки должен указать правильную кодировку источника во время компиляции. Параметр javac команды: -encoding. (Атрибут в задаче Ant javac тот же.) Он должен соответствовать любой кодировке, используемой вашей IDE при сохранении файлов.

Если ваша IDE использует, например, UTF-8, но сборочная машина использует кодировку US-ASCII по умолчанию для своей платформы, специальные символы будут декодированы как ?. Поскольку несколько случаев теперь имеют одинаковую метку, вы получите исходное сообщение об ошибке.

3 голосов
/ 14 ноября 2009

Проблема компилятора в том, что вместо '\ u8221' вместо '\ u8221' вы видите '/ u8221' - обратную косую черту.

Я не совсем уверен, что использование сущностей поможет, но вы можете попробовать ... Полагаю, это зависит от того, насколько поврежден нисходящий код.

РЕДАКТИРОВАТЬ: Doh, я не заметил, что ваши значения Unicode были в десятичном виде. Да, они должны быть в шестнадцатеричном виде :) Я оставлю этот ответ здесь, поскольку он объясняет, почему компилятор жаловался - '\ u8221' - это экранирующая последовательность, состоящая исключительно из символов, просто не та, которую вы хотели:)

0 голосов
/ 14 ноября 2009

Лучше было бы использовать Apache Commons Lang http://commons.apache.org/lang/api/org/apache/commons/lang/StringEscapeUtils.html.

0 голосов
/ 14 ноября 2009

Кодировка по умолчанию варьируется от платформы к платформе - Windows использует собственный диалект ISO-Latin-1 (по крайней мере, те, над которыми я работал). Linux часто использует UTF-8 (что, скорее всего, ваша проблема), а Mac использует MacRoman. Вы можете обойти большинство ваших проблем, придерживаясь простого 7-битного ASCII и используя \ u для всего, что вам нужно, если вам это нужно в исходном коде.

Лично я бы оставил что-нибудь «национальное» вне источника Java и использовал бы функции Локализации для поиска переведенных строк для простых ключей, и они помещаются в ваш код Java.

...